List files and inconsistent paths

Question

I am confused by the way this library works. The confusion has led to alot of convoluted code and I need help straightening it out.
I have a server (filezilla's FTP server for windows) that hosting 2 ftp users (user1 and user 2). The root of user1's "home" or root folder is actually c:\ftp\users\user1 and the root of user2's ftp folder is actually c:\ftp\users\user2. In each case, when they log in via a normal ftp client, there is no available parent directory as their users have a virtual root of whatever the home folder is (meaning they can cd ..)
My problem is that I am having trouble listing these directories and getting consistent results.
For instance, I execute ftoClient.dirDetails("/") for user1, I get an array of FTPFile objects (actually an array of 1) with the following details:
[ {
group: "ftp",
isDir: false,
name: "text.txt",
path: "///",
size: 151,
lastModified: 1297377540000,
... other attributes omitted
}
]

Now later, I loop through this array and I do a dirDetails() against the contents of the name attribute (text.txt) and I get the following:
[ {
group: "ftp",
isDir: false,
name: "text.txt",
path: "//text.txt",
size: 151,
lastModified: 1297377540000,
... other attributes omitted
}
]


So now I have several questions:
1) why is the path inconsistent ("///" vs "//text.txt") when listing directory details of a directory vs listing directory details on a file? It is the same object each time. Shouldn't it have the same path regardless of which object is the root?
2) why does the path start with 2 extra "/" characters in both cases? The root is actually "/", There is no possible way a filename can start with 2 "/".
3) shouldn't calling dirDetails on a file (as apposed to a directory) result in some kind of exception?
4) is there a more consistent way to get FTPFile objects based on paths?

Answer 1

Servers are quite inconsistent with how they behave listing directories - some accept no parameters, and some accept a filename as the parameter, and list only that file.

The most reliable way of listing a directory is to change into that directory, and use dirDetails("").

Answer 2

OK Per bruce's suggestion, I change the directory listing from

ftpClient.dirDetails("/") ;

to

ftpClient.chdir("/");
ftpClient.dirDetails("");

Now the first listing has a path that makes sense but I still can't figure out how to get the FTPFile object based on a specific path. the above file listing yields the following list:

[ {
group: "ftp",
isDir: false,
name: "text.txt",
path: "/",
size: 151,
lastModified: 1297377540000,
... other attributes omitted
}
]

Now, when I loop through this array and I do a dirDetails() against the contents of the name attribute (text.txt) and I get the following:
[ {
group: "ftp",
isDir: false,
name: "text.txt",
path: "//text.txt",
size: 151,
lastModified: 1297377540000,
... other attributes omitted
}
]

So there appears to be no consistent way to get the FTPFile object based on the specific path to a file. If there is, I would appreciate some advice on this.

Answer 3

Ok I change the second ftpClient.dirDetails("text.txt") to this:

FTPFile file=ftpClient.fileDetails(path);

Now I get even crazier results for the path:
{
group: "ftp",
isDir: false,
name: "/text.txt",
path: "\"Listing /text.txt\" (id=104)",
size: 151,
lastModified: 1297377540000,
... other attributes omitted
}


This is even more useless than the crazy paths from dirDetails("text.txt") because now the filename is different too! Someone please help. I am starting to feel My project may be dying on the table!!!

Answer 4

There certainly does seem to be a bug there somewhere.

Can you use the size() and modtime() methods instead? These pertain to individual files rather than whole directories.

- Hans (EnterpriseDT)