• Status Closed
  • Percent Complete
  • Task Type Patches
  • Category Operating System/Drivers
  • Assigned To No-one
  • Operating System All players
  • Severity Low
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by rasher - 2009-02-23
Last edited by rasher - 2009-02-26

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

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 (0×0) and a 20MB file of ones (0×1)
* 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 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.

Closed by  rasher
2009-02-26 22:55
Reason for closing:  Fixed
Additional comments about closing:   Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407

Fix committed in r20121.

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.

Even copying from the microSDHC card to the main memory of the Sansa does the same thing.

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.

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.

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.


Available keyboard shortcuts


Task Details

Task Editing