"Target file already exists" When downloading into an empty folder

[RealVanDoor]

I have been having this issue with FileZilla for years but it seems to come and go. Maybe it is a server issue or something else but I really would like to better understand this behavior.

I start with an empty folder on my local drive. Then I log into one of my websites and drag a folder from FileZilla to the empty folder. Sometimes (not always) FileZilla will work for awhile and then stop to say "Target file already exists". Well, it did not exist before I started downloading the folder with FileZilla so I kinda expected that, if FileZilla put the file there it would know that!

So, at this point in a download I do not really know what to do, especially when the file sizes are different. Do I skip the file, leaving the download from earlier in the session intact? Or do I overwrite the file with the new one FileZilla is trying to download? There is really no way to know unless I compare the two files and that kinda defeats the whole idea of batch downloading/uploading!

So, I guess, in a nutshell, I am wondering if I have some setting wrong? Or maybe there is a work-around for this? Or some best practice?

Ideally, in a situation like this, I'd want my FTP client to check the file on the server and compare to the one it previously downloaded and make the best decision but maybe I am missing something here. What is it that triggers FileZilla to attempt to download the same file it previously downloaded? If it is an error from before then wouldn't that be the answer right there? Previous file caused an error so previous file=bad!

Sorry to go on and on but this has always been one of those niggling things that bug me about this awesome software and I never bothered to ask about it before. If anyone can help or point out where I am doing something dumb that would be soooo appreciated!

[RealVanDoor]

After a bit of further research I have discovered two separate issues...

1) I had several images with the same filename but different case! so, for example, ThisFile.jpg and thisfile.jpg, are treated as two separate files on my Linux host but when FileZilla downloads those files to my local Windows 10 folder it sees those as the same file. This is easy for me to fix but it would be better if FileZilla could recognize that problem and throw a more specific error.

2) Out of about 1,000 php files I had 4 or 5 that had the "Target file already exists" error so every time the error occurred I made a copy of the file already downloaded and then chose to have FileZilla overwrite. But, in every single case the files are identical!

So, if anyone has any thoughts about my #2 issue above I'd greatly appreciate it!

[boco]

1) I have to pass that question to the developer (who should visit this topic,soon). Without knowledge of the innards of FileZilla, I cannot make assumption if and how a detection of POSIX conflicts is even possible.
Those conflicts are one of the reasons why POSIX files that have to be transferred over potentially incompatible platforms/filesystems are usually distributed as tarball.

2) Usually, when the server or network throws an error (which happens then-and-when), FileZilla will resume the transfer where it left off. The problem is the Data Type of the files transferred. Binary (TYPE I) files are fine.
But PHP files are text files and as such usually transferred as ASCII (TYPE A)*. Text files undergo line ending conversion in some cases, so their file size can vary slightly between platforms. For this reason, resuming of ASCII files is not possible.
In other words: FileZilla cannot resume ASCII files, thus you get prompted what to do. If you know the directory was empty, before, and you excluded a case of 1), you can usually just select Overwrite.

*You can select to transfer all files as Binary in the settings. But in case of editing the files on Windows, you need an Editor that can handle UNIX line endings. Notepad++ is fine (do not convert the file to Windows type, though). Windows Editor is not!

[botg]

Things like this are to be expected if using multiple files with too similar names. Different operating systems, even individual file systems, have different rules what makes a filename unique.

The only workable solution is to avoid having two filenames that differ only in case.

[RealVanDoor]

Things like this are to be expected if using multiple files with too similar names. Different operating systems, even individual file systems, have different rules what makes a filename unique.

The only workable solution is to avoid having two filenames that differ only in case.

Fair enough but what about the php files? FileZilla said they already existed and even reported differing file sizes but, as I described above, the files were identical.

[RealVanDoor]

1) I have to pass that question to the developer (who should visit this topic,soon). Without knowledge of the innards of FileZilla, I cannot make assumption if and how a detection of POSIX conflicts is even possible.
Those conflicts are one of the reasons why POSIX files that have to be transferred over potentially incompatible platforms/filesystems are usually distributed as tarball.

