automount ntfs volumes (was ntfs volume and locale= option)

[Szabolcs Szakacsits]

On Fri, 10 Oct 2008, Robby Workman wrote:

> Okay, all that being the case, we still need to work something out to
> have a modicum of consistency among distributions.  I'll bet I'm not
> alone in being often frustrated by reports of "I can do $x in
> $distribution, but it works differently in $other_distribution - how do
> I replicate the behaviour in $distribution?"  We (Slackware) ship an fdi
> file in our ntfs-3g package that seems to work out well, at least for
> the majority of users, but of course, there are going to be corner
> cases.   Maybe we packagers can work out a "de-facto" standard, so as
> an effort to start that process, here's our fdi file (attached).
> Comments and criticism welcome :-)

Thanks. We tried to walk on this path a few times, sadly without much 
success.

The above approach works for specific distribution versions __until__ 
ntfs-3g or HAL is upgraded (or downgraded). Which happens too often.

Ntfs-3g is actively developed and new stable releases are made at least 
once a month. We have 1100 downloads a day, need to support around 180 
distribution brands * 3 versions = 480 distributions, Linux 2.4 and 2.6, 
FreeBSD 6, 7, 8, NetBSD, Solaris, OS X, etc.

The HAL configuration files seem to be too HAL version specific. We 
couldn't find one which would work with most installed, upgraded, 
downgraded HAL versions.

Google can find examples when the configurations are different even for the 
same distro, depending on the HAL version used, e.g.:

 http://wiki.archlinux.org/index.php/HAL#NTFS
 http://gentoo-wiki.com/HOWTO_NTFS_write_with_ntfs-3g#Use_ntfs-3g_instead_of_kernel.27s_read-only_ntfs_driver_for_AutoMounting

So, we can't provide one HAL config file which would work almost everywhere 
but since most distros (cc 90%) don't sync, understandably, with ntfs-3g 
upgrades in every month but only less often thus many users upgrade by 
direct downloads which break their automounts.

We also can't detect HAL version changes and provide workarounds for HAL 
incompatibilities because to be called depends on HAL to call ntfs-3g what 
it doesn't do.

Probably because of these regular automount breakages some distros decided 
to use the ntfs file system type for ntfs-3g. 

Which unluckily resulted an even bigger mess. 

See e.g. Danny's recent reverted patch. The next HAL release will break at 
least all Ubuntu and Fedora based distros (about 12 million users) not 
being able to automount NTFS. Again. 

Btw, what is actually needed from HAL? Notification and deny or filter out 
the 'dev' and 'suid' mount options for user initiated root mounts. 

I'm not entire sure that not including a few trivial, never changing lines 
in HAL is worth spending several dozen developers' time for years trying to 
to solve an otherwise unsolvable, simple issue which is plaguing millions 
of users for over two years whenever they plug a today default NTFS 
external disk to be able to read/write it, as they did in the past with 
FAT.

More ideas about how this issue could be solved is very welcome, thank you. 

This is absolutely far the biggest problem Linux has with NTFS support 
today and none of the NTFS file system developer is knowledgeable how 
user-friendly hotplug could be elegantly solved across all the distro 
versions. In fact, we weren't even aware this is also our job until Danny 
pointed out to us recently. Otherwise we should have started to work on 
this much earlier, given how serious this issue is.

Regards,
	   Szaka

--
NTFS-3G:  http://ntfs-3g.org