Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#4742 closed Bug (worksforme)

Data loss when using "Move data file to …" from HFS+ to FAT32 volume

Reported by: porg Owned by: jordan
Priority: Normal Milestone: None Set
Component: libtransmission Version: 2.42
Severity: Critical Keywords: move data-loss fat32 hfs+



I had already often successfully used the function "Move data file to" to move torrents within a Volume or also across HFS+ volumes.

Today I used "Move data file to" to move 2 torrents from my HFS+ to my FAT32 partition, and sadly the data was lost!!! It's neither at the source nor target directory. Also did a ls -la to check for invisible files/folders, but no luck. The torrent data files seem to have went into digital nirvana.


For my current case: Is there any chance to regain the data? I mean: From my local disks, without re-downloading. Help appreciated!

In general: Data loss without ANY notification to the user is quite a serious bug. Even more severe if you were the only remaining seeder of that torrent, then this practically is the end of that torrent, not even a chance to re-download it, at least until another 100% seeder re-joins, and even then it costs download bandwidth time/money again. Please fix that bug, and add a warning to the documentation/wiki! Thanks!

Change History (7)

comment:1 Changed 10 years ago by livings124

  • Component changed from Mac Client to libtransmission
  • Owner changed from livings124 to jordan

comment:2 Changed 10 years ago by x190

Re: "Help appreciated!":

"The maximum possible size for a file on a FAT32 volume is 4 GB minus 1 byte or 4294967295 (232) minus 1 bytes."

  • This should be a copy operation, so data should still be in the original location.
  • Pause all torrents and quit Transmission.

  • Restart computer.

Please state your OS and its version. At the very least you should have seen a progress bar (if using OS X).

comment:3 Changed 10 years ago by porg

I am using Mac OS X 10.6.8 with Transmission 2.42 (13013)

The reported bug has occurred while moving 2 torrents, of which:

  • one contained 3 files (31 KB, 3 KB, 127,7 MB)
  • the other contained 5 files, of which I selected 4 (4 KB, 388.7 MB, 3.1 MB, 363.5 MB), and 1 remained unselected (944,9 MB)

So no FAT32 limitations should have been hurt by this.

Nevertheless after that move operation, these torrents were shown with the troubled icon and the remark "Error: No data found! Ensure your drives are connected or use "Move Data File To...". To re-download, remove the torrent and re-add it.".


I tried to reproduce the bug with all possibly thinkable test scenarios, and noted what happened when moving between HFS+ and FAT32.

1) Torrent consisting of...

a) ... 1 file.


b) ... multiple files (in torrent root), selected some of them.


c) ... multiple folders (in torrent root), from within which I selected some files.


2) The 2 torrents (b) and (c) together at once.



  • The bug did not re-occur in any scenario!
  • Contrary to what x190 writes, I did not see a progress bar for the move process (neither in the tests nor ever before) although I use the most recent Transmission.


The data seems to be definitely gone:

  • A Spotlight search for the respective file names returned no suitable results.
  • A search for invisible files at source/destination via ls -la showed nothing suitable.

Any other idea, of where it could have gone?

comment:4 Changed 10 years ago by x190

If this issue is not reproducible, do you think it might have been a temporary OS X and FAT32 filesystem interaction problem?

Re Data Recovery: If a restart as above doesn't help, then I would use Disk Utility's "Verify" function on all volumes. Hopefully, you have backed-up this data with Time Machine or otherwise. If not, you would need to try a Data Recovery Tool.

comment:5 Changed 10 years ago by porg

Concerning: Data recovery in my current case

Nevermind, it was a large torrent, but not that important. Fate accepted.

Concerning: Temporary OS X and FAT32 filesystem interaction problem

I checked system.log, kernel.log and ~/Library/Logs/CrashReporter/?*

  • manually for the timeframe of the accident
  • for the entire time frame via search terms: FAT, HFS, filesystem, fs, i/o, io, read, write, copy, move

But found nothing! So all we have is my witness report, no materialized proof, and (yet) it could not be reproduced either.

I think the last steps before closing this bug report:

  • Is FAT* <--> HFS* moving supported by Transmission per se?
  • Are there any exceptions/limitations? Obviously maximum file size and metadata. Any further besides these?
  • Is this documented? If not, shall it be documented? Who does that?

comment:6 Changed 10 years ago by jordan

  • Resolution set to worksforme
  • Status changed from new to closed
  • Summary changed from Data loss when using "Move data file to …" from HFS+ to FAT32 volume !!! to Data loss when using "Move data file to …" from HFS+ to FAT32 volume

I don't know of any limitations other than the ones intrinsic in FAT that you mentioned.

I've just confirmed that I can move files to a fat32 flash drive. Since neither of us can reproduce the behavior you saw, I'm going to close this bug as WorksForMe? for now.

Still, thank you for reporting this issue. If you're able to trigger the behavior again in a repeatable, reproducible way, please let the dev team know via trac. Thanks!

comment:7 Changed 10 years ago by porg

Yes. I'm glad that the issue is now at least documented (and thereby indexed for web search engines), and should it ever occur to me again, or someone else affected, I/they will continue reporting here.

Note: See TracTickets for help on using tickets.