22 Jul
2012
22 Jul
'12
2:14 a.m.
On 21/07/12 "J. Liles" <malnourite(a)gmail.com> wrote:
On Sat, Jul 21, 2012 at 3:50 PM, James Morris
<james(a)jwm-art.net>
wrote:
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.
On 21/07/12 "J. Liles" <malnourite(a)gmail.com> wrote:
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... On Fri, Jul 20, 2012 at 5:24 AM, James Morris
<james(a)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.