[go: nahoru, domu]

|
|
Subscribe / Log in / New account

Flags as a system call API design pattern

Flags as a system call API design pattern

Posted Feb 13, 2014 14:25 UTC (Thu) by mathstuf (subscriber, #69389)
In reply to: Flags as a system call API design pattern by sorokin
Parent article: Flags as a system call API design pattern

What is renameat2's behavior with paths that reside on different filesystems? I'd assume it fails due to the atomicity guarantees it can no longer make. Since rename already has some restrictions in that regard, swapat sounds, to me, like it might not care by default (and would need a flag for atomicity).

As for behavior change based on flags, one coworker was working with a tool which output to stdout/stderr by default, was silent with -E (no argument), but -EE took an argument for where to write the output (but just the output data from the conversion, not logging), so there's some insanity out there. I hope the kernel avoids such...behavior for a single syscall (outside of *ctl calls).


(Log in to post comments)


Copyright © 2024, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds