[alkonaut]

The problem is that the files are still there, if the application manages the files itself to get more functionality than the fileystem itself offers (i.e. like iTunes indexing the files), then if you move/rename files you have fooled the secondary index. So the problem isn't that apps can't/shouldn't manage the files themselves, the problem is that the index they use (e.g. a SQL table) isn't provided by the filesystem to guarantee consistency. If the filesystem provided a database like interface, then iTunes and Lightroom wouldn't have to have SQL tables for the files, and if you moved a file on disk you wouldn't have fooled the application.

[seszett]

Well, applications still can store their data in a large SQLite database (for example) and be immune to users moving files around. Require admin rights and put the database somewhere outside of user reach.

Now if you want files that are accessible both from inside and from outside the application, then you have to settle for a compromise somewhere, and that's what we already have with filesystems and the OS-provider access methods to them.

[alkonaut]

Exactly. The whole issue is the inconsistency with todays app-centric views of data (iTunes) and the fact that the path hierachy based view of the files will probably still be around for many years to come. I think the best solution would be for the OS/filesystem to provide a queryable layer on top which contains metadata and guarantees consistency without forcing the applications to lock in their data. I can't see how it would be very controversial, as it actually removes nothing, only adds.