Bug#408948: .volume might be needed too as well as full pathnames

[Loïc Minier]

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
 GNOME #405291.)

> A more elegant way to fix network:// and the like is probably to give
> autogenerated files another MIME type, like
> application/x-desktop-virtual.

 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
 the magic.

> 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>