Potential Bug in BeginGetFileInfos on SecureFTPConnection

Question

We are currently using edtFTPnet/PRO 8.6.4, and we are encountering an issue where if an FTP server has a folder with another folder within it that has the same name (ex. //Test/Test), when we try to execute BeginGetFileInfos on the first folder (ex. //Test), the FTPFile objects that are directories with have the wrong Path values because it is doubling up on the folder name for each folder object. Ex. //Test/Fubar has a Path value of //Test/Test/Fubar.

Is this a potential bug, or maybe some issue in our implementation? Is there a work around?

EDIT: I think I am seeing this happening everywhere now! When I go into a folder from the top level, it doubles up on that folder in the Path of the children directories.

I will investigate our implementation as well.

EDIT2: We are also changing the working directory before doing the get on file infos. They are both on background threads though, so I wonder if the later is finishing before the former and could be causing the issue.

Comments

If you don't find the problem then can you please open a ticket (enterprisedt.com/help) and include a debug-level log that illustrates the problem?

---

Logging tells me the calls are synchonious.

I found that commenting out the change working directory call would cause it to work. If I change the work directory, will that change be reflected in the Path property of any FTPFile objects I generate?

---

You need the change working directory call to be completed before calling BeginGetFileInfos. Yes, the new directory should be reflected in the Path property.

---

One last question: If GetFileInfos is called with a null parameter, will it be the same as GetFileInfos without a parameter? Which is to say, it will give the contents of the current working directory?

It is what I am observing, but I want to be sure. If it is the case then maybe I have a work around.

---

Yes, it's the same.

Answer 1

Then I have a workaround. Marking this as answered.