Re: [Bug-xorriso] resolving symlinks

[Thomas Schmitt]

Hi,

Justin Cormack wrote:
> xorriso : FAILURE : Cannot obtain link target of :
> '/tmp/efi/containers/services/nginx/lower/var/log/nginx/error.log' :
> No such file or directory
> xorriso : NOTE : Problem occurred with intermediate path :
> '/proc/self/fd/pipe:[600539]'

After some pondering i can now reproduce this by help of "echo |":

  echo | \
  xorriso -as mkisofs -o /dev/null -R -f /proc/self/fd

The problem happens only if link following is enabled by option -f.
If you want to record the symbolic link target path rather than
the link target's content, then option -f is inappropriate.
Consider whether you are better off without it.

---------------------------------------------------------------------

These "pipe:[...]" link targets seem to be known troublemakers.
On my system they do not exist as files although the fd/ files may point
to them.
Seems to be a special readlink protocol.

---------------------------------------------------------------------

If you need option -f for other links, then you are not very well
served by -as mkisofs emulation. Even if you increase the abort threshold
to severity "FATAL" before executing the problematic commands:

  echo | \
  xorriso -abort_on fatal -as mkisofs \
          -o /dev/null -R -f /proc/self/fd

this will not record the problematic file (but will yield a result with
the files which made no trouble).

---------------------------------------------------------------------

You would have to use xorriso's native command language, which is flexible
enough to disable link following before mapping the problematic files and
then to enable it again:

  echo | \
  xorriso -outdev stdio:/dev/null \
          -follow link \
          -map /directory/with/links/to/follow \
               /directory/with/resolved/links \
          -follow off \
          -map /proc/self/fd /proc/self/fd \
          -follow link \
          -map /another/directory /another/directory

Nevertheless, recording a volatile object as link target will not
make much sense either. You most probably won't find "pipe:[106019372]"
on a system which mounted the ISO.
(It's similar as backing up a UNIX domain socket file.)


Have a nice day :)

Thomas