in reply to Walking a directory tree with net:FTP:find

The obvious question is: "Are you sure that the directory '/test1/in' exists and the ftp user has read permissions to it?". Should the directory be "./test1/in" or "~/test1/in" or maybe "test1/in"? I don't see anything glaringly wrong with the code in general.

  • Comment on Re: Walking a directory tree with net:FTP:find

Replies are listed 'Best First'.
Re^2: Walking a directory tree with net:FTP:find
by bdunbar (Initiate) on May 31, 2012 at 19:08 UTC

    The obvious question is:

    Good question. The answer is 'yes'. 
    ftp redacted@ftp2.redacted.com
Connected to redacted.com.
220 Redacted FTP service.
331 Please specify the password.
Password: 
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> cd /test1/in
250 Directory successfully changed.
ftp> ls
229 Entering Extended Passive Mode (|||55795|).
150 Here comes the directory listing.
-rw-rw-r--    1 227      101           308 May 29 20:47 TOMEN_12042000
+44.EDI
-rw-rw-r--    1 227      101           305 May 29 20:47 TOMEN_12042000
+45.EDI
-rw-rw-r--    1 227      101           308 May 29 20:47 TOMEN_12042000
+49.EDI
drwxr-xr-x    2 0        0               3 May 29 21:47 one
drwxr-xr-x    2 0        0               2 May 29 21:42 two
226 Directory send OK.

    [download]

    Should the directory be

    I'll run over and give that a shot. Thanks.
[reply]
[d/l]
Re^2: Walking a directory tree with net:FTP:find
by bdunbar (Initiate) on May 31, 2012 at 20:38 UTC

    I tried with "./test1/in", "~/test1/in", "/", and finally " ".

    Same result as noted in parent

    Finally I extracted the source from the article (to ensure it was clean, free of any krep that might have crept in while I've been thrashing) to a new file, saved to disk, made it executable. Same problem.

    Threw in a directory name that does _not_ exist 
    $ftpfind->finddepth (\&wanted, "/namethatdoesnotexist");
sub wanted {
 print "hello";
 print $_;
}

    [download]

    Same Error

    It is possible that when CPAN compiled Net::FTP::Find it ... got something wrong, screwed up the bits?

[reply]
[d/l]

      I doubt if it got corrupted by the installation process; it's a pure perl module so should be pretty straight forward.

      I'm working on a Windows machine w/Active perl at the moment and was moderately surprised to find there don't seem to be any ppm packages for that module generally available.

      Ah well, I went ahead and installed it manually and tried (a suitably modified version of) your script and am getting the same results locally.

      In poking around a bit, it looks to me like a bug in Net::FTP::Find::Mixin. Specifically, in line 116:

      if ($depth == 0) {
    next if $_ ne '.'; # <-- line 116
    $_ = $directory;
}

      [download]

      The logic seems backwards; I believe it should be eq not ne.

      if ($depth == 0) {
    next if $_ eq '.';
    $_ = $directory;
}

      [download]

      With that change made locally it works as I would expect... And on inspection of the Net::FTP::Find::Mixin CPAN page, there is an open bug report filed about this very problem, (Though it doesn't mention the above solution)

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom