PATCH: Bug 52115: rename of directory misbehaves

David Faure faure at kde.org
Tue Jan 13 12:08:26 GMT 2004


On Tuesday 13 January 2004 11:25, Dawit A. wrote:
> It is supposed to. And the tests I did confirm that this is what happens...
>
> > In the R_RENAME case it launches a ::stat() and goes to STATE_STATING, 
> > i.e. it moves on to the "long way".
> 
> I am stating the destination and not source :) Also I reset the 
> destinationState flag back to DEST_NOT_STATED so that 
> CopyJob::slotResultStating does the "right thing"

Oh, I see. I'm not updating destinationState after the destination changed, and
this indeed leads to bugs (e.g. if I try to rename a dir to the name of an existing file,
I get the "foo is a file, but a folder was expected" error, instead of the rename box).

Now I finally understand your patch - sorry it took me so long :-)
Why does it only act on ERR_DIR_ALREADY_EXISTS? Shouldn't it do the same for ERR_FILE_ALREADY_EXISTS?

Also, the KURL(m_dest,newPath) looks wrong. The 2nd arg of that KURL ctor
doesn't take paths (this would lead to bugs with files containing e.g. '#' in their name).
m_dest.setPath(newPath) should be enough.

Updated patch attached, seems to work well here.

-- 
David FAURE, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: job.cpp.diff
Type: text/x-diff
Size: 3062 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20040113/f7134b6d/attachment.diff>


More information about the kde-core-devel mailing list