On Tue, 2012-03-27 at 14:24 +0200, Emanuel Rumpf wrote:
I am having a hard time imagining anything *less* likely to be adopted
than trying to cram a *database* down everyone's throats to save some
I think I'll just avoid going into the why and say: not in a million
> - What if any of the symlink to symlink is deleted - do applications
What if a file is deleted? What if the entire file system is wiped?
Users can remove files, film at eleven. Nothing to do with symlinks.
> - Some apps would want to store additional info relating to the file
So? Apps can store whatever they way. If you are crazy and want to
store a binary database in there instead of a sane file format, feel
No session manager that forces everyone to use some database would ever
fly. This is obvious.
> - having symlinks leaves the user with the question how to reliably
That is inherent to any solution with "links" to external resources.
Links to external resources are a requirement. If you want to move a
session, use a smart tool that can fix the links, or archive it.
The argument for these having to be separate is because otherwise the
copies would pollute the namespace. Also remember files can be created
before save time.
> For an app, there may be a semantic difference for
A file outside the session is a file outside the session. Happening to
be in a directory that happens to be a different session makes no
> that's what I meant above, in 2.
You keep bringing up this "what if the user deletes a file that is used"
problem as if there could possibly be a solution. Obviously there can
not be. Yep, users can delete files. That is not a criticism of any
In reality this is not a problem. Users have a pretty good idea that if
they go screwing around with e.g. their ardour session and start
deleting files, something is probably going to break. Don't Do That.
> 1. large files should never go to the session directory
Why? What exactly is "large"? Just because a file is large doesn't
mean I don't want it in a session. It is a requirement to be able to
roll up a self-contained archive of a session *if* you want to.
> 2. Lfiles shared between apps have to be managed by a (super-)
Why? It's perfectly clear. A file is a file.
> 3. Lfiles newly created (recorded / modified ) - for ALL sessions - go
Doesn't really matter. You can use one. You can use many. Whatever.
And why does the Grand Centralized Session Manager File Authority need
to do this? What exactly is the problem that all these rules and
> 6. The SM knows all files-in-use and is able to move unused
The only thing you need to be able to clean up is the location of the
latest snapshot, or the snapshots you want to keep. The rest is a
classic garbage collection. You do not need a blessed centralized file
location for this. It doesn't even make it any easier.
> IF I did not forget / oversee anything critical, this looks like a well managed
To be honest I don't think this dissection of the problem really makes
much sense. Basically in a quest to have a database for a database's
sake you've merged all the directories, requiring a database or at least
index file to keep track of all the special different "kinds" of files
in there, and requiring a big fancy session manager to actually do all
of this. In the process nothing has been won.
Nobody ever got fired for using hierarchical directory structures with
files in them. KISS.
Linux-audio-dev mailing list