Re: automounting / autorunning

[Alexander Larsson <alexl redhat com>]

On Fri, 2008-01-18 at 03:23 -0500, David Zeuthen wrote:
> 
> This would include local files (such as from harddisks) but also some
> networked mounts like Bluetooth (BT is really a network connection) as
> well as mounts with user space file system drivers such as cdda:// and
> gphoto2://. For the latter, we need to sniff the content to e.g. sniff
> the media and detect the DCIM/ directory so we can ask the user if he
> wants to start f-spot etc.
> 
> Does that make sense? Maybe if we called it 
> 
>  g_mount_is_fast()
> 
> it would better reflect what I'm getting at. However, that name sucks
> too. Naming is hard. Film at 11 ;-)

Thats exactly the reason I asked, because we have a history of
misunderstandings and problems using "local" in API. We used to have
gnome_vfs_uri_is_local(), that basically returned TRUE for file: uris,
and FALSE otherwise. Then someone complained that their NFS mount was
reported as local, and code was added to make it return TRUE for NFS
files, which promptly broke a bunch of code that used it to check for
file: uris. It also severely changed the performance characterestics
from a string compare to a very complicated I/O operation involving
mtabs and whatnot which lead to other problems.

And of course, for the cases where people were using is_local() for
something other than looking for file:// the new code wasn't all that
good either. Some NFS mounts are faster than local disks and/or are
generally uses as "fast" "local" storage (say a NFS home), and suddenly
it was marked as slow, and bunched together with ftp mounts from the
other side of the world...

So, the lesson to learn here is that "local" isn't a well defined word,
and should be avoided in the UI. Instead we should use specific well
defined names, and if we need add multiple of them instead of combining
use of a vague one for several things.

In this case, maybe something like g_volume_should_automount()?