Opened 12 years ago

#8055 new Bug report

Queued files with relative paths puts folders in the wrong place

Reported by: Chris Mandrusiak Owned by:
Priority: normal Component: FileZilla Client
Keywords: Cc:
Component version: Operating system type: Windows
Operating system version: Windows 7



When I import XML to generate a transfer queue, and the files in the XML have relative paths for the remote file I get some strange behaviour depending on which settings are used.

Let’s say I have 2 files to be processed, folder1/file1.txt and folder2/file2.txt => Note the 2 file paths are relative paths, not absolute

If I have set up a maximum of 1 simultaneous transfers *

  • The first file is uploaded to /{home directory}/folder1/file1.txt
  • When that completes, the second file starts and because it is relative path adds to the current path, so it gets uploaded to /{home directory}/folder1/folder2/file1.txt

I presume this is because FileZilla reuses the connection, and so after the transfer the current folder is folder1, not the home directory. The second one then just adds to it.

If I have the queue set up to more than 2 or more simultaneous transfers
Then this time, because 2 connections are made, they both get changed relative to the home directory and so I get the files placed here:-

  • The first file to /{home directory}/folder1/file1.txt
  • The second file to /{home directory}/folder2/file2.txt

Depending on the number of threads I have to upload I get totally different results! Another reason I am pretty certain it is a bug is that because if the XML file used puts all the files in the same batch folder, then regardless of the using 1 or multiple threads, they always go in the same folder! So similar example, there are 2 files samefolder/test1.txt and samefolder/test2.txt. When this runs with either 1 or >=2 threads the files are uploaded to:-

  • The first file to /{home directory}/samefolder/file1.txt
  • The second file to /{home directory}/ samefolder /file2.txt

That goes totally different to what you expect after my test above

* The number of connections does not actually have to be 1, it just has to be less than the total number of files being uploaded. So if I have 5 files going to 5 different folders, I would get the bug happening if I used 1, 2, 3, or 4 connections. If I used 4 connections however, then 4 of the files would upload properly and only the 5th file which reused an older connection puts the folder in the wrong place.

Tested with version 3.5.3


Change History (0)

Note: See TracTickets for help on using tickets.