Mime types for folders
stefbon at gmail.com
Tue Feb 8 05:51:53 PST 2011
2011/2/8 Křištof Želechovski <giecrilj at stegny.2a.pl>:
> Dnia wtorek, 8 lutego 2011 o 12:40:25 Stef Bon napisał(a):
>> Well, I'm building a construction which also requires/provides
>> information about a directory.
>> for example:
> This is a locator (audio:/), not a media type.
> These are block devices, not directories.
Yes they are, at least in the construction I'm working on.
I've been postig about that earlier here.
In short, it creates a different environment for the user, hiding the
standard system directories like /bin, /dev, /lib etcetra.
The directories visible to the user are:
The standard directories are there, but hidden, through the use of a
fuse fs (fuse-workspace-ll) and pamchroot oa.
Now the Network map looks like:
and this contains BONONLINE, a smb workgroup. Going futher there are
servers and shares.
The map Computer contains the hardware, like ata and disks, and yes
formatted and unformatted.
They are all represented by a directory, where the mountanble
(=formatted and supported fs) are redirected by fuse to a special
setup of the automounter.
So in Computer:
entering these mounts them (somewhere at /mnt/..) and shows the
contents (also) here.
Now I'm using the subtypes I've already mentioned.
So yes, a smb share is a remote directory, and the local environment
hgets extended information
about what it is and more via extended attributes.
getfattr --name=system.workspace_uri %path%
but some sort of information is also good as mimetype.
The environment should know somehow a file is not local, but remote.
And the construction I'm working does not depend on KDE, or Gnome. It
can also be used with a text login.
See more info:
>> I've called them subtypes. Well what's in a name, but I've used the
>> name type already in the software I'm working on.
>> Well according to Chris the pattern can be set like:
> I rather advertised "inode/directory;role=kde.desktop.images.user".
> An SMB share is a remote inode, and the difference is in the location, not in the media type. You may want to use a separate subtype for that to express the fact that the access protocol is different; I am not sure whether it would be the right thing to do though because the SMB access protocol was specifically designed to mimic the directory features present in the kernel filesystems. (This is even more obvious with NFS where the network extension is built into the kernel.)
More information about the xdg