2) Usually, when the server or network throws an error (which happens then-and-when), FileZilla will resume the transfer where it left off. The problem is the Data Type of the files transferred. Binary (TYPE I) files are fine.
But PHP files are text files and as such usually transferred as ASCII (TYPE A)*. Text files undergo line ending conversion in some cases, so their file size can vary slightly between platforms. For this reason, resuming of ASCII files is not possible.
In other words: FileZilla cannot resume ASCII files, thus you get prompted what to do. If you know the directory was empty, before, and you excluded a case of 1), you can usually just select Overwrite.

*You can select to transfer all files as Binary in the settings. But in case of editing the files on Windows, you need an Editor that can handle UNIX line endings. Notepad++ is fine (do not convert the file to Windows type, though). Windows Editor is not!

Thanks! So, overwrite is the safe choice when copying from server to local, initially empty, folder?

[boco]

In that case you're only overwriting the file stub that was created just before the transfer broke.

[john_geilo]

is there any update? i have the same problem. when copy a lot of files from my windows machine to the server, filezilla says some files already exist. as if filezilla copy it 2times.

some files are 0KB in the target, others are the same filesize.

[Ahem2203939]

Thank you so much for your insight, @boco! I have another question that's related. Some files that I've transferred have shown up as much as 2x larger on the target machine when giving me the "Target file already exists" error. One such file, for example was a .jpg, so I can understand how lots of NLCR's might end up in a file like that, but one was a .min.js file, so I don't see how the file could end up 1.5x as large on the target machine just from new lines. Any ideas?

[Ahem2203939]

Here's some additional information I found. One image that I downloaded came up as two very different sizes between the source and target machines. In line with what @boco said, the filenames differed only by case (i.e., AAA.jpg vs. aaa.jpg). Also, the server had both types of filenames stored on it, each at one of the corresponding sizes from the original error. Downloading the lowercase file to compare with the uppercase one (I had to try a couple times to get the sizes and filenames to match what was on the server), I then found that the lowercase file would not show up through the File Explorer in Win8.1 even though it did show up through the Filezilla interface. I then downloaded (again, took a couple tries) the filesize to uppercase names but in both different sizes. Then, when I looked at the files in an image client (MSPaint, for example), they both appeared to be exactly the same size, same image, same quality, everything.

However, other files that had shown significantly different file sizes when I got the "Target file already exists" error in Filezilla. Those files, as I investigated by re-downloading them to a different folder after having initially skipped them, ended up different. The files were truncated. Again, that corroborates what @boco said.

Finally, I caught various error messages going by in the log pane of Filezilla. I wasn't producing a log file at the time but I did manage to copy and paste some of the relevant errors. For example:
Status: Starting download of /wp-includes/SimplePie/IRI.php
Command: PASV
Error: Disconnected from server: ECONNABORTED - Connection aborted
Error: File transfer failed
Status: Disconnected from server
Status: Resolving address of customersite.com //obscured for client privacy
Status: Connecting to 89.67.789.334:56... //obscured for client privacy
Status: Connection established, waiting for welcome message...
Status: Initializing TLS...
Status: File transfer successful, transferred 29,597 bytes in 1 second
Status: Starting download of /wp-includes/SimplePie/File.php
Status: Verifying certificate...
Status: TLS connection established.
Status: File transfer successful, transferred 9,970 bytes in 1 second
Status: Starting download of /wp-includes/SimplePie/Exception.php
Status: Logged in
Status: Starting download of /wp-includes/SimplePie/Item.php
Status: File transfer successful, transferred 2,238 bytes in 1 second
Status: Starting download of /wp-includes/SimplePie/Enclosure.php
Status: File transfer successful, transferred 28,867 bytes in 1 second
The file in question, IRI.php, had been successfully transferred completely.

Interesting stuff.

[boco]

Local files that are much larger than the remote ones should only occur if the host is using an ancient IIS FTP server with broken Resume support. In that case, the server would send the correct offset but send the file again from the start.

[Ahem2203939]

Incredible information, @boco. Thank you!