Recursive directory deletion in client 3.3.5.1
Posted: 2010-12-30 20:50
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
- 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