Opened 15 years ago
Last modified 15 years ago
#3627 closed Bug report
Filezilla does not handle low diskspace conditions correctly
|Reported by:||watzo||Owned by:|
|Keywords:||Cc:||watzo, Tim Kosse|
|Component version:||Operating system type:|
|Operating system version:|
OS: Windows XP SP2
Filezilla version: 3.1.0
- steps to reproduce:
- download one or more files exceeding the available disk space
- actual result:
- Filezilla logs the transfer failure in its log pane (Error: error while writing local file)
- the incomplete file(s) are left in the directory
- the transfers do not show up under failed transfers
- expected result:
- the transfers are added to the failed transfers pane
- no remnants of the incomplete file remain in the target directory (in general I would appreciate a more atomic approach to Filezilla's transfers, e.g. first download to a temporary directory, move to final destination after successful transfer).
Change History (2)
comment:1 by , 15 years ago
comment:2 by , 15 years ago
Please try the upcoming 2008-07-26 build from http://filezilla-project.org/nightly.php
Reopen if a failed transfer does not appear in the failed tab.
Note: See TracTickets for help on using tickets.
That's the actual bug.
Two options for that:
Deleting incomplete file is a bad choice. Imagine you transfer a multi-gigabyte file over a slow connection and near the end the disk becomes full. Lots of wasted time and bandwidth.
The other option is not possible to implement reliable across all supported systems. Moving files around can take a lot of time, if source and target are on different drives, partitions, network shares and so on. Even on Windows, if there's a directory C:\FOO, it might actually be just a mountpoint for drive D:
In other words, it will take a lot of resources to move files from C:\SOMETHING to C:\FOO
Even renaming files in one and the same directory can be an expensive operation, for example if using union filesystems.