Bug 243074 - HAL's Auto Mount VFAT shortname=lower
Summary: HAL's Auto Mount VFAT shortname=lower
Status: CLOSED DUPLICATE of bug 242832
Alias: None
Product: Fedora
Classification: Fedora
Component: hal
Version: 7
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: David Zeuthen
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2007-06-07 07:21 UTC by Granville Xiong
Modified: 2013-03-06 03:51 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-06-07 16:22:03 UTC

Attachments (Terms of Use)

Description Granville Xiong 2007-06-07 07:21:58 UTC
Description of problem:

I just installed FC7 a few days ago and am using Gnome as my desktop environment
in UTF-8 encoding. One of my daily jobs is to back up my files from my hard
drive to my USB portable drive. I use rsync to synchronize the data from ext3
hard drive partition to vfat portable drive partition. I use the following
command to do the job:

rsync -v -t --modify-window=2 -r -u --delete -z "${SRC_DIR}" "${DEST_DIR}"

Everything was fine in FC6. But things were not going well in freshly installed
FC7: some of my files were kept being backed up every time when I ran rsync
command, although the source files were not changed at all! I tracked down the
problem by revealing the default mount options stored in /media/.hal-mtab, as
shown here:

/dev/sdb1 501 0 vfat nosuid,nodev,uhelper=hal,shortname=lower,uid=501 /media/PHD

The culprit is the mount option "shortname=lower" which created in vfat
partition lower-case directory and file names for the directories and files
whose original name is short and all upper case in Linux ext3 partition.
Therefore every time rsync deleted the directories and files whose letter case
__appear__ changed in vfat, copied the source directory from ext3 to vfat, and
then changed the case to lower ones. I checked out the manpage of mount and ran
some tests, and found out that the mount option "shortname=mixed" does the right
job: everything was kept exactly the same in vfat partition as those in ext3 one.

So my question is that where to put my customized mount option in FC7 system, so
that every time when a removable device is plugged in, the correct mount option
can be used automatically. It seems to have something to do with HAL but I have
no idea where to store my mount options. And I also found a config file
/etc/gconf/schemas/gnome-mount.schemas which contains something like:


I changed "lower" to "mixed", but had no effects at all on mounting plugged drives.

It looks like this bug is caused by the default configuration of HAL. I wrote a
configuration file storage-policy.fdi:

<?xml version="1.0" encoding="UTF-8"?>

<deviceinfo version="0.2">
    <match key="block.is_volume" bool="true">
      <match key="volume.fsusage" string="filesystem">
        <match key="volume.fstype" string="vfat">
          <merge key="volume.policy.mount_option.shortname="

I put it at /usr/share/hal/policy/95userpolicy/ and restart haldaemon. Then
lshal has an output line:

volume.policy.mount_option.shortname= = 'mixed' (string)

But /media/.hal-mtab still shows shortname=lower! So it seems that my
storage-policy.fdi was not loaded by HAL. I also tried /etc/hal/fdi/policy/ but
no effects at all either.

This problem potentially affects the communication of FC7 box with most portable
multimedia devices, e.g. digital camera, MP3 player, PDA, etc., most of which
are mounted as FAT32 storage. Say I wanna maintain a list of my favorite songs
on my MP3 player using rsync, and end up with all short upper-case artist names
renamed. It's a disaster!

I remember I have done similar jobs in FC5 and FC6, and they worked. Does
anybody know how to do it in FC7? Thanks a lot!

Version-Release number of selected component (if applicable):

How reproducible:


Steps to Reproduce:
Actual results:

Expected results:

Additional info:

Comment 1 David Zeuthen 2007-06-07 16:22:03 UTC
HAL is only a mechanism; gnome-mount controls what policy to apply.

*** This bug has been marked as a duplicate of 242832 ***

Note You need to log in before you can comment on or make changes to this bug.