Messages in this thread | | | Date | Sun, 31 Mar 2013 10:25:48 +0200 | From | Pavel Machek <> | Subject | Re: New copyfile system call - discuss before LSF? |
| |
Hi! On Sat 2013-03-30 22:38:35, AEDilger Gmail wrote: > On 2013-03-30, at 14:45, 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? > > Yes, that would be reasonable, and/or possibly openat(fd, NULL, AT_FDCWD|AT_UNLINKED)?
openat() is better interface for this, I'd say.
BTW... I don't think this has to be done at the same time as splice() [or how it ends up being called] changes...
Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
| |