[LAD] samples/symlinks/sessions

[James Morris]

On 21/07/12 "J. Liles" <malnourite at gmail.com> wrote:
>On Sat, Jul 21, 2012 at 3:50 PM, James Morris <james at jwm-art.net>
>wrote:
>>
>> On 21/07/12 "J. Liles" <malnourite at gmail.com> wrote:
>> >On Fri, Jul 20, 2012 at 5:24 AM, James Morris <james at jwm-art.net>
>> >wrote:
>> [..]
>> >>
>> >> 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.
>> >>
>> >
>> >When does this situation come up? The whole point of the symlinks is
>> >simply to permit some kind of session portability without the
>> >session manager or user having to understand the project format.
>> >So, for that purpose, nothing really matters except that a tar or a
>> >copy should include all (within reason) of the external resources
>> >the session requires.
>>
>> User creates session. User then creates 2nd session and wants to
>> use same samples as 1st session but, for whatever reason, rather than
>> loading samples from original paths, goes instead to 1st session dir
>> and loads the samples from that.
>>
>> User then decides to delete 1st session thereby breaking 2nd session.
>
>Nothing is fool-proof...

No, of course not. Looking back at what you said though, usage of
symlinks should be transparent to user. My framing of the issue was
skewed by sprawled thoughts ;-)

Not so much should symlinking to symlinks be allowed as should my
program deal with symlinks or the files they point to?

Now I see the symlinks should be transparent to user (at least until
they want to tar -h it) meaning: present user with the files the
symlinks point to, that is, the files the user originally specified in
the first place.

Forgive the clunking-brain noises!

james.