FTP PWD issue

AndMaz

Hi

It seems that FTP server responds with an empty string when I cd into a dir then cdup back to parent dir and then execute pwd

A proper response should include /. This issue breaks my FTP client

Update I can also repro the issue in FileZilla. Here are the logs

12:02:00	Status:	Logged in
12:02:00	Status:	Retrieving directory listing...
12:02:02	Status:	Directory listing of "/" successful
12:02:06	Status:	Retrieving directory listing of "/backup"...
12:02:09	Status:	Directory listing of "/backup" successful
12:02:13	Status:	Retrieving directory listing of "/"...
12:02:13	Command:	CWD /
12:02:13	Response:	250 Directory successfully changed.
12:02:13	Command:	PWD
12:02:13	Response:	257 ""
12:02:13	Error:	Server returned empty path.

dc42

@AndMaz thanks for reporting this. Can you point me to where in the FTP protocol specification it says that the response should be "/" ? I looked in RFC959 but didn't find it.

AndMaz

@dc42 thanks you for quick answer.

I can't point to exact place in RFC959 where it states that root is / but empty string as PWD doesn't seem to be correct. I mean, the working dir can't be empty. In Unix-like systems the root directory is denoted by the / sign.

Initially I assumed that the problem came from my FTP client but the issue also happens in FileZilla, that implements all the FTP-related RFCs properly (at least I hope so)

dc42

@AndMaz I've just tested FileZilla with two Duets:

So it appears to be returning "/". Wireshark confirms this.

Which version of RRF are you running?

AndMaz

@dc42 I'm using 3.4.2.

What version did you use during your tests?

dc42

@AndMaz I am using 3.5beta but I don't think anything has changed in that area. I can re-test using 3.4.5 tomorrow,

dc42

@AndMaz I just tested it using 3.4.5 on one of the machines, and it still works.

AndMaz

@dc42 thank you. I guess that I bumping firmware version will solve it

AndMaz

@dc42 BTW in your tests did you cd into some dir then cdup? I'm asking this because the pwd right after connecting works properly, i.e., no bug

dc42

@AndMaz I managed to provoke this twice by doing CDUP and then selecting the root:

I will fix it in RRF 3.5beta3 and 3.4.6.

AndMaz

@dc42 thank you for https://github.com/Duet3D/RepRapFirmware/commit/f5fa23c3fd9eab9dc97cbefe317c3b0ee31cdf71

Unrelated Is is possible to add a recursiveDelete (default to false) to GET /rr_delete ? At the moment it's doesn't seem to be possible to remove a dir if it contains something inside. I would like to avoid overloading HTTP server with a bunch of delete reqs.

0

dc42 committed to Duet3D/RepRapFirmware

Fix for FTP change to root directory (included in 3.5beta2 release)

T3P3Tony

@AndMaz I have moved this to the firmware wishlist and that is a new feature.

AndMaz

@T3P3Tony thank you. Do you want me to create a dedicated ticket for this?
(This started as a FTP issue but then ended with a HTTP feature request)

T3P3Tony

@AndMaz yes probably better if you do, with a descriptive title. Then you can make this thread as solved. thanks!

AndMaz

@T3P3Tony don't know how to mark it as solved but here it goes

Update The original issue is solved https://github.com/Duet3D/RepRapFirmware/commit/f5fa23c3fd9eab9dc97cbefe317c3b0ee31cdf71 and released in v3.5beta2 (Link https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x-Beta#reprapfirmware-350beta2)

0

dc42 committed to Duet3D/RepRapFirmware

Fix for FTP change to root directory (included in 3.5beta2 release)