challenging problem involving symbolic links

Hello,

I'm working on an application that bridges together several
applications involved in creating a video workflow for editing with
digital cinema cameras. The main platform is MacOSX.

Because of the nature of some of the utilities for working with this
video footage I must spoof filenames by using symbolic links to
essentially rename files. This hack works great most of the time, but
on some systems (possibly Leopard systems) it runs into problems.

The second is sometimes the program will load a symbolic link, but it
will refer to it by a /Volume path instead of by a path from root. So
for example it will refer to the path to the symbolic link as /Volumes/
Macintosh HD/Users/Username/Desktop etc. instead of /Users/Username/
Desktop ... etc. Again, only in some situation not in all. (I believe
mostly on Leopard, but I'm not certain yet) This creates problems as
there is a mismatch between what the program thinks is the path to the
symbolic link and what it is referred to elsewhere.

The plot thickens as in some cases the program sees the path as /
Volumes/Macintosh HD/Volumes/Macintosh HD/Users/Username/Desktop..

Can't figure it out and looking to gain a deeper understanding of how
symbolic links are processed by the system. Thanks in advance for any
insights.

IBloom

ibloom <ianmbloom@gmail.com> writes:
> I'm working on an application that bridges together several
> applications involved in creating a video workflow for editing with
> digital cinema cameras. The main platform is MacOSX.
>
> Because of the nature of some of the utilities for working with this
> video footage I must spoof filenames by using symbolic links to
> essentially rename files. This hack works great most of the time, but
> on some systems (possibly Leopard systems) it runs into problems.

[...]

> looking to gain a deeper understanding of how symbolic links are
> processed by the system.

This is really simple: A 'symlink' is a (small) 'special file' which
contains a path name. When some path which resolves to this file is
used as an argument of a system call which does not specifically
implement some 'symlink functionality' (eg lstat), the name stored in
the symlink file will be substituted for the original path name and
the path-to-file resolution process starts over with the new name
(until it finally reaches a real file or some implementation defined
'maximum symlink nesting level' has been reached).

Rainer Weikusat wrote:
> ibloom <ianmbloom@gmail.com> writes: 
>
> [...]
> 
>
> This is really simple: A 'symlink' is a (small) 'special file' which
> contains a path name. When some path which resolves to this file is
> used as an argument of a system call which does not specifically
> implement some 'symlink functionality' (eg lstat), the name stored in
> the symlink file will be substituted for the original path name and
> the path-to-file resolution process starts over with the new name
> (until it finally reaches a real file or some implementation defined
> 'maximum symlink nesting level' has been reached).

... and this substitution process is invisible to the caller of
whatever function (like open(), stat(), or whatever) tried to
use the pathname.

However, sometimes it can become visible later on, because it
may change some state that is indirectly visible.  For example, if
you do chdir() to set the current working directory, and if that
causes you to follow symlinks, then when you read back the current
working directory, you may see the side effects.  (This is why
well-behaved software rarely reads the current working directory.)

- Logan

On Mar 25, 12:03=A0am, Logan Shaw <lshaw-use...@austin.rr.com> wrote:
> Rainer Weikusat wrote: 
> 
> 
> 
> 
>
> ... and this substitution process is invisible to the caller of
> whatever function (like open(), stat(), or whatever) tried to
> use the pathname.
>
> However, sometimes it can become visible later on, because it
> may change some state that is indirectly visible. =A0For example, if
> you do chdir() to set the current working directory, and if that
> causes you to follow symlinks, then when you read back the current
> working directory, you may see the side effects. =A0(This is why
> well-behaved software rarely reads the current working directory.)
>
> =A0 =A0- Logan

In this situation, all of the symlinks I am generating are one step,
symlink->datafile. The parent directory of the symlink is just a
normal directory.
So I should be more specific. The program is saying that the path to
the "symlink" starts in /Volumes rather than /Users

So it's reading:

/Users/Desktop/MyFolder/mysymlink --> /Volumes/AnotherVolume/
AnotherFolder/mydatafile

as

/Volumes/Macintosh HD/Users/Desktop/MyFolder/mysymlink --> /Volumes/
AnotherVolume/AnotherFolder/mydatafile

or

/Volumes/Macintosh HD/Volumes/Macintosh HD/Users/Desktop/MyFolder/
mysymlink --> /Volumes/AnotherVolume/AnotherFolder/mydatafile


It follows the link just fine and the files load in fine. But when it
tries to load an XML construct that refers to the loaded file paths
there is a mismatch. So this is what I can't understand...

IBloom

In article
<7a6cc5bd-cdfb-4650-8e7c-1e759208c76a@b64g2000hsa.googlegroups.com>,
ibloom <ianmbloom@gmail.com> wrote:

> So it's reading:
>
> /Users/Desktop/MyFolder/mysymlink --> /Volumes/AnotherVolume/
> AnotherFolder/mydatafile
>
> as
>
> /Volumes/Macintosh HD/Users/Desktop/MyFolder/mysymlink --> /Volumes/
> AnotherVolume/AnotherFolder/mydatafile
>
> or
>
> /Volumes/Macintosh HD/Volumes/Macintosh HD/Users/Desktop/MyFolder/
> mysymlink --> /Volumes/AnotherVolume/AnotherFolder/mydatafile
>
>
> It follows the link just fine and the files load in fine. But when it
> tries to load an XML construct that refers to the loaded file paths
> there is a mismatch. So this is what I can't understand...

On OS X, /Volumes is where the system automatically mounts disks.  The
boot volume is mounted as /, but /Volumes/<disk name> is a symlink to /:

imac:barmar $ cd /Volumes
imac:Volumes $ ls -ld 'Macintosh HD'
lrwxr-xr-x  1 root  admin  1 Mar 20 05:55 Macintosh HD -> /

If you use the pwd command to get your current directory, it makes use
of the $PWD environment variable, which the shell uses to keep track of
the pathname you used to get where you are, including symlinks.  So if
you do:

cd /Volumes/Macintosh\ HD/Users

then pwd will display this path, but if you do:

cd /Users

then pwd will show this shorter path.  You can use the -P option to pwd
to show the true absolute path rather than the logical path used to cd.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***

On Mar 25, 12:55 am, ibloom <ianmbl...@gmail.com> wrote:
> On Mar 25, 12:03 am, Logan Shaw <lshaw-use...@austin.rr.com> wrote:
>
>
> 
> 
> 
> 
> 
> 
> 
> 
>
> In this situation, all of the symlinks I am generating are one step,
> symlink->datafile. The parent directory of the symlink is just a
> normal directory.
> So I should be more specific. The program is saying that the path to
> the "symlink" starts in /Volumes rather than /Users
>
> So it's reading:
>
> /Users/Desktop/MyFolder/mysymlink --> /Volumes/AnotherVolume/
> AnotherFolder/mydatafile
>
> as
>
> /Volumes/Macintosh HD/Users/Desktop/MyFolder/mysymlink --> /Volumes/
> AnotherVolume/AnotherFolder/mydatafile
>
> or
>
> /Volumes/Macintosh HD/Volumes/Macintosh HD/Users/Desktop/MyFolder/
> mysymlink --> /Volumes/AnotherVolume/AnotherFolder/mydatafile
>
> It follows the link just fine and the files load in fine. But when it
> tries to load an XML construct that refers to the loaded file paths
> there is a mismatch. So this is what I can't understand...

What if, when comparing symlink paths, you work around this by doing
something like:

1) First strip the filename off of the path (this is the symlink
itself), leaving you with something like "/Volumes/Macintosh HD/
Volumes/Macintosh HD/Users/Desktop/MyFolder".

2) Then, use realpath() on that directory name. This will resolve
symlinks to their actual paths. Do all path comparisons based off of
this value instead (and also compare the symlink filenames themselves,
of course, since you did strip them from the path in step 1).

The reason for #1 is because realpath() resolves symlinks, so if you
did it on the symlink itself you'd end up with whatever file it points
to, which I don't think is what you want.

http://developer.apple.com/document....3
.html

Not sure if that helps, I don't know much about OSX.

Jason



>
> IBloom