FTP operations fail with "device is protected"

[JTremblayAGT]

I am trying to upload a .XVR file for a Karel program and I get an error while the corresponding .CVR file is present fails silently and attempting to delete it says the file is protected (because of the CVR). Using the provided delete method I am unable to delete the .CVR file and I get that the device is protected.

Uploading a .XVR file with FileZilla works perfectly fine even if the CVR file is present and deleting the .CVR file deletes both.

It seems something isn't quite set right in the FTP client that is created with the connection since FileZilla has no trouble performing these operations.

I have also tried with another FTP client (WinSCP) and it also works just fine.

[JTremblayAGT]

I have found the reason for this issue. Filezilla immediately performs a STOR operation and simply overwrites the XVR file while the provided method actually attemps a DELE operation, which fails with a 550 file is protected error. I have replicated the issue using FluentFTP using the FtpRemoteExists.Override flag: changing it to FtpRemoteExists.NoCheck fixes the issue.

Please make the FTP client more easily configurable. The current defaults are way too restrictive.

[Rufus31415]

Thanks for the investigation.

Do you think it would be better to simply use FtpRemoteExists.NoCheck equivalent by default instead of adding yet another parameter?

It would keep the API simpler for users and would also be closer to the behavior of FileZilla and WinSCP. What do you think?

[JTremblayAGT]

I don't know all the implications of using this flag and there are some risks according to the FluentFTP authors. There is also a FtpRemoteExists.OverwriteInPlace which should accomplish the same thing and be safer but I haven't tried it yet.

I'm not a big fan of hiding a default that might not cover all cases but that's up to you. If that's the case we'll likely just stick to FluentFTP for file transfer operations.