trash specification: Why do we keep around .desktop files for metadata?
chris at gnome-de.org
Sat May 26 09:04:35 PDT 2007
Am Samstag, den 26.05.2007, 02:23 -0400 schrieb Liam R E Quin:
> > Using FAT32 for permanent storage is not recommended, and it's not used
> > on a daily basis anymore, so we shouldn't consider that an argument
> > against extended attributes.
> "not used on a daily basis"? by anyone on the planet? I don't believe
> you. :-)
We shouldn't write specs for everybody but for the vast majority, if it
massively reduces implementation complexity. Of course, the USA could
still use AM for audio broadcasting, and not using SI units in science
would make it more simple for people who already know how to measure in
knots, yards and gallons.
Local file systems that do not support extended attributes should simply
be considered legacy. Of course, there are also new file systems
developed that don't have extended attributes, but they're either not
targetting everyday computer use, or have no chance of being used by a
big group of people (like Reiser4, pending Linux kernel inclusions for
quite some years). See Wikipedia  for a list of common file systems,
and see for yourself! Heck, most of them even those not supporting
metadata don't even support file ownership (like FAT32, for the
Command-line applications implementing our spec would have to implement
INI file parsing, which is a no-no. Also, you can easily destroy the
entire trash consistency using binutils, as the spec *requires* "(t)he
$trash/info directory (to contain) an “information file” for every file
and directory in $trash/files".
Maybe you could name me a use-case where a file system that doesn't even
support ownership (aka FAT32) can be used as something else as a
top-level data dump, and hence would require sophisticated path
restoring facilities? 8.3 filenames are so 1990.
Note that even the first SSH protocol draft from 2001 includes extended
attributes. We're approaching 2010, and while supporting file systems
that are mostly of historical value is a good thing, we shouldn't care
about new features for them.
Christian Neumair <chris at gnome-de.org>
More information about the xdg