FAT32 Driving Me Crazy

English Applications
1

OK, so I have to copy a few gigs onto a USB 2.0 external drive, which happens (and has to for reasons omitted here) to be formated as a single 1TB FAT32 partition.

While the drive mounts correctly and I can read all of its contents, my problems started with the ‘cp’ command terminating with a SEGV or freezing my entire machine (no keyboard or mouse working). Oh, and I’m on OpenSUSE 11, if that makes a difference.

The error does not occur always at the same point, as I can reboot my machine and try again with the same files/directories and it eventually works.

The first time my ‘cp -R’ command failed, I wanted to do a recursive diff, to figure out which files were successfully copied.

Craziness number #1: Diff thinks most files do not match! The problem is that ‘cp’ seems to translate files to lower case while copying to a FAT32 partition. Diff does not know this, so says that the ‘same’ file only exits on the FAT32 and the Linux partition.

Craziness number #2: Case sometimes preserved! Try ‘mkdir V1’ and it creates ‘v1’ (lower case). Try ‘mkdir Volume1’ and it creates ‘Volume1’ (mixed case preserved). Do ‘mv Volume1 V1’ and the directory becomes ‘v1’ (lower case).

So, I’m hoping someone has any idea of how to fix or avoid some or all of these problems. Ideally, cp would copy files with the right case, mkdir would create dirs of the right case and diff would work as a consequence. If not, perhaps there are non-standard system tools that can help. BTW, I tried to copy with the Gnome file manager and it froze itself once and froze the machine the other time.

Thanks in advance,

  • Itai
2

I cannot answer all your problems but I find that all FAT32 files with one case, whether upper or lower, are copied over as lower and those with both upper and lower are copied as they are. But I have no idea at what point in the copying process that decision is made.

3

You mean FAT32 actually supports partitions over 32GB? Good for you!

4

FYI
Limitations of the FAT32 File System in Windows XP

[quote]The maximum disk size is approximately 8 terabytes

You cannot format a volume larger than 32 gigabytes (GB) in size using the FAT32 file system during the Windows XP installation process. Windows XP can mount and support FAT32 volumes larger than 32 GB (subject to the other limits), but you cannot create a FAT32 volume larger than 32 GB by using the Format tool during Setup
[/quote]Are you doing this from a CLI, a terminal in X or from a GUI?

What size are the files you are moving/copying?

5

The files I am copying vary in size from a few KB to a few hundred megs. There may be a very small number above 1GB but less than 2GB. There are roughly 40,000 files totaling a bit under 200GB.

Initially I tried ‘cp -R’ on the command-line (tcsh) for the whole thing at once. In 4 tried this causes 2 SEGVs and 2 times my machine froze. When I tried to copy the whole thing via the Gnome file-browser instead, the system froze (no keyboard or mouse, so I could not even go to a console session).

What ended up getting the job painfully done it to do ‘cp -R’ on smaller chunks (1-20GB). Still, I had to try multiple times as 1 time out of 2, ‘cp’ failed with a SEGV. When that happens the file-system became read-only, so I had to reboot for my second try.

6

Yes. It was formatted on an Intel Mac and this also works (but you can’t format it) on Windows XP.

7

Actually, I was copying TO FAT32. The case was preserved that way. What is driving me nuts the most is that file-operation (mkdir for example) does not create the file/directory in the requested case.

8

On Saturday 13 December 2008 23:16, idanan wrote:

> OK, so I have to copy a few gigs onto a USB 2.0 external drive, which
> happens (and has to for reasons omitted here) to be formated as a single
> 1TB FAT32 partition.

> While the drive mounts correctly and I can read all of its contents, my
> problems started with the ‘cp’ command terminating with a SEGV or
> freezing my entire machine (no keyboard or mouse working). Oh, and I’m
> on OpenSUSE 11, if that makes a difference.
No, it doesn’t.
First thing: I’d use rsync, if I where you. Better at handling such
volumes, perhaps, but certainly much better to resume, if thing stop
mid-may.

> The error does not occur always at the same point, as I can reboot my
> machine and try again with the same files/directories and it eventually
> works.
No ready-made solution for that. Can be anything from drive overheating,
to file size, to clashing name cases, …

