You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
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?
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.
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...
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!
Activity
robinrodricks commentedon Jul 14, 2022
Its a good idea.
MihailsKuzmins commentedon Jul 14, 2022
I think this logic should be somewhere in
UploadFileInternalandUploadFileInternalAsync, 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 itI 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
yatlor commentedon Jul 14, 2022
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 commentedon Jul 15, 2022
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 commentedon Jul 15, 2022
Yes these are good ideas. The scope of FluentFTP is to provide the best out of the box support for FTP operations.
robinrodricks commentedon Sep 19, 2022
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 commentedon Mar 22, 2024
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 commentedon Mar 22, 2024
Or simply an "OverWriteWithoutDelete" or " OverWriteAttempt" parameter value
gregoryb commentedon Mar 28, 2024
Same issue behaviour here.
FanDjango commentedon Mar 28, 2024
Noted.
mryanmurphy commentedon Feb 4, 2026
Was added in 50.1.0
FluentFTP/RELEASES.md
Lines 3 to 6 in f931112