On Fri, Oct 17, 2008 at 12:27 PM, Jeff Layton <jlayton@xxxxxxxxxx> wrote: > On Fri, 17 Oct 2008 10:24:29 -0500 > "Steve French" <smfrench@xxxxxxxxx> wrote: > >> On Fri, Oct 17, 2008 at 10:09 AM, Steve French <smfrench@xxxxxxxxx> wrote: >> > Even when a file is open by another process, posix allows the file to >> > be deleted (the file is removed from the namespace and eventually the >> > data is removed from disk). Unfortunately due to problems in some >> > NAS filers/servers this can be hard to implement, and I am not sure >> > what the "best" behavior is in that case. > > My argument is that the primary function of unlink() is to remove a > filename from the filesystem. If we return success from such a call > without actually having freed up that filename, then that's a bug. It's > unfortunate that some servers don't support the calls we need to make > this work all the time. The filename will be freed - and the trade off is which breaks fewer apps. Both open and unlink man pages list plausible return codes but I am worried that the sequence of file operations open/unlink/close (I think we see both dbench and connectathon do this IIRC) is as common a a sequence as open/unlink/create/close thus we could break more apps your way than leaving it as is. > We can't however make assumptions about what applications want. We > could, in principle, fix up the situation where a server does > open->unlink->create by truncating the old file and pretending that > it's a new one. That could corrupt data - the original opener may need that data up to the moment they close that handle. > All we can reasonably do is try to have each syscall give us the > expected end result or an error if it can't be done. The open syscall is allowed to fail with ETXTBUSY (or even access denied among other). Although this type of situation is not common on open, it more common in open (and create) than on unlink and thus A likely that an app could deal with an open error than on the unlink that preceeded it. The other argument here is that whether or not we allow unlink (when it can be marked for deletion but not silly renamed) - we have apps that will get the same error on open due to Windows, MacOS and other non-Linux clients setting the flag (ie open/create failures for a filename that was marked delete-on-close can still happen even if we aren't the ones who set the flag on the file since Windows and various other OS can and do set this file on the server or remotely) -- Thanks, Steve -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
