RMD returns problematic response since 1.8.1

[larsen]

Hello,

we have a Xerox AltaLink C8035 that is used for scanning and stores PDFs via FTP. After I upgraded FileZilla Server from 1.8.0 to 1.8.1, the scanner stopped storing files as it seems it doesn't cope well with a changed error message.

Following are (what I hope) the relevant parts from the log. The scanner first tries to create and delete some directories (apparently checking for case-sensitivity).

With 1.8.0:

Code: Select all

xerox [Command] MKD /xcse7980
xerox [Response] 257 "/xcse7980" created successfully.
xerox [Command] MKD /XCSE7980
xerox [Response] 257 "/XCSE7980" created successfully.
xerox [Command] RMD /xcse7980
xerox [Response] 250 Directory deleted successfully.
xerox [Command] RMD /XCSE7980
xerox [Response] 550 Couldn't open the file or directory

With 1.8.1:

Code: Select all

xerox [Command] MKD /xcse6437
xerox [Response] 257 "/xcse6437" created successfully.
xerox [Command] MKD /XCSE6437
xerox [Response] 257 "/XCSE6437" created successfully.
xerox [Command] RMD /xcse6437
xerox [Response] 250 Directory deleted successfully.
xerox [Command] RMD /XCSE6437
xerox [Response] 550 Diese Funktion wird vom System nicht unterstützt.

The error message comes from Windows 10 (German) instead of FileZilla Server. At least, I don't think that FZ would produce a localized error message. Translates to "550 This function is not supported on this system."

What is the background for that change and could it be reverted or changed to adapt for this problem?
I will also try to contact Xerox support.

[botg]

The error message is a bug, but it should not affect the client in any way. The text of the message is intended for humans only. Programs should look only at the response code, and of that, one only needs the first digit.

[boco]

There is a little issue with the text being off, but actually, that text is completely irrelevant. All the client deals with is the response code, and that one hasn't changed at all. Any client evaluating the error text is doing it wrong, the text is for humans only.
Take ten different FTP server software packages, and you will have at least five different versions of the error text. Machine programs are supposed to read and interpret the response code, 550.

[larsen]

Alright, thought so. Hoping for Xerox support then.

Out of curiosity: What is the background for that change?

[boco]

It's the wrong text, it's a bug. Still, clients should never rely on the text portion of server responses. Unlike the response codes, texts are not standardized and there will be variations between server implementations.

[larsen]

Problem has been solved with 1.8.2

Xerox support states:

Engineering and Development team was able to recreate the customer scan to FTP issue with FileZilla 1.8.1 version.
On analyzing the device log, development team observed that the scan job got failed due to failure in obtaining the lock file and not able to enter passive mode. Getting 250 response code from the server which means command success but IP address and port were not provided. We believe the issue is with the Filezilla 1.8.1 version and not with the device.

<transferServ> (Tue Apr 30 2024 06:15:54.513) <p7104,t7136,lib/dcsftp/src/dcsftp_getreply.c, 229> debug>> FTP response code: 250
<transferServ> (Tue Apr 30 2024 06:15:54.513) <p7104,t7136,/genlib/dcsftp/src/dcsftp_data.c, 186> ERROR>> Cannot enter passive mode - FTP response code = 250
<transferServ> (Tue Apr 30 2024 06:15:54.513) <p7104,t7136,/genlib/dcsftp/src/dcsftp_data.c, 215> INFO>> init_ipv4_passive_data_conn RETURN: DCSFTP_DATA_SOCKET (failure

We tested with the latest FileZilla Version (1.8.2) which was released on 26th April 2024 and observed the scan to FTP job got completed without any issues.

[oibaf]

250 is a successful reply code that has nothing to do with passive mode. The response from Xerox is quite puzzling, to say the least.