> The first time my ‘cp -R’ command failed, I wanted to do a recursive
> diff, to figure out which files were successfully copied.
No need, with rsync.

> Craziness number #1: Diff thinks most files do not match! The problem
> is that ‘cp’ seems to translate files to lower case while copying to a
> FAT32 partition. Diff does not know this, so says that the ‘same’ file
> only exits on the FAT32 and the Linux partition.
> Craziness number #2: Case sometimes preserved! Try ‘mkdir V1’ and it
> creates ‘v1’ (lower case). Try ‘mkdir Volume1’ and it creates ‘Volume1’
> (mixed case preserved). Do ‘mv Volume1 V1’ and the directory becomes
> ‘v1’ (lower case).
A simple ruile: FAT (32 or otherwise) has NO case. Anything resmbling case
is merely display gloss. Don’t ever rely on it for anything.

> So, I’m hoping someone has any idea of how to fix or avoid some or all
> of these problems. Ideally, cp would copy files with the right case,
> mkdir would create dirs of the right case and diff would work as a
> consequence. If not, perhaps there are non-standard system tools that
> can help. BTW, I tried to copy with the Gnome file manager and it froze
> itself once and froze the machine the other time.
Use rsync, you’ll still get a reasonably ‘cased’ set of dirs/files.

FAT32 on a 1 TB partition is new to me, but I’ve done a 640GB one, so…

With FAT32, you get a max file size of 4GB(-1 byte).

Mind the depth of the paths: the specs seem to say you can get a fullpath
length of up to 64KB. But any Windows machine I’ve worked with stops at
255 chars. So, avoid crossing that limit, too.

–
There is an art, it says, or rather, a knack to flying.
The knack lies in learning how to throw yourself at the ground and miss.
Douglas Adams

9

As someone suggested, I tried rsync… It does not help because of the case issue unfortunately (explanation below). It turns out even if rsync could work, it wouldn’t solve all the problems either.

So what I really need is a way to tell the (OpenSUSE) FAT32 driver to show files on a FAT32 device in their actual case. Anyone would know what option that would be and how to set it? That would be greatly appreciated :slight_smile:

Thanks in advance,

  • Itai

PS: For the curious, here is why rsync doesn’t work:

  • Say I sync ‘SOMEPIC.JPG’ and ‘somedoc.txt’ from Linux to FAT32 on Monday.
  • On Tuesday, I rync again WITHOUT anything having changed. rsync will try to sync SOMEPIC.JPG again because it cannot find it on the FAT32 drive, it only has ‘somepic.jpg’.
  • As I undestand this, it is because the FAT32 driver enumerates “single case” files as lower-case! So all lower-case files have no problems but all upper-case files do. Mixed case is another case.
10

What is your ultimate goal in this? To transport files to another Linux system using a FAT32 external disk, or to backup your files?

If to transport files, you’d be better off using tar to write archives on the disk, using split to keep the size of the chunks within limit. Something like:

tar zcf - * | (cd /media/DISK; split -b 1G)

At the other end you can recombine with cat and extract with tar.

If to backup your files, sorry, IMO backing up Linux files on FAT32 is an inherently bad idea.

11

Getting some sanity back finally :wink:

Here is the solution to the lower-casing of files by the file driver (without knowing the answer it is surprisingly hard to search on the Internet and arrive at this solution):

The solution to this is thus, you must mount the FAT32 partition using shortname=mixed, you can either put this into your /etc/fstab, where it’ll use it automatically, or you can do what I did and install the parameter into the gconf options, so when it automounts, it’ll use the property. You can do that by following these instructions

  1. open the gconf editor (if you don’t have it installed, install it, then open it)
  2. you’ll find it in the system tools section of your Gnome desktop menu
  3. Navigate through the heirarchy of folders to:/system/storage/default_options/vfat
  4. On the right, you’ll see mount options, open it
  5. change the value of shortname=lower to shortname=mixed
  6. click accept
  7. close gconf
  8. Unmount and remount your FAT32 drives
  9. FINISHED.

Source: Linux, FAT32 and mounting options | Chris Thomas: The blog (18)

Now that I found this, I’ll see which of my original problems remain.

  • Itai