> >On Mon, 2012-07-16 at 09:45 +0100, James Morris wrote:
> >> On 15/07/12 David Robillard wrote:
> >> >On Fri, 2012-07-13 at 15:57 +0100, James Morris 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?
> >> >
> >> >I just used the original name of the file, with a number added for
> >> >uniqueness if necessary (which is very seldom the case). It works
> >> >and is much more human-friendly and straightforward than the above
> >> >options. A "make this path unique by sticking a number on the end
> >> >of it" function turns out to be pretty useful anyway.
> >> >
> >> >Of course, you need to actually check for existence of files to
> >> >create it, which might be a problem in some cases (though not any
> >> >I've encountered), but anything that assumes a mapping based on the
> >> >current path is a unique identifier for a particular file's
> >> >contents is bound to fail anyway.
> >>
> >>
> >> Well I spent what time I had free over the weekend implementing the
> >> first option. I did take a look beforehand to see what NON-Daw did
> >> (it does what you recommend), but disliked how it didn't check for an
> >> existing symlink pointing to the file it was creating a new symlink
> >> for.
> >>
> >> I decided checking existence of one directory to be easier than
> >> examing each symlink in a directory to see where it points. However
> >> I'd not be surprised if these benefits were outweighed by other
> >> costs.
> >
> >FWIW, since I originally did quite a bit of advocating of this scheme
> >because of my experience doing it for plugins, I should mention an
> >important part of the system there:
> >
> >The *host* gets to make all these decisions.
> >
> >e.g. the host could make symlinks, or always copy, or use hashing and
> >copy when necessary, or just let things use absolute path references,
> >and so on. This is achieved with a callback to map paths to/from
> >state.
> >
> >It might be nice for a session manager to be able to do the same thing,
> >though this means a round-trip for each path, and is likely much less
> >feasible for a host of other reasons (a one-file C "library" to Do The
> >Right Thing is probably more useful), but I thought I'd mention it.
> >
> >Cheers,
> >
> >-dr
>
>
> Any thoughts about symlinking to symlinked samples?
>
> I decided to follow symlinks when storing sample paths in memory and
> then recreate the symlink path when saving. This avoids symlinking to
> symlinks. I believe it provided some other minor benefits but can't
> exactly recall what they were now.
>
> james.
>