[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fuse-devel
Subject:    Re: [fuse-devel] special FUSE ioctl
From:       nf2 <nf2 () scheinwelt ! at>
Date:       2007-07-13 11:35:11
Message-ID: 4697636F.5040705 () scheinwelt ! at
[Download RAW message or body]

hi Jan,

Jan Engelhardt wrote:
> On Jul 12 2007 13:54, nf2 wrote:
>   
>> the main purpose would be something like getxattr() for entire 
>> file-systems ("xstatvfs" - a kind of extended statvfs),
>> returning a list of key/value pairs:
>>
>> * internal connection status
>> * busy/idle
>> * number of connections
>> * if the connection is dead (someone pulled the servers network cable):  
>> counts of reconnect failures...
>>     
>
> What I say: no other filesystems do anything like this, and I doubt it would
> even be meaningful for them (number of connections for ext3, anyone?)
>
>   

sure - that's why i thought of key/value pairs... only network 
filesystems like sshfs, curlftpfs... need this feature...

>> additionally this "xstatvfs" should expose hints for 
>> desktop-file-management which the user has specified when mounting:
>>
>> * create .Trash or not
>> * render previews
>>
>> i know this would also work with getxattr() on the root "/" of the 
>> FUSI-filesystem, but doesn't this look a bit like a hack...?
>>     
>
> Consider the case where
>
>  - user B cannot write to / to update xattrs
>
>  - user A wants previews, but user B does not.
>
> Aside that, if root really wants no previews for /, he should set that
> in an xattr.
>
>   
only the person who mounts, knows if the server is a local file-server 
in the next room (where .Trash and previews make sense), or a ftp-server 
of a customer, 100 miles away, where both things would cause problems. 
Those "hints" would be set in the mount-options, the exposed xattrs 
would be read-only. It file-managers have a way to ignore those "hints", 
it's their business.... ;-)

my "use-case" for FUSE is mainly desktop-controlled private user mounts 
into their home-directory (similar to what KIO and Gnome-VFS provide 
with their "network-transparency")... (see libfusi/gfuse-manager)

>> (btw: is getxattr() available everywhere where FUSE is?)
>>     
>
> Yes and no. Some operating systems (e.g. Solaris) have xattr support, but some
> filesystems (e.g. Solaris-UFS) do not. And FUSE filesystems only have it if the
> user cared to implement support.
>   

the question is, if all operating systems nowadays are compiled with 
xattr support so that FUSE filesystems could eventually expose their 
"meta-information" that way.

>   
>> other use cases, perhaps, would be running special commands on file-systems:
>>
>> * turning on/off logging
>> * implementing a "file-copy on server" function - AFAIK some filesystems 
>> (webdav) have this feature... (rather use fcntl for this?)
>>     
>
> No, this copy-on-server is/must be a filesystem-agnostic operation. The best
> you could do (I can come up with) is to implement copy-on-server is to change
> your FUSE's hardlink function to do the server-side copy.
>
>
>
>   

why does it have to be file-system agnostic? file-managers just have to 
check if the feature is available... hard-links sound a bit dangerous, 
cause it might happen that file-managers mistakenly create hardlinks on 
a local file-system... :-(

norbert







-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
fuse-devel mailing list
fuse-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fuse-devel
[prev in list] [next in list] [prev in thread] [next in thread]