+FTP: no overwrite dialog on rename

[ghisler(Author)]

OK, I have added this now for renaming single files! Now when the user confirms the rename but it fails, TC will delete the target and try again.

[petermad]

Seems to work fine in TC 8.51b3 both for rename conflicts in same folder and for conflicts with files in parent folder or subfolder

[ghisler(Author)]

Thanks for testing it! If all works well and no bugs are found, I will use this also when renaming multiple files.

[Sob]

I tested it a little. Basic stuff works well:

[ok] Question on rename when target exists in current directory
[ok] Question on rename when target exists in another directory (not a bad idea with SIZE command :)
[ok] Question on upload to another directory when target exists
[ok] Deleting existing target when server does not support rename overwrites

But there are some problems with permissions, these were tested with IIS FTP:

Code: Select all

// RO source, existing RW target
SIZE ../readwrite/target.txt
213 0
//TC message: overwrite? - user:yes
RNFR source.txt
550 
//!!!bug#1: TC should stop here and show error
DELE ../readwrite/source.txt
250 DELE command successful.
RNFR source.txt
550
//TC message: rename failed!

Code: Select all

// RW source, existing RO target
SIZE ../readonly/target.txt
213 0
//TC message: overwrite? - user:yes
RNFR source.txt
350 Requested file action pending further information.
RNTO ../readonly/source.txt
550 
DELE ../readonly/source.txt
550 
//!!!bug#2: TC does not show any error

Code: Select all

// RO source, existing RO target
SIZE ../readonly/target.txt
213 0
//TC message: overwrite? - user:yes
RNFR source.txt
550 
//!!!bug#1: TC should stop here and show error
DELE ../readonly/target.txt
550 
//!!!bug#2: TC does not show any error; but in this case it shouldn't get so far anyway

Or another problem, this one is with vsftpd, but unfortunately TC can't do much here:

Code: Select all

// RO source, existing RW target
SIZE ../readwrite/target.txt
213 0
//TC message: overwrite? - user:yes
RNFR source.txt
350 Ready for RNTO.
//oh sure, the file is read only, but why not promise client that server will try to rename it anyway...
RNTO ../readwrite/target.txt
550 Rename failed.
//TC: hmmm, server probably doesn't support rename overwrites
DELE ../readwrite/target.txt
250 Delete operation successful.
//TC: target cleared, lets try again
RNFR source.txt
350 Ready for RNTO.
RNTO ../readwrite/target.txt
550 Rename failed.
//TC: whoops! what happened?
//TC message: rename failed!

But even though deleting the target file and not finishing renaming of source might look bad, user already agreed that target can be overwritten, so it's not such a big deal.

[ghisler(Author)]

It's indeed a good idea to detect a RNFR error separately - currently TC only tests whether the entire rename operation failed. But in the second case, TC cannot know why RNTO failed.

[Sob]

TC 8.51b4 now handles failed RNFR.

But there's still missing error message (marked as bug#2 in logs in my previous post). And now it also happens after RNFR fails.

[ghisler(Author)]

Sorry, currently not supported.

[Sob]

I noticed that. :) But TC knows that it's in the middle of rename procedure and when some of the steps fails, regular "rename failed" message would be much nicer than silent failure.