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

[Robby Workman]

On Fri, 10 Oct 2008 22:13:53 +0300 (EEST)
Szabolcs Szakacsits <szaka at ntfs-3g.org> wrote:

> 
> On Fri, 10 Oct 2008, Michael Biebl wrote:
> > 2008/10/10 Szabolcs Szakacsits <szaka at ntfs-3g.org>:
> > >
> > > 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.
> > 
> > Could you elaborate, why that didn't work out? What were the
> > problems wrt hal?
> 
> Please see my previously sent examples (arch linux, gentoo).
> 
> > If ntfs-3g is updated and the ntfs-3g package ships the fdi file, 
> 
> Ntfs-3g can not ship a file which works with most versions of HAL.
> 
> If we shipped several config files for the different HAL versions
> then we wouldn't be able to on-the-fly replace them when HAL changes.


Why not ship an fdi file that works with currently released hal source?
You can put an xml comment in there that says it's designed for
hal-$VERSION.  If/when hal breaks something with it, then you change
your fdi file and bump the version requirement.  No need to ship more
than one fdi file - packagers should be smart enough to figure out if
they need to keep shipping the older version, and users who decide to
upgrade from source had better get that way.


> > I'd expect the ntfs-3g maintainers to update the fdi file
> > accordingly.
> 
> Even if all ntfs-3g maintainers update the fdi file accordingly, this 
> doesn't help when users upgrade from source and the included fdi is
> not compatible with the installed or a later upgraded HAL version.


Most users don't do this.


> If HAL interfaces were stable then there wouldn't problem using a
> config file. But apparently this is not possible because it's an
> always changing target.
> 
> On the other hand, ntfs-3g is quite static from configuration point
> of view: only the 'dev' and 'suid' mount options should be denied.


If that's the case, then this isn't as big a problem as it seems IMHO.
As I said above, most users won't be upgrading any system software from
source, and of those who do, they'll be much more likely to need/want
ntfs-3g upgraded than hal.  

-RW