Re: [PATCH] Allow to mount/unmount volume from within target URI

[Alexander Larsson <alexl redhat com>]

On Tue, 2006-02-14 at 15:39 +0100, Christian Neumair wrote:
> On Tue, 2006-02-14 at 15:36 +0100, Christian Neumair wrote:
> > On Mon, 2006-02-13 at 10:25 +0100, Alexander Larsson wrote:
> > > On Fri, 2006-02-10 at 22:43 +0100, Christian Neumair wrote:
> > > > On Tue, 2006-02-07 at 11:38 +0100, Alexander Larsson wrote:
> > > > > On Sun, 2006-02-05 at 14:11 +0100, Christian Neumair wrote:
> > > > > > The attached patch is meant to allow the user to modify a volume from
> > > > > > within its target directory. It's not very well-tested. For instance,
> > > > > > I'm not sure whether not setting the volume in
> > > > > > libnautilus-private/nautilus-directory-async.c:link_info_done if the
> > > > > > volume_id is NULL causes some problems when unmounting a volume.
> > > > > 
> > > > > The general approach of having the link-to-volume object set the status
> > > > > of the destination is wrong. It means the destination will work
> > > > > differently depending on if the link to it is shown.
> > > > 
> > > > Here we go. This one adds a new volume monitor which only deals with the
> > > > target URIs, and adds context menu entries to the file menu, the
> > > > background and the location context menu, and also reorders the
> > > > selection-related mount/unmount items to be above "Properties" for
> > > > consistency reasons. It extremely improves my Nautilus experience and I
> > > > really think it's worth to breaking a few freezes.
> > > 
> > > I don't like this patch, it always keeps all mountpoints always open,
> > > which might lead to problems with unmounts, and it totally changes what
> > > nautilus_file_has_volume/drive() means (it used to mean "this file
> > > represents a volume, but now its also used for normal folders). 
> > > 
> > > I also think we don't need anything as complicated as a separate
> > > monitor, since all it does is proxy information from the vfs monitor.
> > > The only thing you need is to map from folder uri to what drive/monitor
> > > is mounted there, and this info is availible using
> > > GnomeVFSVolumeMonitor. Ideally there would be an API for it, but you can
> > > just get all the volumes and look for it manually. This is not really a
> > > performance problem, because there are not typically many volumes/drives
> > > active, the objects are all in-memory, and this check is done seldom
> > > (i.e. not for every file when loading a folder).
> > 
> > I hope you prefer this one.
> > 
> > I have no clue why I'm experiencing refcount issues. I initially thought
> > it'd be my fault but even when adding multiple gnome_vfs_volume_ref and
> > gnome_vfs_drive_ref calls, I had crashers. The volume monitor getters
> > seem to dup the internal lists and ref each drive/volume, so I think I
> > got the refcount right.

It is your fault:

+		list = gnome_vfs_volume_monitor_get_mounted_volumes (gnome_vfs_get_volume_monitor ());
+
+		for (l = list; l != NULL; l = l->next) {
+			*volume = l->data;

This always returns the last volume, not reffed, if there is not volume
for the current dir.

Also, does the src/file-manager/fm-tree-view.c changes do anything but
reordering code?

Anyway, this looks like a much better approach.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's a lonely amnesiac ex-con on the run. She's a time-travelling mute museum 
curator with only herself to blame. They fight crime!