PATCH: Bug 52115: rename of directory misbehaves

[David Faure]

On Tuesday 13 January 2004 08:53, Dawit A. wrote:
> On Monday 12 January 2004 03:52, David Faure wrote:
> 
> > Thanks but I'm afraid the patch is wrong (it duplicates code instead of
> > fixing the bug :)
> 
> Hmm... okay but you yourself said that the "fast" ::rename path is not used 
> after such trivial errors  which results in unnecessary stats and lookups. 
> That was exactly what I was trying to avoid once I got a hang on everything. 
> It is not the easiest thing to trace actions through job.cpp. :) However, it 
> is indeed a good decision to fix the actual bug first. Could my patch then be 
> considered as a short-circuit hack for using the quick ::rename path for such 
> trivial errors ?
True, it would be good to do that. But it's not what your patch does, is it?
In the R_RENAME case it launches a ::stat() and goes to STATE_STATING,
i.e. it moves on to the "long way".
If your patch used fast-rename I would have committed it, no doubt :)

We would need to loop around the fast-rename code
(or recursively call it), to offer the rename box as long as an existing
name is chosen... I think this would be safer done after 3.2.

> I was worried it might affect some protocols, but I do not  
> see how if the protocol returns the proper error codes...
Right - that's how the fast-rename path works already, so nothing new there.

> However, the more pressing problem with your commit is that it exposes yet 
> another bug somewhere else. Here is the dialog box I get when I rename a 
> directory d1 to d2 and there is an existing directory d2:
> 
> http://members.cox.net/kdelists/screenshots/rename-dlg-1.png
Indeed (not related to my commit, this was already there). Fixed.

-- 
David FAURE, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).