on 14/3/02 11:06 PM, Dave Cragg at [EMAIL PROTECTED] wrote: > I don't think a standard has been defined, but the convention seems > to be to return the listing in standard Unix style, at least on all > the ftp servers I've checked with, including those on Windows. (I've > no idea about Classic Mac OS ftp servers.) As you note, the popular > ftp clients seem to rely on this. I've done a bit more research - it's a common convention, but it's not universal. On the IIS FTP servers with Windows NT/2000, for example, there are controls to choose between 'unix style' and 'ms-dos style' directory listings. I guess the popular FTP clients have had to build parsers for each format - which is fine, but in this case the only thing we want is the name of each file, and whether it is a directory or not.
And I've still not found anything which expresses whether, given the "unix style" there are formatting rules we can rely on. Eg if the username 'owner' for the file has a long username with a space on it - does this get cropped so that subsequent columns start at the same character position? or does the space get translated in some way so that you can count gaps to delimit colummns? or do you have to make a smart parser that goes from both ends at once, and hope you don't have a file named "Nov 19 1997 stuff" owned by a user called "Joshua K. Molinsky". Or just give up and fantasise about a world in which the authors of the FTP RFC, observing that the LIST format was more useful to humans than computers, devised an alternative format with the same data in a format useful to computers - instead of NLST! > One problem with using NLST is that it makes no distinction between > files and directories. You'll have to parse out the file extensions, > assuming all the files have one. Yes - in our situation we can't rely on file extensions, so we were considering simply testing each filename returned by NLST as if it were a directory - but this could be very inefficient. The other idea would be to get both LIST and NLST listings, and compare them (optimistically hoping that they at least return the files in the same order) - using the data returned by NLST to pick off the correct number of characters at the end of each line as a check, and if they match then using the flags at the start of each line to see if it's a directory (though that still is format dependant, ie a DOS listing you need to check for "<DIR>" in the middle of the line....) I guess it's a toss-up as to whether it's more or less inefficient to get two listings for each directory, or to test every file as if it was a directory - or bite the bullet and write parsers for Unix and DOS, test on as many servers as we can, and wait for bug reports as our users find more variations. Either way, I think it would be useful if there was a way to get NLST listings out of the FTP library. Ben Rubinstein | Email: [EMAIL PROTECTED] Cognitive Applications Ltd | Phone: +44 (0)1273-821600 http://www.cogapp.com | Fax : +44 (0)1273-728866 _______________________________________________ improve-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/improve-revolution
