Opened 17 years ago
Last modified 11 years ago
#3170 closed Bug report
Verify Post-Upload
| Reported by: | hollasch | Owned by: | |
|---|---|---|---|
| Priority: | normal | Component: | Other |
| Keywords: | Cc: | hollasch, Alexander Schuch, Tim Kosse | |
| Component version: | Operating system type: | ||
| Operating system version: |
Description
When I transfer a large directory with thousands of files, I inevitably get a handful of zero-length files scattered throughout. My current workaround is to use the command-line FTP client (I'm on Windows XP) to "ls -lR" the entire site, then grep the results for zero-sized files, and upload those individually.
I would like to see an option in FileZilla to verify the size of each file after uploading, and retry the transfer on disagreement between the local and server versions.
Change History (15)
comment:1 by , 17 years ago
comment:2 by , 17 years ago
These files are on a web site I manage, so I suppose that it's possible the files in question were locked by the server. If so, that will be a common condition on an active website. I didn't have the log file set up (I do now). Finally, there were no alerts of any kind that the upload had problems. That is, the queue was completely emptied when finished, the all appearances suggested a problem-free upload.
I can continue working with you on this -- should I open a bug report and continue from there?
comment:3 by , 17 years ago
This item can be moved to any other tracker as well, so we can continue here.
Due to time constraints, I haven't tested latest nightly build of FileZilla 3 (beta) yet, but as far as I know, there is a working separate queue for failed items already. Anyway, can you please test a recent nightly build of FileZilla 3 (beta) as well?
comment:4 by , 17 years ago
Installed the 2007-0716 nightly build. Beta 10 used to crash on me part way into the upload (25000+ files), but the latest nightly worked fine. On top of that, it uploaded all changed files (8600+) without a single problem. First time I've seen that!
One problem with the latest build, though, is that I don't see a way to log debug information to a file -- am I missing something?
comment:5 by , 17 years ago
Well, I thought I'd try again with the 2007-0716 nightly build for a different set of files (again, about 8600, but different files than the prior comment), but this time I got one zero-sized file, though the failure queue was empty. Much better than it used to be, but it looks like the problem is still there. Again, I can't find a way to generate a log file, so that's about all I can give you.
comment:6 by , 17 years ago
FileZilla 3 doesn't yet have a way to log into a file rather than the message log. Maybe an option can be added... have to see.
comment:7 by , 17 years ago
Ah, I figured that a log file was just temporarily disabled. Shall I open a feature request for this? When I was using the rev 10 Beta, I would get random crashes when uploading files. Without a log file, I have nothing to offer the devs to help diagnose the issue.
comment:8 by , 17 years ago
As far as I know, BotG is working on this verify file size after transfer option. No ETA given, though.
You can file a feature request for logging to a file, if you like, but that doesn't mean that it will implemented any faster. It just makes sure that this feature is not forgotten...
With crashes you mean that FileZilla 3 beta 10 crashes on your computer? Random crashes are not very useful, as they just indicate a problem, but without any way to figure out where it is. If you can reliably crash a nightly build with a given set of instructions, those can be fixed. Without such instructions, you can use a nightly build, or compile your own version of FileZilla and enable all debugging options. Then, run it in a debugger, make it crash, and try to figure out what might be causing this. (Again, the best is a reproduceable crashing).
comment:9 by , 17 years ago
Right now I noticed that logging to file has been requested already, so no need for you to request it again.
[ 1514795 ] Message Log to file... more options please!
comment:10 by , 17 years ago
You mentioned that you had a single zero-sized file yet the queue said success. In that case, even a complete log wouldn't reveal more information, since the replies from the server indicated success.
I've looked at the code again, FZ3 sends all data and gracefully shuts down the transfer connection, then waits for the server's "226 Transfer OK" (or similar) reply to arrive. It might be possible that the server or any router/firewall in between drops the connection prematurely.
What size were the files that came up empty on the server?
comment:11 by , 17 years ago
Files that came up zero-sized on the server are all of various sizes. Some are 60KB images, some are 1.5KB HTML files.
comment:13 by , 17 years ago
Gave beta 11 a go on a tree of 10,000 files. I ended up with four bad empty files (with updated timestamps), but no crash. After that I did the upload again (with Overwrite if Newer), and the bad files were not updated (presumably because FileZilla is still looking only at timestamp).
comment:14 by , 17 years ago
Your configuration seems to be improper. Please run the network
configuration wizard and follow its instructions.
As long as the test at the end of the wizard fails, your
configuration is not correct.
Reopen only if the test succeeds and the problem did not go away.
comment:15 by , 17 years ago
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).
Did you check for the reason of those zero-sized files already? Was the file in use/locked when FileZilla tried to open it for upload? What does the message log show for those files? Any error when uploading them, or did they "silently" fail?