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

[Robby Workman]

On Fri, 10 Oct 2008 12:07:35 +0000 (UTC)
Szabolcs Szakacsits <szaka at ntfs-3g.org> wrote:

> Danny Kukawka <danny.kukawka <at> web.de> writes:
> > On Samstag 4. Oktober 2008, Michael Biebl wrote:
> > > a Debian user reported that mounting ntfs volumes fails for him 
> > > under KDE [1]. After investigating this problem, the following 
> > > issues were found:
> 
> Thank you Michael for taking care about this issue. Your summary was
> one of the nicest and cleanest I've ever read.
> 
> The locale= mount option is relatively a minor issue because there 
> are over 70 other ones which users may want to use and can cause the 
> same problem.
> 
> The real issue is how NTFS automount should work. This became one of 
> our (NTFS-3G) top priorities for a while because it's indeed a big 
> mess for two years, and it's only getting worse.
> 
> The NTFS-3G developers' policy was that we do not force what NTFS 
> driver is used and how it is used. This is also explained as the top 
> most often asked problem: http://ntfs-3g.org/support.html#plugandplay
> 
> In June we invested a lot of time and enery to research and solve 
> this issue but sadly with no result yet. Originally we believed that 
> HAL should provide the needed configuration, as it does for any other 
> file systems.
> 
> Danny kindly explained to us that this is not OK because NTFS-3G is 
> not a kernel file system driver. This is true because it's indeed a 
> hybrid, split kernel/user space driver but otherwise it exactly 
> behaves as any other in-kernel file system driver.
> 
> The only real difference is that while automount works smoothly 
> for the other file systems, it's a total user and distro developer 
> disaster and confusion for those who would like to use NTFS-3G
> (at the moment over 180 distributions, most of the top 100 most
> popular ones: http://ntfs-3g.org/distributions.html).
> 
> We planned to provide the HAL .fdi file in the NTFS package and 
> collected the requirements. The issue became very complicated 
> because whatever we designed, it was either broken in some popular 
> system or it got broken later on by HAL upgrades. 
> 
> We sent to Danny some emails asking his help and advice but sadly 
> we never got reply to the above emails how we could solve these 
> problems:
> 
>  http://ntfs-3g.org/misc/ntfs-hal-2008-06-12.txt
>  http://ntfs-3g.org/misc/ntfs-hal-2008-06-17.txt
>  http://ntfs-3g.org/misc/ntfs-hal-2008-06-29.txt
> 
> Our conclusion was that either HAL should provide the config because
> it's the only one which knows its internal changes, so it can keep 
> compatibility and consistency with itself, or some other type of
> automount should be used.
> 
> We would gladly do whatever is needed to support smooth automount 
> but we got completely stuck how this could be achieved without direct 
> HAL support.
> 
> > > b.) should be locale= option be provided by a fdi shipped within
> > > the ntfs-3g package?
> > 
> > Also yes. 
> 
> Please see http://ntfs-3g.org/misc/ntfs-hal-2008-06-12.txt
> 
> We would have done it long ago if this would be sanely feasible.
> 
> > Always the package that introduce something new, which isn't part
> > of the basic system (as e.g. libmtp for supported MTP devices)
> > should deliver their own fdi files to provide correct policies and
> > behavior.
> 
> NTFS-3G is part of the basic system for many distros. Due to lack of
> HAL support, all of them invent its own workarounds which keep get
> broken by HAL upgrades and other workarounds. 
> 
> > > Other ideas, comments?
> > 
> > I'm not sure if overwriting the fstype in HAL (as ntfs-3g
> > apparently do) 
> 
> NTFS-3G doesn't do anything with HAL: no fdi file, no modification 
> anywhere, etc. It just installs the driver binary and the 
> /sbin/mount.ntfs-3g mount helper. 


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 behavior 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 :-)

-RW


-------------- next part --------------
A non-text attachment was scrubbed...
Name: 10-ntfs-3g-policy.fdi
Type: application/octet-stream
Size: 481 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/hal/attachments/20081010/f15dfa48/attachment.obj