Re: [Bug-xorriso] resolving symlinks

[Justin Cormack]

On 4 August 2017 at 19:55, Thomas Schmitt <address@hidden> wrote:
> 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.

Ah, ooops, I missed that this script had -f in, yes removing that is
what I want in this case, thanks.

Justin

> ---------------------------------------------------------------------
>
> 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
>