Oddly, '$ftp->command("SITE CHMOD 755 $file")'and '$ftp->quot("SITE CHMOD 755 $file")' wouldn't hang the connection, and they would did successfully execute the chmod command via the ftp connection (I checked with an ftp client and every file in the base directory did show a successful chmod change), it just seemed to somehow corrupt the capacity to call cwd in any way, and always returned '' for the current directory, even though the ->quot was continuing to work for chmods.
I'll file this behavior in the 'mystery box' (as it is usually user error anyway) and keep using the site function, thanks again.
Wiggins D'Anconia wrote:
Rob Dixon wrote:
Hi.
[EMAIL PROTECTED] wrote:
I am trying to use the NET::FTP module to recursively chmod files. Either of these two ways of telling the server to chmod it seem to work:
$ftp->command("SITE CHMOD 755 $file"); or $ftp->quot("SITE CHMOD 755 $file");
I've never tried this, but the POD for my installation of Net::FTP doesn't mention a 'command' method, and for 'quot' it says:
WARNING This call should only be used on commands that do not require data connections. Misuse of this method can hang the connection.
'command' I *believe* is an underlying method of the Net:: base modules, which is why the warning is attached.
...but once that runs once, even successfully, $ftp->pwd() returns an empty string afterwards, and no files are found if I cwd to valid directories.
I know the FTP section is working right, I can watch it run through every file and folder in the cgi-bin recursively, *if* I comment out the CHMOD line.
If I leave that line active, it does CHMOD everything in the base dir, but can't cwd after the first CHMOD.
Does anyone have any ideas of why this may be happening?
There is a 'site' method. Again I've never used it, but as a long shot you might try:
$ftp->site("CHMOD 755 $file");
or variations on that.
The 'site' method *should* work similar to what he has, it essentially sends a SITE before a string of values similar to the way command/quot would work. Which brings me to....
Because of the nature of SITE commands being implementation specific have you determined whether this will actually work on the FTP server implementation. In other words, before digging around in Net::FTP for a bug or inconsistency try firing up a telnet <host> <port> session and sending an actual FTP session string including these commands and see if how the server reacts, and if it reacts correctly. Because Net::FTP is just sending strings back and forth (at least until a data transfer) it is unlikely (not impossible) that it is something on the client end...
I am assuming that you know for sure that the remote host is actually based on a filesystem (aka has directories, unix type permissions, etc.)?? Shocked me the first time I dealt with a record based mainframe via FTP...
http://danconia.org
-- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
