On 13/07/12 renato <[email protected]> wrote: >On Fri, 13 Jul 2012 16:11:23 +0100 >James Morris <[email protected]> wrote: > >> On 13/07/12 James Morris <[email protected]> wrote: >> >Hi, >> > >> >My sampler app has Non Session Mangement implemented but is >> >currently still referring to external files by their original path. >> > >> >I want to use the symlink method as discussed fairly extensively >> >here but I'd like to know if there is any recommended strategy for >> >naming the symlink of a sample. >> > >> >It could so happen that as far as the filesystem is concerned the >> >only discerning uniqueness between two samples is in the path (ie >> >kit1/snare1.wav and kit2/snare1.wav). >> > >> > >> >I've come up with three possible solutions to this (in my current >> >order of preference): >> > >> > >> >1) symlink-to-sample created in a subdir named using a hash* of the >> >full path to external file >> > >> >2) painstakingly re-create the full path within the session dir and >> >add the symlink into that. >> > >> >3) some horrible text manipulation of the full path (ie replace / >> >with _) that is bound to fail. >> > >> > >> >* J. Liles mentioned SHA1 here: >> > http://linuxaudio.org/mailarchive/lad/2012/3/30/189343 >> > >> >Are there other/better options or disagreements about (1) being a >> >good choice over the other options I've presented? >> >> Have just realized that a problem with (1) is the loss of information >> contained in the naming of the path. Is that a problem or not? >> > >if it's a symlink, one could just see the path to original file with ls >-l ? > >renato
Yes while it is a symlink but if archived with tar -h then only the basename + extension will remain. A future user might find information encoded in the path (ie name of sample library) helpful (corrupt sample?). Perhaps a small text file showing the path could be added. I like the idea of hashing the path, as descending through multiple levels of nested-but-otherwise-empty sub directories is irksome. james. _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
