Page 1 of 1

Recursive directory deletion in client 3.3.5.1

Posted: 2010-12-30 20:50
by dynoman
Hi, I've got a similar problem as in topic #15194 where the server is an old-style DOS-like tool and I want to enable recursive directory deletion (like in topic #15194 and #11742). I'm running version 3.3.5.1 on Win7. Here's some relevant posts I found in the forum, following those is what I'm seeing now.
- Recursive Delete fails with FileZilla client 3.3.2: 2010-03-04: http://forum.filezilla-project.org/view ... =2&t=15194
- Unable to delete sub-folders: 2009-05-20: http://forum.filezilla-project.org/view ... =2&t=11742
- Recursive Directory Compare: 2010-10-28: http://forum.filezilla-project.org/view ... =3&t=18132

There are no filters and "force show hidden files" is enabled (but there aren't any). In topic #15194 Jonkr wrote: "When I select a non-empty folder and press delete, every file in that directory is deleted as expected. FileZilla also recursively traverses into any subdirectories, and correctly list any files therin.". That was with client 3.3.2. With the 3.3.5.1 client, the recursive portion appears to have been snipped. My logs show only the deletion of the files in the directory and then the attempt to remove the directory.

In topic 18132 botg wrote about recursive operations: "FileZilla would have to traverse the entire directory hierarchy which would be a very slow, potentially endless operation.". The only endless part would be if symbolic links created a cyclic path. I'm not knowledgeable enough about FTP to know if the protocol allows distinguishing between those. But since there is a "Stop" button, I'm not worried about the small chance of cyclic paths during recursive operation.

One of our regular tasks is erasing a directory tree on a server prior to uploading a similar tree. This eliminates the stale nodes (sub-directories) and leaves (files) that may be left over. The FTP server is on an embedded system and we can't change it. That means that recursion must be used, either manually or via scripts. What I've had to use in the past is WS_FTP from IpSwitch which has a "delete non-empty directories" setting that basically tells it to do the recursive search and delete all files found in the subdirectories before removing the target directory.

That can take 15-20 minutes on a large tree, but it's better than having to remove the flash (with its Win32 FAT file system) from the embedded system, load that on a Windows PC, just to delete the tree (which still takes 10 minutes because even windows still has to do the recursion). This is one of those cases where recursion must be used or the feature can't be enabled.

Is the avoidance of a potential infinite recursion (due to cyclic path from a symbolic link) worth not having the ability of deleting populated directory trees? I vote No :).

Is someone here familiar enough with the source code that they could point me to some files? Having been a programmer (and now a "Software Engineer") for over 30(!) years and having coded in C and C++ for over 15 years now, I'm sure I could do this work (presuming that the code base isn't too twisted from the years of maintenance on it). But I hesitate to launch into this if it won't get accepted back in the main build.

Steve

Re: Recursive directory deletion in client 3.3.5.1

Posted: 2010-12-30 21:44
by botg
How _exactly_, down to every click and button press, are you initiating the deletion?

Can you please paste a complete, unmodified log of such a failed deletion attempt with "Show raw directory listings" enabled in the settings dialog?

See http://filezilla-project.org/sourcecode.php for the source code.

Re: Recursive directory deletion in client 3.3.5.1

Posted: 2010-12-30 22:16
by dynoman
botg wrote:How _exactly_, down to every click and button press, are you initiating the deletion?
Having connected and logged in, I right-clicked the target directory in the Remote file list pane, selected "Delete" from the context menu, and answered Yes to the "delete..." dialog.
botg wrote:Can you please paste a complete, unmodified log of such a failed deletion attempt with "Show raw directory listings" enabled in the settings dialog?
Attached. Having found where the debug log options are set and having set them, I see now that it is still doing the full recursive descent, but it's not issuing the delete on the sub-contained files.
botg wrote:See http://filezilla-project.org/sourcecode.php for the source code.
I am employed full-time and maintaining (with 4 others) over a million LOCs. I don't mind helping out, but I was hoping for some clues like "check in function DeleteDir() in file foo.c in directory process/command.", or whatever the appropriate pointer text is. Basically I'm not sure when I can get the time to scan the entire FTP Client code base to find where the entry points for a "small" change (like deleting the sub-contained files) are. Note that my editor (Visual SlickEdit) has very rich and powerful navigation tools with which I can try to avoid ripple effects (if a global had to be changed or a function tweaked). Perhaps just grepping the tree for Delete would work?

Thanks!
s

Re: Recursive directory deletion in client 3.3.5.1

Posted: 2010-12-31 10:29
by botg
Interesting, a server with DOS-style path syntax.

Good starting point would probably be src/interface/recursive_operation.cpp and likely src/engine/serverpath.cpp as well.

Re: Recursive directory deletion in client 3.3.5.1

Posted: 2010-12-31 11:11
by botg
The problem is that even though your server uses a DOS-style path syntax but instead of proper backslashes uses ordinary slashes. Very exotic, I cannot think of any reason why anybody would possibly create such a server.

Re: Recursive directory deletion in client 3.3.5.1

Posted: 2010-12-31 13:49
by botg
A fix has been committed.

Re: Recursive directory deletion in client 3.3.5.1

Posted: 2010-12-31 18:41
by dynoman
botg wrote:The problem is that even though your server uses a DOS-style path syntax but instead of proper backslashes uses ordinary slashes. Very exotic, I cannot think of any reason why anybody would possibly create such a server.
"Exotic", yeah, that's the word I was looking for! :lol: It's an ancient legacy FTP server piece from the days of DOS 3.1.

s

Re: Recursive directory deletion in client 3.3.5.1

Posted: 2010-12-31 18:57
by dynoman
botg wrote:A fix has been committed.
:D WooHoo! Thank you much! You da man! 8) I'm off today, but I'll give it a try when I can figure out the download. We're using CVS and so I haven't yet learned or installed SubVersion (although I know a half-dozen other older source-code-control systems). I just got a new computer (Windows based) and so I'm actually loading all new software on it. We're using an ancient cygwin (because of the ancient kernel that we're tied to), so I'll have to get a different compiler also.

Again, Thanks!

Steve

Re: Recursive directory deletion in client 3.3.5.1

Posted: 2011-01-01 14:38
by boco
I guess downloading the nightly build should do it. It's created every night and is a snapshot of the current dev code.

Re: Recursive directory deletion in client 3.3.5.1

Posted: 2011-01-03 18:45
by dynoman
boco wrote:I guess downloading the nightly build should do it. It's created every night and is a snapshot of the current dev code.
Thanks Boco!

I looked at the "nightly downloads" page and saw various choices, but none of them said "windows". I guessed i586-mingw32msvc because it had two downloads available (guessing client and server) and since it's got both a "w32" (win32) and a "msvc" (microsoft service?). And sure enough, the "FileZilla_3_setup.exe" has the client for Windows.

I tested that against our creaky DOS-like server and the delete now works!

The changelog says "codesquid" checked in a change to serverpath.cpp (version 3936) while I thought it was "botg". My guess is that the public view (web interface to the repository) hides some details.

But my thanks to whomever! :D

s

Re: Recursive directory deletion in client 3.3.5.1

Posted: 2011-01-04 01:14
by boco
a "msvc" (microsoft service?)
Microsoft Visual C
The changelog says "codesquid" checked in a change to serverpath.cpp (version 3936) while I thought it was "botg".
Very same person, just the names are different in the project tracker (Trac).