UploadFileAsync with Overwrite

[MihailsKuzmins]

I have experienced problems with UploadFileAsync and Overwrite when the file on the FTP server is deleted, but for some reason (sorry, I do not have logs) upload of a new file fails, so as a result there is no file on the FTP server at all.

Some people suggest renaming the file on the server and delete it only if upload succeeds, and revert renaming if upload fails. I think that this is not implemented in FluentFTP. Are there any plans to do it?

[robinrodricks]

Its a good idea.

[MihailsKuzmins]

I think this logic should be somewhere in UploadFileInternal and UploadFileInternalAsync, but these methods are really large with multiple return statements, so it does not seem to be so simple. Somehow we need to rename the file here, keep a reference to it and do not forget to delete it

I cannot think of something good at the moment, but maybe will try to play around with it. Or maybe you have some tips?

FluentFTP/FluentFTP/Client/FtpClient_FileUpload.cs

Lines 726 to 732 in ed515e4

	else if (existsMode == FtpRemoteExists.Overwrite) {
	// delete the remote file if it exists and we need to overwrite
	if (fileExists) {
	DeleteFile(remotePath);
	}
	}

[yatlor]

I upload files with a .partial extension and then if the upload succeeds, I delete the original and rename the .partial file. Hard to say what the best approach is, but this keeps the file available until it is ready to be replaced. Just a thought. I do this even when the file doesn't exist as it makes it clear for my use case that the upload might be able to resume and if the upload is interrupted it is clear if the file is seen in another session. Not sure if all of that belongs in the library or not but it is helpful in my use case.

[my-nihongo]

I upload files with a .partial extension and then if the upload succeeds, I delete the original and rename the .partial file. Hard to say what the best approach is, but this keeps the file available until it is ready to be replaced. Just a thought. I do this even when the file doesn't exist as it makes it clear for my use case that the upload might be able to resume and if the upload is interrupted it is clear if the file is seen in another session. Not sure if all of that belongs in the library or not but it is helpful in my use case.

Yes, I have also implemented the logic outside the library, but if it is a common practice, maybe it is worth considering integrating it into the library...

[robinrodricks]

Yes these are good ideas. The scope of FluentFTP is to provide the best out of the box support for FTP operations.

[robinrodricks]

Added to the bucket list. We will pick this up as and when we have free time. Comment on this issue if you want us to prioritize it. Thanks!

[egreiner]

I know this is closed but planed for future releases...

Keep in mind that FluentFTP may experience difficulties if the FTP user lacks the permission to delete files.

This situation is particularly relevant to me as I'm currently facing this challenge while trying to upload a CSV file with updated contact data for a VoIP system. (Despite discussing this with the company, they've been unyielding...)

FluentFTP's current behavior does not overwrite the existing file directly. Instead, it attempts to delete the file before uploading the new one. This process fails in cases where the user does not have delete permissions.
(tested with sync and async clients)

While I'm not familiar with the internals of FluentFTP, it seems to me that enabling an overwrite option should fulfill user expectations without needing to delete and re-upload. I'm contemplating whether introducing a method like TryUploadFile(...Overwrite...) or SafeUploadFile(...Overwrite...) — or whatever it might be named — to handle this specific scenario would be beneficial. Alternatively, adding an additional enum item like SafeOverwrite might be a more elegant solution.
Thanks!

[FanDjango]

Or simply an "OverWriteWithoutDelete" or " OverWriteAttempt" parameter value

[gregoryb]

Same issue behaviour here.

[FanDjango]

Same issue behaviour here.

Noted.