[PATCH] lost volume.mount_point when unmounting...

[Jonatan Liljedahl]

On Thu, 27 Oct 2005 11:38:23 -0400
David Zeuthen <david at fubar.dk> wrote:

> On Thu, 2005-10-27 at 01:31 -0200, Jonatan Liljedahl wrote:
> > > Why is this difficult? If you get the volume.is_mounted property
> > > change the device is not away in this case. If you need the mount
> > > point options use the key block.device instead to identify the
> > > volume. Or is there an other problem? 
> > 
> > I need the mount point when the device is removed (when
> > volume.is_mounted is changed to "false"). But at this time the
> > mount_point is already reset to "" which means I can't tell my
> > desktop environment (ROX) to remove the device from the panel. Maybe
> > it's possible to patch rox to allow id tags to be attached to panel
> > items so that they can be changed/removed by that id instead of
> > their path, but that's probably a lot of work.
> 
> So I think that what you need to do here is to keep a data structure
> associating the hal udi and the mount point, e.g.
> 
>  struct {
>    String udi;
>    boolean is_mounted;
>    String mount_point;
>  } Volume;
> 
> Note also that these two properties are updated as a single
> transaction, e.g. atomically... this means that the PropertyModified
> D-BUS signal actually tells your process (the client) that they were
> changed at the same time... libhal, IIRC, doesn't tell you this
> though... 
> 
> However.. you should just keep the mount_point around. Wouldn't this
> work?

Yes, that would work. But it would need specialities in ivman. It would
require either special handling of devices that has a mount_point, so
that ivman keeps an internal list of those devices and the mount_point
they got when mounted (when is_mounted was set to true), and then export
it's own variable: ivm.mount_point which could be used by rules in the
config files instead of hal.volume.mount_point. In other words these
things would need to be hardcoded in ivman since they would not be
possible to express in its configuration files. Unless variables were
added to ivmans configfiles, so that when the device got mounted a
variable (local to that device udi) could be used to remember the
mount_point and then used again when unmounted. But then, why not just
add the variable as a property to the device list of HAL instead of
keeping a remember_mount_points list around? =)

I don't understand why it's so bad to have volume.mount_point kept at
the old value when a volume is unmounted?
Would it be possible to create an .fdi file that added a property:
volume.had_mount_point each time volume.mount_point was set to anything
other than "" ? If so, i'd be happy becouse it's easier to drop an .fdi
file in a dir than to maintain a patch. =)


/Jonatan    -=( http://kymatica.com )=-