For security reasons, I have two workstations i front of me, and I can only transfer data between them through a USB key.

As you can imagine, it can get quickly tiresome, but the most annoying is having to unmount the things before removing them. Not umounting them results in missing files most of the time, even if I remove them a while after having last written to them.

Now, since they're only used for transferring smallish files, and each are basically written once and read once, I don't need the fancy pansy caching infrastructure that makes clean unmounting a necessary step. And since the data is always a copy of something I have at hand, I don't care if the filesystem croaks from time to time.

But anyway the system doesn't need to force that on me, it could simply make sure everything is committed with a second, and works synchronously. Then when I remove the key, nothing is lost. Is there a way to do this?

I would appreciate any other tips on handling this situation.

Edit: it appears the situation has changed between RHEL5 and Fedora up to F11 on one hand, and F12 on the other. The latter use DeviceKit-disk, and I haven't quite figured out how to do this. The method provided below in gconf does not work anymore.

I don't think you want autounmounting (there is no way the Linux system can read your mind and figure out how to run a 2-3 second operation before you pull the drive), rather, you want to make sure all data is flushed to the drive before you would pull it.
–
J. PolferSep 17 '09 at 14:58

That's precisely what I meant. Autounmounting was a pun.
–
niXarSep 17 '09 at 15:27

since this question was asked for RHEL5, maybe you should post a separate follow-up question asking how to do the same in Fedora12 with DeviceKit. (i'm somewhat curious about the DeviceKit method myself.)
–
quack quixoteFeb 25 '10 at 13:15

3 Answers
3

If your system is using HAL to automount USB sticks, you need to tweak the HAL configuration. I'm not sure what the best way to do this is, but here are a couple of methods that might work for you.

Severalsites indicate that mount options can be added into Gconf with the gconf-editor or gconftool tools. My understanding is that these are per-user tweaks; I'm not sure how to effect system-wide defaults in Gconf.

Start gconf-editor

Find or add the key /system/storage/default_options/vfat/mount_options

Set the new value to your desired mount options. I assume the syntax is a comma-separated list, such as you'd use with mount -o, like one of these examples:

iocharset=utf8

umask=022

gid=1002,fmask=133,dmask=022

The HAL specs show several properties in the storage.policy.* namespaces that affect the mount options. HAL and Dbus are complicated, but a lot of the default configuration happens in /etc/hal and /etc/dbus-1. On my Ubuntu system, /etc/hal/fdi/policy/preferences.fdi is one place where I could tweak HAL's default policies. On your system, you'll need to locate the proper place.

Read through this answer I wrote about HALevt. It's written from a Debian perspective, and you aren't using HALevt, but the HAL tweaks should be similar. Hopefully the links and examples might give you some ideas of where to start looking.

"I setup all the automount to happen in /mnt/auto and have a /auto/usb softlink to /mnt/auto/usb. It is important to use noatime and showexec for your mount options to extend the lifetime of your thumb drive, and have proper file permissions."

There's also the kernel module hotplug which provides you with udev for which rules can be written. Generally these only automount and don't do a umount.

I'm not sure if these two approaches are related at all.

Update
If what you're looking for is the sync option to mount, so as to minimize the time data spends in the buffers, then just add that to one of the configuration files. Be advised that this generally reduces the life of a flash memory device. If you plan on pulling the live device, this will minimize the risk of there being data sitting in the buffer. However I have not found anything which will trigger after an unplug event to clean up the mount point, that sure would be nice.

Lastly if you always write the files on a non-linux machine, and only read the files on a linux machine (a uni-directional sneaker net), then you should throw in the read only option too, just to make it simpler. Again it would be nice to have umount trigger, but maybe there's a way to configure a umount before a mount on the hotplug event.

RHEL already does those things through udev→hal→dbus and gnome-mount.
–
niXarSep 18 '09 at 7:20

1

I know about the "sync" option in mount, but I'm not doing the mount myself, I'm using RHEL5's gnome + udev + hal + dbus + gnome-mount standard setup, and I'm not sure where I should put that, if I can put it anywhere.
–
niXarSep 20 '09 at 1:30

"RHEL5" is in the question title. That would be Red Hat Enterprise Linux 5.
–
PowerlordSep 18 '09 at 18:31

I've been led to believe that "Linux" was an operating system. I might have been wrong. As R. Bemrose pointed out, RHEL5 stands for what he said. Additionally, the tags include "gnome" which is the desktop environment. (In fact, one of the workstations is running Fedora 11, but that does not make any difference)
–
niXarSep 20 '09 at 1:28