
On Wed, 28 Sep 2005 21:01:26 -0400, James Y Knight <foom@fuhm.net> wrote:
On Sep 28, 2005, at 8:04 PM, Jp Calderone wrote:
rename() in VFS should work across filesystems,
Hm, that is going to be an interesting one to implement. I'm thinking in particular about what happens when you have a structure like: / -> adhoc.AdhocDirectory: tmp -> osfs.OSDirectory("/home/jknight/tmp", ...) home -> inmem.FakeDirectory(...)
and I ask to move a file from /tmp/foo to /home/bar.
I can see ways to make this work. They involve temporary files, as you mention below. If we rule those out, it does become harder.
IMO it is reasonable to say that the VFS 'rename' operation is allowed to cleanly fail, and not do the rename, forcing a higher level to do a copy/delete if it wants. This pushes the complication out of each VFS implementation to one implementation that will work across all, and furthermore can share its code with the copy implementation. This maps nicely to rename(2), as well, as a bonus.
guarantee atomicity (if this is feasible - I think it is. If not, it should explicitly deny atomicity),
It isn't feasible, when renaming across filesystems. There will certainly have to be a time at which both 'from' and 'to' exist. Additionally, it may be impossible to create a file 'to+".tmp"' (or similar) in the target directory to atomically rename to 'to' when you've finished copying, because of permissions. Another reason to restrict "rename" to be the simple rename, rather than the copy&delete-rename.
When are you allowed to create a file named "foo" in a directory, but not allowed to create a file named "foo.tmp"? Anyway, I think it's worth a try at least. If it turns out to not be possible, then certainly it should not be done :) I am mainly concerned that there be consistent behavior across backends. Writing code that deals with the quirks of os.rename() on Win32 is annoying, to say the least (and realisticly, just plain error prone). Jp