Bug 24129 - please mount vfat disks with shortname=mixed
Summary: please mount vfat disks with shortname=mixed
Status: RESOLVED FIXED
Alias: None
Product: udisks
Classification: Unclassified
Component: operations (show other bugs)
Version: unspecified
Hardware: All All
: medium normal
Assignee: David Zeuthen (not reading bugmail)
QA Contact:
URL: https://bugs.launchpad.net/ubuntu/+so...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-09-24 01:14 UTC by Martin Pitt
Modified: 2009-10-09 07:05 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
git formatted patch (1.27 KB, patch)
2009-10-08 11:35 UTC, Martin Pitt
Details | Splinter Review

Description Martin Pitt 2009-09-24 01:14:27 UTC
From Ubuntu bug report:

  "Since the move to DeviceKit for karmic, my removable VFAT-formatted disks are being mounted with shortnames=lower. This breaks e.g. rsync: if a file called "FOO" is created, it will actually appear named "foo". Past bugs -- e.g. https://launchpad.net/bugs/15525 and https://launchpad.net/bugs/76200, amongst others -- concluded that shortnames=winnt (or perhaps shortnames=mixed) was the correct setting, and this was indeed the case in earlier releases.

  shortnames=lower appears to be set in devicekit-disks's src/devkit-disks-device.c."

The proposed patch is pretty straightforward, just changing "shortname=lower" to "shortname=winnt" in src/devkit-disks-device.c. However, we should have a consensus about this and fix it upstream, or not at all.

Was this deliberate or just an oversight? Thanks!
Comment 1 Martin Pitt 2009-09-24 01:20:40 UTC
It's not actually a regression from an upstream perspective, though. In Ubuntu we had a gnome-mount patch to change to shortname=mixed by default. However, I'd really like to avoid piling up patches again. There must be a generally applicable default for this, after all.
Comment 2 David Zeuthen (not reading bugmail) 2009-09-28 12:16:34 UTC
Hmm, it's shortname=lower because that's what the (upstream) kernel defaults to, see Documentation/filesystems/vfat.txt. If we change it, then e.g. various (obscure?) rsync usage patterns are fixed - but what do we break?
Comment 3 Martin Pitt 2009-10-08 02:51:16 UTC
It's not that obscure, though. With "lower", you don't preserve case:

$ rm *; touch foo; ls 
foo
$ rm *; touch FOO; ls 
foo

but with "winnt" you do:

$ rm *; touch foo; ls 
foo
$ rm *; touch FOO; ls 
FOO

If you want to open a particular file, both variants are clever enough to ignore case:

$ rm *; echo xx > FOO; cat foo
xx
$ rm *; echo xx > foo; cat FOO
xx

So we don't break file access, and behaviour for lower-case and MixedCase is identical, it just fixes ls/readdir() for ALLUPPERCASE file names.
Comment 4 Martin Pitt 2009-10-08 03:01:44 UTC
So obviously this change would break software which relies on an all-uppercase file name being actually saved as all-lowercase name.

The other issue is that if you create a file in all uppercase under Windows XP, it gets displayed in all-lowercase in Linux with "shortname=lower", whic is unexpected as well.
Comment 5 Martin Pitt 2009-10-08 03:14:01 UTC
I mailed the kernel vfat maintainer for input.
Comment 6 Martin Pitt 2009-10-08 11:25:21 UTC
Answer from the kernel vfat maintainer:

> Timely question :) Primary reason is historically compatible. However,
> at 2.6.32, I've decided to change default from "lower" to "mixed".
>
> 2.6.32 will use shortname=mixed as default.
Comment 7 Martin Pitt 2009-10-08 11:30:25 UTC
This already landed in Linus' tree two months ago:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=955234755ce4a2c33cfc558912aa8f2148cc1fc6
Comment 8 Martin Pitt 2009-10-08 11:35:44 UTC
Created attachment 30176 [details] [review]
git formatted patch

Trivial patch, but for the sake of fast "git am" love and having a meaningful changelog (and also to make my local "git rebase" work :) ), I'll attach it here.
Comment 9 David Zeuthen (not reading bugmail) 2009-10-09 07:05:16 UTC
Committed. Thanks for doing this.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.