2014/1/21 Thomas Lübking <thomas.luebk...@gmail.com>:
> On Dienstag, 21. Januar 2014 13:37:29 CEST, viv...@gmail.com wrote:
>
>> And windows?
>
>
> HPFS/NTFS has xattr support (through alternative data streams) and WINNT
> supports handling xattr on FAT as well.
>
> The problem about xattr is rather that 99% of all ext3/4 users will atm get
>
>   setfattr: <filename>: Operation not supported
>
> ie. xattr nowhere being activated.
> This would have to change dramatically in order to make a xattr
> implementation useful.
>
> Next thing is global xattr awareness, ie. one has to consider that even if
> kio/dolphin would have great xattr support and cp aliasing -a by default
> etc., the user might move/copy the data using nautilus or some other lousy
> filemanager :-P
>
> I *do* consider xattr the BY FAR more sane approach to the problem, but
> currently do frankly not see this on end user desktops :-(
> Linux/Desktop has to become a "xattr OS" before relying on it - thus imo
> xattr support could only be explicitly optional to get there.
> Otherwise ubuntusers™ will complain loosing their metadata all the time.
> "Unfortunately" this isn't MacOS where SJ. just said: "do or you're fired,
> you <censored>!"
>
>
> Keeping metadata in id3v2/xmp/iptc unfortunately only covers few filetypes
> (w/o invoking sidecars, ie. what __MACOSX does when entering the outer
> world) - directories could be stored in ".directory"

xattrs are not available in neither NetBSD, DragonFlyBSD nor in
OpenBSD (which will ship 4.11.5 in the next release). And what's for
read-only mounted file systems?

And what will happen if the file with xattr is saved on a flash drive,
and then transferred to another computer? In case with separate DB
it'll be just "lost", maybe not immediately. In case of xattrs, other
user will receive this info, which is not good itself at least. And
this may cause Baloo misbehaving, no?

I'm all for improving current situation with Nepomuk, and appreciate
any steps in this direction a lot. But, please, do not use xattrs
here: in the best case you'll have two totally different codepaths
that you'll have to manage.

--
  WBR,
  Vadim Zhukov

Reply via email to