PATCH: Bug 52115: rename of directory misbehaves

[Dawit A.]

On Tuesday 13 January 2004 07:08, David Faure wrote:
> 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 :-)

Do not worry. It took me a long long 2 days to figure out how everything 
worked before I can even begin to contemplate a fix :)

> Why does it only act on ERR_DIR_ALREADY_EXISTS? Shouldn't it do the same
> for ERR_FILE_ALREADY_EXISTS?

An oversight:) Yes, it should.  I was only dealing with a directory as 
outlined on. BTW, you need the rename dialog patch as well. Otherwise the 
inncorrect URL is shown!

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

Ah okay. But that still does not prevent people from typing the path in 
manually, either by mistake or otherwise, no ? I did not see any validator on 
the lineedit of the rename dialog which I think we will need at some point in 
the future...

> Updated patch attached, seems to work well here.

Looks okay. Can you add the ERR_FILE_ALREADY_EXISTS check as well then ?

On related note it is sad none of the common remote protocols, ftp, fish, 
sftp, gracefully deal with renaming of directories or files to an existing 
name. More things to fix :(

-- 
Regards,
Dawit A.
"Preach what you practice, practice what you preach"