From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ric Wheeler Subject: Re: openat(..., AT_UNLINKED) was Re: New copyfile system call - discuss before LSF? Date: Sun, 31 Mar 2013 19:14:15 -0400 Message-ID: <5158C347.3090400@redhat.com> References: <512BD44C.40907@amacapital.net> <20130226210232.GA19510@logfs.org> <20130330194933.GB1005@amd.pavel.ucw.cz> <08D26E22-3856-43A4-8835-48C86CC5F71C@dilger.ca> <20130330214509.GB4322@amd.pavel.ucw.cz> <925D663D-D8F8-4297-A642-33C732354701@netapp.com> <20130331073604.GA13159@amd.pavel.ucw.cz> <1364754452.4771.10.camel@leira.trondhjem.org> <20130331183238.GA25751@amd.pavel.ucw.cz> <1364755493.4771.14.camel@leira.trondhjem.org> <20130331225022.GA31552@amd.pavel.ucw.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Myklebust, Trond" , Andreas Dilger , =?ISO-8859-1?Q?J=F6rn_Engel?= , Andy Lutomirski , Zach Brown , Paolo Bonzini , Linux FS Devel , "linux-kernel@vger.kernel.org" , "Chris L. Mason" , Christoph Hellwig , Alexander Viro , "Martin K. Petersen" , Hannes Reinecke , Joel Becker To: Pavel Machek Return-path: Received: from mx1.redhat.com ([209.132.183.28]:22910 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755895Ab3CaXPd (ORCPT ); Sun, 31 Mar 2013 19:15:33 -0400 In-Reply-To: <20130331225022.GA31552@amd.pavel.ucw.cz> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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