Bug#408948: .volume might be needed too as well as full pathnames
lool at dooz.org
Wed Feb 14 11:49:12 CET 2007
On Wed, Feb 14, 2007, Josselin Mouette wrote:
> As for fixing #408556, I suggest the following course of action:
> * for computer:// and applications://, allow all .desktop files;
> * for network://, dns-sd:// and smb://, use clever filters;
> * for file://, only allow files belonging to the user or to root;
> * for all other cases, treat them as text.
(I've sent a detailed analysis of the smb:// URLs and network:// URL in
> A more elegant way to fix network:// and the like is probably to give
> autogenerated files another MIME type, like
I'm not sure we foresee all the consequences of such a change, and I'm
not sure why we would need to treat as "virtual" the .desktop files
below computer:// and not below sshfs://.
> This would allow to easily distinguish
> them from any user-created files, as there is no way the fd.o database
> would return this MIME type when queried.
The shared mime info DB can be queried, even for the virtual files.
I'm not sure it is, but the virtual .desktop file contents would match
> All these changes require a shlibs bump for gnome-vfs and the last one
> requires a conflict against nautilus versions not understanding this
> MIME type.
I'm not sure why we would need a shlib bump if we only change gnome-vfs
to return a different MIME type for smb-root. The API doesn't change,
and while the ABI changes at some level, we need to adapt the
applications, not simply rebuild them; it's a kind of transition where
we will have to raise build-deps and deps on libgnome-vfs in some
applications (well, in nautilus), so I think we should simply add a
versionned dependency in nautilus, for example a conflict. IOW,
versions of nautilus which refuse handling "smb-root" as a desktop file
should conflict with versions of gnome-vfs providing "smb-root".
Loïc Minier <lool at dooz.org>
More information about the Pkg-gnome-maintainers