Re: [PATCH] 312707: moving a file or folder onto itself destroys it

[Alexander Larsson <alexl redhat com>]

On Fri, 2005-08-26 at 00:09 +0300, Tuukka Tolvanen wrote:
> Alexander Larsson wrote:
> > On Thu, 2005-08-25 at 12:38 +0200, Alexander Larsson wrote:
> >> On Sat, 2005-08-06 at 21:51 +0300, Tuukka Tolvanen wrote:
> >>> Tuukka Tolvanen wrote:
> 
> >>> Besides, the same filesystem could be reachable via multiple methods at 
> >>> the same time anyhow, which renders fs entry identity comparisons pretty 
> >>> academic. Temp-renaming targets that are in the way, instead of 
> >>> deleting, seems to be the only way to really cover all the cases, that I 
> >>> can think of. Does that sound right?
> 
> >> I dislike both the initial fix and doing temp renaming. They introduce
> >> even more stats and other i/o into an already slow gnome_vfs_xfer. Also,
> >> such solutions sounds inherently racy.
> 
> I don't think temp renaming should introduce any raciness in itself, as 
> long as only mandatory failures of actual actions are checked, instead 
> of pre-emptive checks being made.

I guess if you have an atomic way to generate a tempfile name its mostly
safe. Not more than the general racyness of doing a recursive file
operation anyway.

However, will the temp move really work in the case we're discussing
though? Won't the move of the file in the destination folder actually
also change the name in of the file in the source folder (since they are
symlinked).

> >> The kernel allows a move (rename) from parent2/folder to parent1/folder.
> >> It just returns success and does nothing. I wonder why a gnome-vfs-xfer
> >> removes the file. Shouldn't it just end up being a gnome_vfs_move (since
> >> the files are on the same filesystem), which shouldn't remove the file? 
> 
> I was looking for a fully general solution with the temp names dance, 
> but within a filesystem offloading the weirdness to the actual 
> filesystem by just using move for the leaf items sounds a lot more sane. 
> Perhaps the pre-flight deletion is being used as a convenient way of 
> signaling the replace decisions in-band, so to speak?

I'm not sure what you mean.

> > Damn, I tried this out (see attached not-very-tested patch), but it
> > didn't work out. The problem is that we on name conflicts of directory
> > moves, if you pick "replace" it actually switches into a merge, which is
> > done by changing from a move operation to a recursive copy + remove.
> 
> A merge-move doesn't have to be done that way, though? The source 
> cleanup could be done during the move xfer in general, essentially 
> omitted in intra-fs merge-moves for items except for source folders, 
> which could be non-recursively removed. The only drawback that comes to 
> mind would be that the compound op failing halfway would leave the 
> hierarchies half here, half there.

I'm sure there is a way for the merge-move case to be handled in a
better way, but in my experiment i only rearranged the current code a
bit, and what happens there is that a "move" operation that has a name
conflict is just turned into a normal "recursive copy and then remove
source" operation in order to merge the source tree with the target
tree. Structuring the move like you propose would need more changes to
the code. You'd have to either mix in the source removal with the copy,
or keep a list of every file you copied (recursively) and then remove
them all non-recursively.

Aborting in the middle will always cause such strange states. I don't
think there is any way out of that.

> As for inter-fs transfers, something involving naming games (either temp 
> rename of the conflict target, or initial name of a transferred-in item) 
> seems necessary, and perhaps not too much extra work fs considering that 
> content data is being copied too in that case.

Does this problem happen in inter-fs transfers at all?

> http://bugzilla.gnome.org/show_bug.cgi?id=311591#c9 Alexander Larsson:
> > amount of i/o, creates new names in the filesystem (really bad if the filesystem
> > is e.g. a subversion repository or some other strange fs) and generally sounds a
> 
> ...but, yeah, then there's that.

Yeah... 

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's a war-weary hunchbacked boxer from the 'hood. She's a bloodthirsty 
belly-dancing opera singer who can talk to animals. They fight crime!