Rockbox

This is the bug/patch tracker for Rockbox. Click here for more information.

Quick links: Bugs · Patches · Rockbox frontpage

Tasklist

FS#9945 - Copy/paste of files doesn't detect disk full condition

Attached to Project: Rockbox
Opened by Jonas Häggqvist (rasher) - Monday, 23 February 2009, 03:26 GMT+2
Last edited by Jonas Häggqvist (rasher) - Thursday, 26 February 2009, 23:55 GMT+2
Task Type Patches
Category Operating System/Drivers
Status Closed
Assigned To No-one
Player Type All players
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Private No

Details

When copying a file from one volume to another, the disk full condition isn't detected, and the copying never finishes.

I used the following method:
* Create 2 files on the player - one 110MB file of zeroes (0x0) and a 20MB file of ones (0x1)
* Copy the 110MB file to a 128MB microsd card
* Copy the 20MB file

The latter operation never finished (after 15 minutes), and I had to forcefully shut down by holding power for 15 seconds. After mounting the card, I see the 110MB file transferred correctly (MD5 sum matched), and a 0-byte file with the filename of the 20MB file.

Users on http://anythingbutipod.com/forum/showthread.php?t=34458 hypothesized that corruption might occur, but this doesn't seem to be the case. At least for this 128MB microsd card.

Tested on a Sansa E280 - I expect this might be true for all multivolume targets.
This task depends upon

Closed by  Jonas Häggqvist (rasher)
Thursday, 26 February 2009, 23:55 GMT+2
Reason for closing:  Fixed
Additional comments about closing:  Fix committed in r20121.
Comment by James Davis (advcomp2019) - Monday, 23 February 2009, 04:19 GMT+2
I just tried this on my Sansa e280 with a 4GB Class 4 microSDHC card. I tried to copy 3.5GB worth of files into 550MB of free space, and I have the same issue.
Comment by James Davis (advcomp2019) - Monday, 23 February 2009, 06:01 GMT+2
Even copying from the microSDHC card to the main memory of the Sansa does the same thing.
Comment by James Davis (advcomp2019) - Monday, 23 February 2009, 06:10 GMT+2
Oops, made a mistake. It was main memory to main memory that I just did. I would think microSD to main memory will have the same bug.
Comment by Jonas Häggqvist (rasher) - Monday, 23 February 2009, 17:30 GMT+2
This (currently untested) patch might do it. Seems the paste code was only checking if the result of the write operation was -1, but write() (and the lower-level function readwrite()) might return other error-values (<0). Hopefully this should be better. Will test later if no one beats me to it.
   paste_detecterrors_FS9945_v1.diff (0.5 KiB) 
 apps/onplay.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comment by Jonas Häggqvist (rasher) - Monday, 23 February 2009, 18:10 GMT+2
That patch did the trick, unless someone can come up with a good reason not to, I'll commit it shortly.

I'm seeing what appears to be another bug where paste fails to clean up after itself when pasting a directory fails and creating possible corruption (not visible in Linux though), but I don't think that's directly related - just another bug that's been uncovered by this check actually working and the paste operation stopping.

Loading...