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

[Danny Kukawka]

On Freitag, 10. Oktober 2008, Robby Workman wrote:
> On Fri, 10 Oct 2008 22:13:53 +0300 (EEST)
> Szabolcs Szakacsits <szaka at ntfs-3g.org> wrote:
[...]
> > 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.  

That is also what other packages do. I don't see a problem here. If we define 
a way to go from now on, than there will be no changes in the next time 
anyway. And the if there are may changes, the old format will still be valid 
for at least the next 6 months. That should be doable, or not?

> > > 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.

No, IMO the HAL interfaces are normally relative stable. We always try to 
prevent changes in the spec if possible and we have a defined time of 
compability.

> > 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.

As already said: If we find a way to go, the generic way/properties will be 
stable for a long time. If you need to change the mount options, it's up to 
you to change the fdi-file in your package. 

I assume that ntfs-3g gets updated more often that HAL. If you rely on HAL you 
can't update ntfs-3g without a HAL update, but if you provide your own 
fdi-file you can update without a HAL relase.

But back to my proposal:
> Maybe we need to change the way HAL currently handles the mount options. I
> think currently about a solution as we have for music player which need a
> special lib to work:
>
> - volume.fstype.alternative (strlist) e.g. ntfs-3g, ntfs-fuse
> - volume.fstype.[alternative].valid_options (strlist)
>   --> volume.fstype.ntfs-3g.valid_options={'locale=','uid=',...}
>   --> volume.fstype.ntfs-fuse.valid_options={...}
>
> This would allow to handle the special mount options an non default fstype
> handler like ntfs-3g or a fuse-fs needs. But this would also mean that the
> desktop needs to adapt to the new properties to be able to mount ntfs-3g.

Any comments on that?

Danny