all uppercase ignored when writing to vfat volume in fstab

bwh1969 · 2009-05-30 21:08:33

Any volumes I have in fstab seem to ignore uppercase characters beyond the first character when I write to them:

Here is a sample line:

UUID=94D7-F23D /media/STORAGE vfat    rw,user,users,auto,exec,uid=500,gid=500  0       0

I specifically need certain directories to have capitals in them, and they just do not appear. I could type

mkdir /media/STORAGE/BRIAN

and I would get "brian" I could also do this from within a file manager and the same thing happens.

However, if I make a directory called "Brian," then I get "Brian." The first capital letter is not ignored.

What options do I need to have in my fstab so that I have rw and exec rights as a normal user and have attention paid to what case files/directories are in?

Another vfat volume that I mount using a file manager (HAL) does not do this.

Last edited by bwh1969 (2009-05-30 21:15:19)

karol · 2009-05-30 21:31:39

'mkdir -p /media/STORAGE/BRIAN' creates the dir structure w/ 'STORAGE' and 'BRIAN". If you can't do this that sth is surely wrong. How do you test what you've got - 'ls'?

fukawi2 · 2009-05-30 22:35:58

AFAIK it's a vfat "feature/limitation/bug". I can't create files or directories with all uppercase names in Windows either.

I can't explain why it works on your other one.

karol · 2009-05-30 22:51:54

I never noticed this problem w/ all caps.
http://www.osnews.com/story/9681/The_vf … _and_Linux 2.1. Mounting Parameters
http://www.osnews.com/story/9681/The_vf … nux/page2/

Last edited by karol (2009-05-30 22:58:41)

Trent · 2009-05-31 16:17:50

bwh1969 wrote:

I specifically need certain directories to have capitals in them, and they just do not appear.

You need capitals in certain directories? For what? vfat is case insensitive. Even in Linux, you can still access that file by any of the names 'brian', 'BRIAN', 'Brian', 'BrIAn', etc. (but only the name that appears in the directory listing will appear in e.g. bash autocompletion).

I could type
mkdir /media/STORAGE/BRIAN
and I would get "brian" I could also do this from within a file manager and the same thing happens.
However, if I make a directory called "Brian," then I get "Brian." The first capital letter is not ignored.

This is a quirk / (mis)feature of all dos-based filesystems as far as my knowledge. In short, upper-case filenames are changed to lowercase, but mixed-case filenames retain their appearance. It makes sense if you don't think too much about it. It only affects the way the name is displayed, though, not the names by which the file is accessible.

I was not aware of the caveat mentioned in karol's first link, that it only applies for 8.3 filenames -- but the filenames are still case insensitive; i.e., if you make a file named BRIANBRIAN it will still be accessible via BrianBrian, brianbrian, brianBRIAN, etc.

Last edited by Trent (2009-05-31 16:20:26)

karol · 2009-05-31 16:42:12

I (as user) also can delete files / dirs created as root.

byte · 2009-05-31 16:43:43

You might want to read up on the "shortname" mount option for VFAT ('man mount' or vfat.txt from kernel sources) and perhaps even try running 'dosfsck -vl' on your VFAT partition.

fukawi2 · 2009-05-31 22:27:50

karol wrote:

I (as user) also can delete files / dirs created as root.

That's because FAT doesn't support POSIX permissions. It's a very equal-opportunity file system which is happy to give everyone access to do exactly the same as what anyone else can do without caring if your root or user, black or white, male or female.

Last edited by fukawi2 (2009-05-31 22:28:07)

karol · 2009-05-31 22:53:19

@fukawi2
I was partially referring to

What options do I need to have in my fstab so that I have rw and exec rights as a normal user and have attention paid to what case files/directories are in?

although I don't yet get uid, gid etc. so I may be wrong wrt to "users can do e-v-e-r-y-t-h-i-n-g".
I _knew_ that it didn't support the permissions but it was such a shock to me that I could delete as user what I have created as root that I had to share this :-) I somehow thought that the various *ids would prevent this from happening.

fukawi2 · 2009-06-01 02:43:08

Ownership is part of POSIX Permissions -- afterall, if you don't know the ownership, what good are permissions, and vice-versa

karol · 2009-06-01 10:03:36

