RNFR / RNTO produces "553 File Exists"
Moderator: Project members
-
- 500 Command not understood
- Posts: 3
- Joined: 2012-01-03 21:11
- First name: Austin
- Last name: Pass
RNFR / RNTO produces "553 File Exists"
Hello,
My Server is FileZilla Server version 0.9.40 beta.
The connection between client and server is plain routed IP, no NAT anywhere to be seen. The connection uses passive FTP.
I'm running a client application that synchronises an FTP folder with a folder on the client computer.
It accomplishes this by uploading a file with a random name, then when the upload is successful renaming the file (it does this to avoid having to delete the destination file first before uploading it - a problem with large multi GB files over WAN links).
However, when it does the RNFR / RNTO combination it frequently gets "553 file exists" returned to it by the FileZilla server. This doesn't happen all the time, and the FTP user account in question has all access rights enabled. I've taken a look at the files in the filesystem itself and the "read only" attribute isn't set, likewise NTFS permissions are set to Everyone:Full.
What could be causing this, some kind of Oplock?
Thanks in advance.
My Server is FileZilla Server version 0.9.40 beta.
The connection between client and server is plain routed IP, no NAT anywhere to be seen. The connection uses passive FTP.
I'm running a client application that synchronises an FTP folder with a folder on the client computer.
It accomplishes this by uploading a file with a random name, then when the upload is successful renaming the file (it does this to avoid having to delete the destination file first before uploading it - a problem with large multi GB files over WAN links).
However, when it does the RNFR / RNTO combination it frequently gets "553 file exists" returned to it by the FileZilla server. This doesn't happen all the time, and the FTP user account in question has all access rights enabled. I've taken a look at the files in the filesystem itself and the "read only" attribute isn't set, likewise NTFS permissions are set to Everyone:Full.
What could be causing this, some kind of Oplock?
Thanks in advance.
Re: RNFR / RNTO produces "553 File Exists"
You cannot overwrite files with RNTO in FileZilla Server. If the target file already exists, you need to issue DELE to remove it before renaming another file using that target name.
-
- 500 Command not understood
- Posts: 3
- Joined: 2012-01-03 21:11
- First name: Austin
- Last name: Pass
Re: RNFR / RNTO produces "553 File Exists"
That seems fair enough.
I don't suppose some kind soul with a functional build environment could compile me a patched version according to this post?
http://forum.filezilla-project.org/view ... &sk=t&sd=a
I know that it isn't correct to permit RNTO to overwrite existing files, but it would make my life so much simpler!
I don't suppose some kind soul with a functional build environment could compile me a patched version according to this post?
http://forum.filezilla-project.org/view ... &sk=t&sd=a
I know that it isn't correct to permit RNTO to overwrite existing files, but it would make my life so much simpler!
Re: RNFR / RNTO produces "553 File Exists"
@botg: Is that a choice you made for FileZilla Server or is that behavior required in a standard?
No support requests over PM! You will NOT get any reply!!!
FTP connection problems? Please read Network Configuration.
FileZilla connection test: https://filezilla-project.org/conntest.php
FileZilla Pro support: https://customerforum.fileZilla-project.org
FTP connection problems? Please read Network Configuration.
FileZilla connection test: https://filezilla-project.org/conntest.php
FileZilla Pro support: https://customerforum.fileZilla-project.org
Re: RNFR / RNTO produces "553 File Exists"
A choice, the standard does not cover what should happen if a target file already exists.
On Windows, implementing the non-overwriting RNTO is easier, whereas on UNIX(-like) system its the other way around.
On Windows, implementing the non-overwriting RNTO is easier, whereas on UNIX(-like) system its the other way around.
Re: RNFR / RNTO produces "553 File Exists"
Understood.
No support requests over PM! You will NOT get any reply!!!
FTP connection problems? Please read Network Configuration.
FileZilla connection test: https://filezilla-project.org/conntest.php
FileZilla Pro support: https://customerforum.fileZilla-project.org
FTP connection problems? Please read Network Configuration.
FileZilla connection test: https://filezilla-project.org/conntest.php
FileZilla Pro support: https://customerforum.fileZilla-project.org
-
- 504 Command not implemented
- Posts: 10
- Joined: 2012-12-04 11:30
- First name: Goran
- Last name: Baotic
Re: RNFR / RNTO produces "553 File Exists"
Hi, botg, could you make this a feature request -- to be able to choose the setting how FZS responds to a RNTO command - overwriting, or non-overwriting. In my case, I have numerous Axis videoencoders which upload JPEGs rapidly to a FTP destination and do so by uploading files with temp (random) filenames, then issue RNTO, which in my case should overwrite.
-
- 500 Command not understood
- Posts: 4
- Joined: 2019-04-24 14:48
Re: RNFR / RNTO produces "553 File Exists"
My situation also requires this.
I looked at the ftp specification. https://tools.ietf.org/html/rfc959
And it just says
RENAME TO (RNTO)
This command specifies the new pathname of the file
specified in the immediately preceding "rename from"
command. Together the two commands cause a file to be
renamed.
So it doesn't say if the command should fail when the destination already exists.
In my experience other ftp servers let you rename onto existing files.
I looked at the FileZilla Server code and it does:
if (!MoveFile(RenName, physicalFile))
That could just be replaced with
if (!MoveFileEx(RenName, physicalFile, MOVEFILE_REPLACE_EXISTING))
And the above security checks relaxed.
This would be a really useful improvement.
I looked at the ftp specification. https://tools.ietf.org/html/rfc959
And it just says
RENAME TO (RNTO)
This command specifies the new pathname of the file
specified in the immediately preceding "rename from"
command. Together the two commands cause a file to be
renamed.
So it doesn't say if the command should fail when the destination already exists.
In my experience other ftp servers let you rename onto existing files.
I looked at the FileZilla Server code and it does:
if (!MoveFile(RenName, physicalFile))
That could just be replaced with
if (!MoveFileEx(RenName, physicalFile, MOVEFILE_REPLACE_EXISTING))
And the above security checks relaxed.
This would be a really useful improvement.
-
- 500 Command not understood
- Posts: 4
- Joined: 2019-04-24 14:48
Rename to replace
Hi Tim.
I did a post in the support area about getting an error from Filezilla Server when trying to do a RNTO onto an exiting file.
I really need to be able to replace files this way. We upload a temporary file then rename it to replace an exiting file.
This way the file will always exist in a complete state. Deleting then renaming doesn't achieve this.
In the other post I mentioned the code could be changed from MoveFile(RenName, physicalFile) to
MoveFileEx(RenName, physicalFile, MOVEFILE_REPLACE_EXISTING)
With tweaks to the security checking above.
Would you accept a patch for this?
Thanks.
I did a post in the support area about getting an error from Filezilla Server when trying to do a RNTO onto an exiting file.
I really need to be able to replace files this way. We upload a temporary file then rename it to replace an exiting file.
This way the file will always exist in a complete state. Deleting then renaming doesn't achieve this.
In the other post I mentioned the code could be changed from MoveFile(RenName, physicalFile) to
MoveFileEx(RenName, physicalFile, MOVEFILE_REPLACE_EXISTING)
With tweaks to the security checking above.
Would you accept a patch for this?
Thanks.
Last edited by botg on 2019-04-25 18:14, edited 1 time in total.
Reason: Move to appropriate topic
Reason: Move to appropriate topic