Question (adding some baloo devs, Manu feel free to answer too): Does that make sense for Save As too or only for Save?

For "Save", I would definitely vote for "preserve as much as possible".

For "Save as ...", I am not sure. There are pros and cons for both possibilities.

Cons:
- It may lead to information leakage. Tags, comments, origin-url ...
- Attributes may no longer apply

Pros:
- It still is mostly the same file
- Manual transfer of attributes is time consuming


Baloo itself does not care either way. As the file is created as a copy (and the old one deleted), it is just a new file which happens to have the same path.

mmmm...that's a good question. I would also do it for "Save as...". When I do "Save us" I expect I'll get a "exact" copy. Anyway, my use case is only for "Save", so I'm fine either way :)

Thanks for looking at this, by the way!!

Good question indeed. Definitely a yes for the save case. For Save As I am leaning slightly towards preserving as well.

What would happen if this information was part of the file (rather than in the extended attributes)? It would be copied/saved as part of the file and managed within the app...

maybe out of my depth here, but I think that goes against the baloo philosophy: if you do that, then *every* program handling the file must know about those attributes (acrobat reader, e.g., would probably crash); extended attributes are handled by the file system and you don't have that problem

(In reply to tagwerk19 from comment #5)
> What would happen if this information was part of the file (rather than in
> the extended attributes)? It would be copied/saved as part of the file and
> managed within the app...

There is no "if ..." here.

Any metadata part of the file is in the scope of the application. Applications may or may not preserve any metadata (and sometimes it is not possible to preserve metadata, i.e. when you convert files to a different format without (structured) metadata).

(In reply to Manu from comment #6)
> maybe out of my depth here, but I think that goes against the baloo
> philosophy: if you do that, then *every* program handling the file must know
> about those attributes (acrobat reader, e.g., would probably crash);
> extended attributes are handled by the file system and you don't have that
> problem

How is this related to baloo? Baloo just takes any metadata there is, and does not care if it is stored inside the file or in extended attributes.

(In reply to Stefan Brüns from comment #7)
 
> There is no "if ..." here.

The naive view is applications ought to read, copy, save info in the extended attributes _as_if_ it was embedded in the file. It's a least surprise thing.

If it's not possible (because of the filesystem say), they ought to give a warning...

(In reply to Stefan Brüns from comment #8)
> (In reply to Manu from comment #6)
> > maybe out of my depth here, but I think that goes against the baloo
> > philosophy: if you do that, then *every* program handling the file must know
> > about those attributes (acrobat reader, e.g., would probably crash);
> > extended attributes are handled by the file system and you don't have that
> > problem
> 
> How is this related to baloo? Baloo just takes any metadata there is, and
> does not care if it is stored inside the file or in extended attributes.

I was thinking about special Baloo stuff (such as tags and comments) which do not depend on the particular file type (I didn't mean e.g., the bit rate in an mp3 file or the width and height of an image). I think Baloo (since a few years ago, anyway) stores/extracts metadata of the first kind into/from extended attributes. But I don't know that much about this...so maybe I'm wrong

Any update on this? I still find this kind of annoying. I understand the "Save as" scenario is a moot point (I would still go for "also keep them"), but I think just saving should keep them (that's what, e.g., Kate does).