PATCH: Bug 52115: rename of directory misbehaves
faure at kde.org
Tue Jan 13 08:34:13 GMT 2004
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:
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).
More information about the kde-core-devel