B..bb...but I thought ... <cries> ;-P
The second link (http://www.osnews.com/story/9681/The_vf … nux/page2/) made my head spin, because it basically said that on different systems the *ids are different <trembling in fear>

fukawi2 · 2009-06-01 10:14:31

uids and gids are can vary between systems if you're not careful in keeping them the same across multiple systems. This can cause problems since ownership is given to a UID/GID combination.

ie, if on my server 'fukawi2' is uid 1000, and karol is 1001, and on you server, fukawi2 is 1001 and karol is 1000, then a file that I own and I copy from my server to your server is suddenly owned by you.

karol · 2009-06-01 10:42:22

Is there a way to prevent this? I can control the uids on my computers and keep them consistent but when I mail a file to you (let's say you graciously provide backup), you can read it, right? I've read that "noexec / nosuid / nodev" = safe, but I have yet to RTFM to know what they mean by that ;-)

I (again) am sorry for the OT.

Trent · 2009-06-01 13:37:35

vfat is entirely user- and group-agnostic. The permissions on the files on a mounted vfat partition is determined by how it is mounted. You can use the umask=xxx option to define specific permissions for a vfat filesystem (see mount(8) for details). The permissions will be applied unilaterally to the whole disk -- all directories and files regardless of type.

If you mount a vfat filesystem as root, it usually has 755 permissions and belongs to root. (An e.g. ext3 filesystem will maintain the per-file permissions you would expect.) If you mount a vfat filesystem as some other user, it will still have 755 permissions but belong to that user. If you need to mount it as root and have write permission as another user, open the permissions with

mount -o uname=000 <device> <mountpoint>

. An easier option is to put it in /etc/fstab with the user option and mount it as an ordinary user (NOT root).

With respect to moving files between machines, you generally only have to be concerned about direct filesystem-like copying (e.g. making backups). Email does not preserve permissions or ownership; you can read an attachment I send to you no matter what permissions it has on my server. Likewise, if I copy a file to a vfat filesystem (say on a removable disk), I have no way of controlling the permissions it will have on your system because that depends on how it's mounted. But if I copy a file with 700 permissions and UID 1000 to an ext2 filesystem, it will be owned by the user with UID 1000 on whatever machine the filesystem is mounted on. That is me on my machine, but say that your UID is 500 -- you can't read, write or do anything else with it as an ordinary user. As root of course you can do whatever you want.

karol · 2009-06-01 13:44:43

If you mount a vfat filesystem as some other user, it will still have 755 permissions but belong to that user.

I think that's what happened in my case. Looks like the only way to keep my secrets to myself is (strong) encryption. - or no secrets :-)

bwh1969 · 2009-06-01 21:27:08

Okay... so I was glad to generate a discussion. But I think a few of you are WRONG. However, the original question then remains: Why then is HAL able to mount the drive and deal with ALL CAPITALS for a directory or filename and the same drive (or any vfat for that matter) mounted via fstab entry does not.

If I let HAL do the work, I do not have this issue. I find this weird. If I unmount the drive and comment it out in fstab then mount it using Dolphin (I am using kde4) or the mount applet, I can create all caps filenames and directories.

WHY capitals is a rather specific question. I am using a live setup with a saved overlay (its really really fast this way), and I I need a certain amount of space to say, run K9copy (um like anywhere from 3-8 GB for the temp directory) so I need to choose a drive rather than let it use the default /tmp/user/k9copy

Linux is case sensitive, so it is looking for /tmp/dvd/VIDEO_TS and AUDIO_TS not video_ts and audio_ts, it creates the directories, but they go to lowercase. When it goes to read the shrunken vob files, it can't find them because of the case issue. I can band-aid the issue by choosing a non fstab drive and use that but then, what is HAL doing that fstab can't handle with my options?

Last edited by bwh1969 (2009-06-01 21:31:48)

karol · 2009-06-01 21:34:05

I don't use HAL, but I can mount manually and have Brian or BRIAN. I can't have both on a vfat drive, because it's not a proper Linux fs, it's from Microsoft, so you know who to blame.

Trent · 2009-06-01 22:32:49

Sorry, I thought the discussion of shortname answered your question. Did you add shortname=mixed to the options in fstab?

fukawi2 · 2009-06-01 22:48:56

Trent wrote:

Sorry, I thought the discussion of shortname answered your question. Did you add shortname=mixed to the options in fstab?

I thought that too... I'm guessing HAL uses this option, whereas you haven't been specifying it in your fstab which is WRONG.*

(* Sorry, but to yell at someone like in your post who's been trying to help you and tell them they are "wrong" is rude)

Last edited by fukawi2 (2009-06-01 22:51:02)

bwh1969 · 2009-06-01 23:23:33

True and I needed to be called on it. It was rude, albeit not set out that way. Trent answered my question but then it somewhat got lost in the talk of gid/uid. I completely missed the shortname thing and it fixed it. Thanks:-)

And fat filesystems suck, and that was pointed out and I do agree but in some cases it is a necessary evil: one could hope there will eventually be some universal filesystem that all major os's read-write properly.

*and I got yelled at for wanting to use capital letters so I felt I needed to redirect the post to needing to address the case issue: it does appear as though a few posts suggest "it is just that way" and I don't think that it is

My issue is peculiar to Arch. It never happened in my debian based systems,

Last edited by bwh1969 (2009-06-02 01:20:12)

fukawi2 · 2009-06-02 01:49:56

bwh1969 wrote:

And fat filesystems suck, and that was pointed out and I do agree but in some cases it is a necessary evil:

I couldn't agree more. Well said

bwh1969 · 2009-06-02 10:32:39

When I have to use XP, which I generally avoid, I use the Ex2IFS driver to read my ext3 partitions. I have write enabled but I rarely ever take this chance. Does anyone here have any extensive experience with it? I actually have been trying to get away from fat: I have had data loss several times both during XP and the rarer Linux crash. Somehow unclean unmounted causes the entire fat32 partition to show up in both OS's as "unformatted." I have tried to use a variety of tools to recover the data with only marginal success.

I have had decent luck with NTFS between both filesystems using NTFS-3g but eventually I have to use the force option at some and then feel uneasy about writing to the drive until I use "ntfsfix" then boot into XP and run the disk checker. I trust ntfs-3g in Linux more than I trust XP's ability to write to ext3 partitions, regardless of how good the driver is.

Any suggestions as to what one could use as a better filesystem between Linux and XP would be greatly appreciated and I promise not to yell at anyone for their suggestions. There are only a few other options and I don't think any of them are -rw in both.

It is easy enough to convert a vfat to an NTFS drive, but it is irreversible and don't want to cause further issues with not having -rw if I plug it into another computer, whether it be a Mac or another Linux box.. Seems like I am stuck with fat32.

karol · 2009-06-02 10:35:40

I've no idea if samba would help.
http://us6.samba.org/samba/docs/SambaIntro.html

Last edited by karol (2009-06-02 10:40:08)

kgas · 2009-06-02 14:55:56

There is another way too. Have you tried the --bind option with mount. This works fine for me. (not from fstab). As all said vfat got its own limitation.

fukawi2 · 2009-06-02 22:28:16

karol wrote:

I've no idea if samba would help.
http://us6.samba.org/samba/docs/SambaIntro.html

Samba is for sharing a mounted filesystem (regardless of type) across the network using the SMB/CIFS protocol.

kgas wrote:

There is another way too. Have you tried the --bind option with mount. This works fine for me. (not from fstab). As all said vfat got its own limitation.

--bind is to mount one file system in 2 locations (ie /mnt/music and /media/music) so I'm not sure how it could help?

Last edited by fukawi2 (2009-06-02 22:28:27)

Arch Linux

#1 2009-05-30 21:08:33

all uppercase ignored when writing to vfat volume in fstab

#2 2009-05-30 21:31:39

Re: all uppercase ignored when writing to vfat volume in fstab

#3 2009-05-30 22:35:58

Re: all uppercase ignored when writing to vfat volume in fstab

#4 2009-05-30 22:51:54

Re: all uppercase ignored when writing to vfat volume in fstab

#5 2009-05-31 16:17:50

Re: all uppercase ignored when writing to vfat volume in fstab

#6 2009-05-31 16:42:12

Re: all uppercase ignored when writing to vfat volume in fstab

#7 2009-05-31 16:43:43

Re: all uppercase ignored when writing to vfat volume in fstab

#8 2009-05-31 22:27:50

Re: all uppercase ignored when writing to vfat volume in fstab

#9 2009-05-31 22:53:19

Re: all uppercase ignored when writing to vfat volume in fstab

#10 2009-06-01 02:43:08

Re: all uppercase ignored when writing to vfat volume in fstab

#11 2009-06-01 10:03:36

Re: all uppercase ignored when writing to vfat volume in fstab

#12 2009-06-01 10:14:31

Re: all uppercase ignored when writing to vfat volume in fstab

#13 2009-06-01 10:42:22

Re: all uppercase ignored when writing to vfat volume in fstab

#14 2009-06-01 13:37:35

Re: all uppercase ignored when writing to vfat volume in fstab

#15 2009-06-01 13:44:43

Re: all uppercase ignored when writing to vfat volume in fstab

#16 2009-06-01 21:27:08

Re: all uppercase ignored when writing to vfat volume in fstab

#17 2009-06-01 21:34:05

Re: all uppercase ignored when writing to vfat volume in fstab

#18 2009-06-01 22:32:49

Re: all uppercase ignored when writing to vfat volume in fstab

#19 2009-06-01 22:48:56

Re: all uppercase ignored when writing to vfat volume in fstab

#20 2009-06-01 23:23:33

Re: all uppercase ignored when writing to vfat volume in fstab

#21 2009-06-02 01:49:56

Re: all uppercase ignored when writing to vfat volume in fstab

#22 2009-06-02 10:32:39

Re: all uppercase ignored when writing to vfat volume in fstab

#23 2009-06-02 10:35:40

Re: all uppercase ignored when writing to vfat volume in fstab

#24 2009-06-02 14:55:56

Re: all uppercase ignored when writing to vfat volume in fstab

#25 2009-06-02 22:28:16

Re: all uppercase ignored when writing to vfat volume in fstab

Board footer