in reply to Re^2: cleaning up absolute path without resolving symlinks
in thread cleaning up absolute path without resolving symlinks

I'm not seeing where the symlinks fit in. Mounting separate volumes should be transparent to file system users like your application, shouldn't they? i.e. if you mount /serve/files/b from a remote disk, shouldn't it still just look like /serve/files/b, no symlink involved? Or are you implying a symlink somewhere else?
  • Comment on Re^3: cleaning up absolute path without resolving symlinks

Replies are listed 'Best First'.
Re^4: cleaning up absolute path without resolving symlinks
by leocharre (Priest) on Mar 06, 2007 at 21:30 UTC

    Here's how it fits in.

    On your shell.. Imagine you are user 'bubba'..

    mkdir /home/bubba/served
    mkdir /etc/a
    touch /etc/a/filehere
    ln -s /etc/a /home/bubba/served/a
    

    Now for perl..

    #!/usr/bin/perl -w use Cwd; use strict; for (qw( /home/bubba/served /home/bubba/served/a /home/bubba/served/a/filehere )){ printf "$_ = %s\n",Cwd::abs_path($_); }

    You get

    bubba#mescaline# perl script.pl
    /home/bubba/served = /home/bubba/served
    /home/bubba/served/a = /etc/a
    /home/bubba/served/a/filehere = /etc/a/filehere
    

    I don't know if people using this in the future will be mounting directly to /home/bubba/served , in fact, I'm pretty sure they will not. Things will be mounted somewhere and likely symlinked to /home/bubba/served. ( I believe hard links don't work accross filesystems.. haha).

    What the program needs to verify is that whatever the file is, it is 'within' the hierarchy of /home/bubba/served. This is why resolving symlinks won't cut it.