Bug 355871

Summary:	krusader move operation check for free space on destination solely at the beginning of transfer, leading to spurious "disk is full"
Product:	[Unmaintained] kio	Reporter:	Nicholas Alexander <nicholas.v.alexander>
Component:	general	Assignee:	David Faure <faure>
Status:	RESOLVED MOVED
Severity:	normal	CC:	davide
Priority:	NOR
Version:	unspecified
Target Milestone:	---
Platform:	Debian testing
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description Nicholas Alexander 2015-11-25 00:38:25 UTC

When moving a folder to another drive, where the free space is smaller than the size of said folder, Krusader starts the transfer, but gives up after transferring only as much as the initial free space would have allowed.
If, during the first move, I create more free space on the target directory by moving out some files, it is expected that the transfer would carry on until the target truly runs out of free space.

Scenario. Consider /media/discone with 10 GB free. On /media/discone, there is a 15 GB folder /media/discone/moveme, that I want to move on /media/disctwo. At the beginning of the move, on /media/disctwo there are 9 GB free, but I intend to create more free space, by moving a 7 GB folder /media/disctwo/reversemoveme on /media/discone.
1. Start move of /media/discone/moveme to /media/disctwo.
2. Start move of /media/disctwo/reversemoveme to /media/discone.

Results:
The first move operation throws a "disk is full" after transferring the first 10 GB, regardless of how much free space is still left on /media/disctwo.

Expected result:
In typical cases, in and out rates being equal, the free space on /media/disctwo would stay around 10 GB as log as the second move is still going on. Thus, the first move operation should finish without incident.

Comment 1 Davide Gianforte 2016-01-24 11:43:36 UTC

This is KIO related. Krusader uses KIO to handle file operations (copy/move/delete...), which are called "jobs".

The free space check is made at the beginning of a Job, then if you free some space after a Job is started, it isn't aware of it.

As a temporary workaround, you can split a single Job using the built-in Queue (if you can) or (just for completeness) freeing all the needed space before starting the Job.

Anyway, this problem should be discussed with the KIO devs.

Comment 2 Nicholas Alexander 2016-04-16 17:09:18 UTC

I understand the limitation of KIO, but here you are making the case for a Krusader bug. Krusader is aware of the fact that transfer will fail, so it should deny the file operation before starting it. An error message saying "This transfer will not succeed" should be displayed, rather than passing the operation to KIO.
Please move back to Krusader.