Re: User-defined mountpoints in GVFS



Alexander Larsson wrote:
>On Sat, 2007-07-21 at 08:00 -0700, Vlad wrote:
>> Hi,
>> 
>> Will the user be allowed to choose the mountpoint of a 
>> GVFS-managed resource? For example, someone may want to
>> have >> sftp:/username server school edu/home/username/research
>> mounted at /home/username/research/school on their local
>> computer.
> 
> No, all fuse mountpoints are handled by one mount, and that
> will be put in somewhere like ~/.gvfs. However, you could
> make symlinks to make it appear in other places.

Yes, symlinks would work.

> We really need the mapping between GVFS location and fuse
> mount to be "simple" to do in both directions (i.e. doing
> no blocking i/o).

I suggest storing a user's remote resources and
corresponding mountpoints in a tab-delimited text file
such as ~/.gvfs/mounts. Every line would represent one remote
resource, the first column containing the remote URL and
connection parameters (username, port #, protocol, etc)
while the second column contains the local FUSE mountpoint. Here is
a sample syntax:

-----------------------
sftp:22:username server school edu/home/username/research
/home/username/.gvfs/mountpoint1
smb:137:username 192 168 1 100/C/Program\ Files
/home/username/.gvfs/mountpoint2
-----------------------


Let's assume /home/username/research/school is a symlink to
/home/username/.gvfs/mountpoint1.  When a GVFS-aware application tries
to open the file /home/username/research/school/article.odt, GVFS will
do the following things behind the scene:

1) Resolve all symlinks to reveal the file's real path on the local
system. In our example, this is
/home/username/.gvfs/mountpoint1/article.odt.

2) Check if any of the mountpoints listed in the second column of
~/.gvfs/mounts is actually a prefix of the file's local path. In our
example, /home/username/.gvfs/mountpoint1 is indeed a prefix of
/home/username/.gvfs/mountpoint1/article.odt.

3) Remove the local prefix from the file's local path to reveal the
file's relative path on the remote server. In our example, this is
article.odt.

4) Append the result of step 3 to the remote URL listed in the first
column of the corresponding line of ~/.gvfs/mounts. In our example,
this yields
sftp:22:username server school edu/home/username/research/article.odt
and completes the mapping in the forward direction.


Now let's step through the mapping in the reverse direction. If GVFS
wants to know what is the local mountpoint of
sftp:22:username server school edu/home/username/research/article.odt,
it will do the following things:

1) Check if any of the entries listed in the first column of
~/.gvfs/mounts is actually a prefix of the remote URL in question. In
our example, sftp:22:username server school edu/home/username/research
is indeed a prefix of
sftp:22:username server school edu/home/username/research/article.odt.

2) Remove the remote prefix to reveal the file's relative path on the
local system. In our example, this is article.odt.

3) Append the result of step 2 to the local mountpoint listed in the
second column of the corresponding line of ~/.gvfs/mounts. In our
example, this yields /home/username/.gvfs/mountpoint1/article.odt.


As you can see, the above steps only involve manipulating strings
through regular expressions and do _not_ require communicating to the
remote server at all. The only I/O operation here is reading the
~/.gvfs/mounts file, but this can easily be resolved by caching the
contents of ~/.gvfs/mounts in memory.

Vlad


       
____________________________________________________________________________________
Yahoo! oneSearch: Finally, mobile search 
that gives answers, not web links. 
http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]