Messages in this thread | | | Date | Sat, 30 Mar 2013 19:21:07 -0400 | From | Ric Wheeler <> | Subject | Re: New copyfile system call - discuss before LSF? |
| |
On 03/30/2013 05:57 PM, Myklebust, Trond wrote: > On Mar 30, 2013, at 5:45 PM, Pavel Machek <pavel@ucw.cz> > wrote: > >> On Sat 2013-03-30 13:08:39, Andreas Dilger wrote: >>> On 2013-03-30, at 12:49 PM, Pavel Machek wrote: >>>> Hmm, really? AFAICT it would be simple to provide an >>>> open_deleted_file("directory") syscall. You'd open_deleted_file(), >>>> copy source file into it, then fsync(), then link it into filesystem. >>>> >>>> That should have atomicity properties reflected. >>> Actually, the open_deleted_file() syscall is quite useful for many >>> different things all by itself. Lots of applications need to create >>> temporary files that are unlinked at application failure (without a >>> race if app crashes after creating the file, but before unlinking). >>> It also avoids exposing temporary files into the namespace if other >>> applications are accessing the directory. >> Hmm. open_deleted_file() will still need to get a directory... so it >> will still need a path. Perhaps open("/foo/bar/mnt", O_DELETED) would >> be acceptable interface? >> Pavel > ...and what's the big plan to make this work on anything other than ext4 and btrfs? > > Cheers, > Trond
I know that change can be a good thing, but are we really solving a pressing problem given that application developers have dealt with open/rename as the way to get "atomic" file creation for several decades now ?
Regards,
Ric
| |