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

[Tuukka Tolvanen <tuukka tolvanen gmail com>]

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.

> > 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?

> 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.

The particular case of merge-moving a hierarchy of otherwise empty 
folders onto itself, as in my testcase, is kinda hard, because the whole 
merge is a big recursive no-op. (Temp renaming folders under merge would 
result in a good failure, but that just starts to sound a bit too 
fishy.) Then again, getting your empty folders pruned in the odd case of 
managing to move stuff onto itself isn't /that/ serious, perhaps.

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.

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.

't.