Am 27. März 2012 03:23 schrieb David Robillard <[email protected]>: > > > ... What you end up with is a few directories > with specific roles. > ... > ... > Figuring this all out was a long process of trial and error, but now > that I write it down it seems clear it can't be simplified without > failing to meet a requirement. I am all ears for arguments to the > contrary, though. >
Thanks for pointing out, David. 1. I don't totally agree with using symlinks: - I tend to think, that file-systems are not as efficient as databases - I feel that symlinks pollute the file-system - What if any of the symlink to symlink is deleted - do applications still know, where the file is which they had been pointing too ? - Some apps would want to store additional info relating to the file (meta-data, tags, related info, ...), thus requiring a simple database anyway. - having symlinks leaves the user with the question how to reliably copy a directory, without messing up everything (dereference yes/no, follow links yes/no ...), something that is critical to deside 2. I don't totally agree with a file- vs. copy-directory: I mean: is there really a semantic difference between a created, a modified file and a copy ?? I think no. After modification, creation, duplication, etc., soon you won't be able to say, weather a file is a any of the above. I mean: For one app it can be a file (original), while for another it can be a copy / reference / whatever. For an app, there may be a semantic difference for A: existing files a user added, which are ORIGINALS (thus refs), never-modified ones B: files the app created or modified, thus copied - files that are NEWONES (thus real and refs) note: a modified or created file can become an ORIGINAL for a different application ! that's what I meant above, in 2. C: files that are HISTORY, the user may want to delete these anytime, to store space - a history-file can become an "original" - what now ? My conclusion: - - 1. large files should never go to the session directory 2. Lfiles shared between apps have to be managed by a (super-) instance that knows what's going on - the session-manager - otherwise it's completely undefined/unclear what happens 3. Lfiles newly created (recorded / modified ) - for ALL sessions - go to a common NSM-Lfiles directory 4. The session manager knows, of EVERY reference to files inside the NSM-Lfiles dir., distinguishing between - CURRENT_REFS (files currently used by any instance) - HISTORY_REFS (file not currently used by any instance) (this is equal ALL_FILES minus CURRENT_REFS) - EXTERNAL_REFS (files referenced by any instance, but not contained in the NSM-Lfiles dir. and NOT created/recorded/modified by any instance ) 5. this means, the user is disallowed to manually reference/link to any of the files contained in the NSM-Lfiles dir (because the SM wouldn't know about it) 6. The SM knows all files-in-use and is able to move unused history-files to a dustbin (no app is allowed to use/reference files within the dustbin). The dustbin can manually be deleted by the user anytime. 7. The SM allows Lfiles (CURRENT_REF + EXTERNAL_REFS) for a certain session or app to be copied to a user-defined directory (export-function) 8. The SM allows HISTORY_FILES to be moved to a dustbin folder. (not including CURRENT_REFS or EXTERNALS) IF I did not forget / oversee anything critical, this looks like a well managed and reliable approach to me. Any opinions ? -- E.R. _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
