LIST * returns files not inside PWD

0 votes
asked Jun 21, 2012 by CER (420 points)
edited Jun 21, 2012

I have a problem with my rebex component with single customer accessing an external ftp site (over a closed line, cant get access to it from the internet). The ftp server returns the following when connecting from filezilla

Command:    SYST
Response:   215 UNIX Type: L8
Command:    FEAT
Response:   500 FEAT not understood.
SupportedFeatures on the Ftp instance returns 0, probably because the FEAT command is not supported by that server.

The problem is that LIST * returns stuff not actually inside the current directory /datamover/users/xxx/customer which is empty. if i changedirectory to that subfolder and calls getrawlist(*), it returns

        .:
        ..:
        -rw-rw-rw-   1 0        1        51 Sep 14  2006 RIGHTSLIST.LIS
        drwxrwxrwx   2 xxx    355      1024 Jun 21 06:15 customer
        drwxrwxrwx   2 xxx    355      2048 Jun 21 06:15 hold
        drwxrwxrwx   2 xxx    355      9216 Jun 21 09:26 xxxxx

and GetList("*") correctly misinterprets this as if RIGHTSLIST.LIS is in the current folder, although its in the root folder.

Command sent LIST .
Response read 150 Opening ASCII mode data connection for file list
Response read 226 Transfer complete. 247 bytes transferred
        RIGHTSLIST.LIS (File)
        customer (Directory)
        hold (Directory)
and GetNameList(*) more correctly returns
Command sent NLST .
*Response read 550 No files found.
and throws Rebex.Net.FtpException: No files found (550). which is fine, because there are no files in the subfolder.

My application uses GetList("*") in many places and fails on all of them for this single server. Any advice on how I can get Rebex ftp to use NLST instead of the LIST command?

/Christian

commented Jun 21, 2012 by Lukas Pokorny (106,330 points)
edited Jun 21, 2012

Just to make sure I understand this correctly - the server actually returns a file in the listing that is not in the current folder. Is this correct? Does Filezilla display that as well?

3 Answers

0 votes
answered Jun 21, 2012 by Lukas Pokorny (106,330 points)
edited Jun 21, 2012

The problem with NLST (and therefore the GetNameList method as well) is that it only returns a list of file names - with no additional information. To see what it actually returns, try calling GetRawList("*", FtpListingType.NameList).

Unfortunately, this means it's not possible to use NLST to replace LIST because it doesn't return the information required - in other words, GetList with NLST would be no different from GetNameList - the listing would only contain the file names.

What about the following alternatives?

  • Use GetNameList instead of GetList in your application when working with this server.
  • Call both GetNameList and GetList and use GetNameLists results to check whether files returned by GetList actually exist.
  • Keep using GetList, but before working with a file, call FileExists method to check whether it really exists.
0 votes
answered Jun 21, 2012 by CER (420 points)
edited Jun 21, 2012

Well, GetList() works an all other servers I have encountered. GetNameList() does not touch files in the wrong folders, and I did call GetRawList("*") as you can see above - it returns the data from the wrong folder.

But - I just found a very good solution myself.

Cant explain why, but if i give an empty string "" as filepattern instead of the "*", GetList("") works exactly as expected. So, drop the "*", or "*.*" and use "" instead, and everything works

0 votes
answered Jun 21, 2012 by Lukas Pokorny (106,330 points)
edited Jun 21, 2012

Thanks for letting us know! Actually, it is not very surprising and I should have probably pointed out that using LIST or NLST commands is problematic. See the remarks for GetList method in the API guide:

The meaning of the arguments argument is not defined by RFC and varies from server to server. Some servers interpret it as parameters to dir command, some as a filename, some ignore it and some report an error. Calling this method with arguments other than null is not recommended and will make your code incompatible with many FTP servers.

...