kevin.krammer at gmx.at
Mon Oct 11 07:14:13 PDT 2010
On Monday, 2010-10-11, François Revol wrote:
> (sorry Mail.app is too stupid to handle digests as separate mails)
> > De : Wei Jiang <_weijiang_ at yahoo.com>
> > Date : 21 juin 2010 13:49:55 HAEC
> Aw, that's old :)
> > À : xdg at lists.freedesktop.org
> > Objet : Trash specification
> > Hi All,
> > The Trash specification is very good. It is intent for Unix, but it is
> > good for Windows as well, with minor modification.
> > I have implemented it for a cross platform (Unix and Windows) file
> > manager Acelet Filer at http://www.acelet.com/desktop/filer.html.
> > I would like to comment about the Trash specification from my experience:
> > $XDG_DATA_HOME is difficult to implement.
> > It is almost out of the capacity of trash implementer. Maybe I can modify
> > .bashrc to add that environment variable, but the user may delete it
> > later. I have checked Ubuntu 9.40 with Nautilus, $XDG_DATA_HOME is
> > undefined.
> > Instead, I would suggest an alternative:
> > Call the program, which implements the Trash specification, with option
> > -info homeTrashDirName to get the trash directory name.
> In Haiku just as on BeOS, we have a C/C++ API to get specific directories,
> find_directory(). There is a finddir command that allows shell scripts to
> use it.
> I believe this way is less fragile than having to export env vars, which
> can be stripped off the env when performing remote login (ssh).
> Also, this allows to return a different path depending on the
> volume/filesystem and even uid.
That's covered in the trash spec, AFAIK.
Anyway, I was just pointing out that the user local data path is always
specified, either by definition of the default or override through environment
> Typically for trash, it's possible to return the path that correspond to
> the user for the /home mountpoint, but return the NTFS-specific path for
> this fs. This way files can be moved to trash without having to be moved
> across mountpoints.
Also covered by the trash spec.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 190 bytes
Desc: This is a digitally signed message part.
More information about the xdg