Moving Baloo forward
vivo75 at gmail.com
vivo75 at gmail.com
Tue Jan 21 12:06:40 GMT 2014
On 01/21/14 11:50, Vishesh Handa wrote:
> On Tuesday 21 January 2014 02:24:01 Francesco R. wrote:
>> just always use an additional database, xattrs are not the way to go.
>> Managing xattrs require a conscious user, many programs by default don't
>> even copy xattrs.
>>
> I disagree. It'll be easier to backup / restore xattr than it would be with
> that database. Additionally, a LOT of tools do respect extended attributes (cp
> with the -a flag), in contrast Nepomuk has never copied any metadata. I doubt
> I can implement it with the extra database as well.
>
> Plus, with extended attributes the metadata is never lost. With the additional
> database, if the file is moved to a place which is not tracked, then the data
> will be lost.
So we agree to disagree ;)
especially on the never lost part, when moved with kio they will be
lost, when using unix command line programs, and without special
arguments they will be lost.
Most important of all they are normally hidden, more hidden than a .dot
file, an additional database, even a .dot file is much more easy to
remember.
$ echo "Hello" > a
$ attr -s simple.attibute -V "test for xattr" ./a
Attribute "simple.attibute" set to a 14 byte value for ./a:
test for xattr
$ kioclient cp a b
$ attr -l b
<empty>
$ cp a b
$ attr -l b
<empty>
$ cp -a a b
$ attr -l b
Attribute "simple.attibute" has a 14 byte value for b
$ rm b
$ rsync a b
$ attr -l b
<empty>
$ rsync -X a b
$ attr -l b
Attribute "simple.attibute" has a 14 byte value for b
add tar, zip to the list
>
>>> I still have to implement this.
>> maybe start without additional metadata, but xattrs must not reach user
>> systems
>>
> Nope. I really think extended attributes is the way to go. There is also an
> XDG standard for extended attributes [1]
>
More information about the kde-core-devel
mailing list