Re: openat(..., AT_UNLINKED) was Re: New copyfile system call - discussbefore LSF?
From: Ric Wheeler
Date: Sun Mar 31 2013 - 19:15:44 EST
On 03/31/2013 06:50 PM, Pavel Machek wrote:
On Sun 2013-03-31 18:44:53, Myklebust, Trond wrote:
On Sun, 2013-03-31 at 20:32 +0200, Pavel Machek wrote:
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?
...and what's the big plan to make this work on anything other than ext4 and btrfs?
Deleted but open files are from original unix, so it should work on
anything unixy (minix, ext, ext2, ...).
minix, ext, ext2... are not under active development and haven't been
for more than a decade.
Take a look at how many actively used filesystems out there that have
some variant of sillyrename(), and explain what you want to do in those
cases.
Well. Yes, there are non-unix filesystems around. You have to deal
with silly files on them, and this will not be different.
So this would be a local POSIX filesystem only solution to a problem
that has yet to be formulated?
Problem is "clasical create temp file then delete it" is racy. See the
archives. That is useful & common operation.
Which race are you concerned with exactly?
User wants to test for a file with name "foo.txt"
* create "foo.txt~" (or whatever)
* write contents into "foo.txt~"
* rename "foo.txt~" to "foo.txt"
Until rename is done, the file does not exists and is not complete. You will
potentially have a garbage file to clean up if the program (or system) crashes,
but that is not racy in a classic sense, right?
This is more of a garbage clean up issue?
Regards,
Ric
Problem is "atomicaly create file at target location with guaranteed
right content". That's also in the archives. Looks useful if someone
does rsync from your directory.
Non-POSIX filesystems have problems handling deleted files, but that
was always the case. That's one of the reasons they are seldomly used
for root filesystems.
Pavel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/