MKXORG=yes on Linux: nbmtree: existing entry for `libXaw.so', type `link' does not match type `file'

[Hubert Feyrer-4]

I'm cross-building -current with MKXORG=yes on Linux, and see the error
below. It seems the METALOG indeed has 'file' where it should have 'link'
- has anyone encountered this before? I don't seem to get this on
NetBSD...


  - Hubert

...
checkflist ===> distrib/sets
--- check_DESTDIR ---
--- /data/feyrer/nbcvs/src-current/obj.i386/destdir/METALOG.sanitised ---
( cat /data/feyrer/nbcvs/src-current/etc/mtree/NetBSD.dist ;  echo '/unset
all' ;  cat /data/feyrer/nbcvs/src-current/obj.i386/destdir/METALOG )  |
/data/feyrer/nbcvs/src-current/obj.i386/tooldir/bin/nbmtree -C -k all -N
/data/feyrer/nbcvs/src-current/etc >
/data/feyrer/nbcvs/src-current/obj.i386/destdir/METALOG.new &&  ( rm -f
/data/feyrer/nbcvs/src-current/obj.i386/destdir/METALOG ;  mv
/data/feyrer/nbcvs/src-current/obj.i386/destdir/METALOG.new
/data/feyrer/nbcvs/src-current/obj.i386/destdir/METALOG )
nbmtree: existing entry for `libXaw.so', type `link' does not match type
`file'
nbmtree: failed at line 33721 of the specification
*** [/data/feyrer/nbcvs/src-current/obj.i386/destdir/METALOG.sanitised]
Error code 1

[Hubert Feyrer-4]

On Tue, 30 Sep 2008, Hubert Feyrer wrote:
> nbmtree: existing entry for `libXaw.so', type `link' does not match type
> `file'

Digging a bit more into this, it's related to the difference in handling
hardlink to symlinks. On NetBSD, it seems that you get a link to the
target file these days[1], while on Linux you get a link to the
symlink[2]. ISTR that NetBSD used to behave like Linux there - is this
really intended?

FWIW, Solaris behaves the same way as Linux does.


  - Hubert


[1] % set files="/tmp/f /tmp/lf /tmp/hlf" ; rm $files ; touch /tmp/f ; ln -s /tmp/f /tmp/lf ; ln /tmp/lf /tmp/hlf ; perl -e 'foreach $f (@ARGV) { @x=stat($f);printf "mode=%o for $f\n", $x[2]; }' $files ; ls -lad $files
  mode=100664 for /tmp/f
  mode=100664 for /tmp/lf
  mode=100664 for /tmp/hlf
  -rw-rw-r--  2 feyrer  wheel  0 Sep 30 13:59 /tmp/f
    ===> -rw-rw-r--  2 feyrer  wheel  0 Sep 30 13:59 /tmp/hlf
  lrwxrwxr-x  1 feyrer  wheel  6 Sep 30 13:59 /tmp/lf -> /tmp/f


[2] % set files="/tmp/f /tmp/lf /tmp/hlf" ; rm $files ; touch /tmp/f ; ln -s /tmp/f /tmp/lf ; ln /tmp/lf /tmp/hlf ; perl -e 'foreach $f (@ARGV) { @x=stat($f);printf "mode=%o for $f\n", $x[2]; }' $files ; ls -lad $files
  mode=100664 for /tmp/f
  mode=100664 for /tmp/lf
  mode=100664 for /tmp/hlf
  -rw-rw-r-- 1 feyrer bedienst 0 Sep 30 13:59 /tmp/f
    ===> lrwxrwxrwx 2 feyrer bedienst 6 Sep 30 13:59 /tmp/hlf -> /tmp/f
  lrwxrwxrwx 2 feyrer bedienst 6 Sep 30 13:59 /tmp/lf -> /tmp/f

[Joerg Sonnenberger]

On Tue, Sep 30, 2008 at 01:59:15PM +0200, Hubert Feyrer wrote:
> Digging a bit more into this, it's related to the difference in handling  
> hardlink to symlinks. On NetBSD, it seems that you get a link to the  
> target file these days[1], while on Linux you get a link to the  
> symlink[2]. ISTR that NetBSD used to behave like Linux there - is this  
> really intended?

NetBSD behaves like POSIX and always has.

Joerg

[Thor Lancelot Simon]

On Tue, Sep 30, 2008 at 02:59:32PM +0200, Joerg Sonnenberger wrote:
> On Tue, Sep 30, 2008 at 01:59:15PM +0200, Hubert Feyrer wrote:
> > Digging a bit more into this, it's related to the difference in handling  
> > hardlink to symlinks. On NetBSD, it seems that you get a link to the  
> > target file these days[1], while on Linux you get a link to the  
> > symlink[2]. ISTR that NetBSD used to behave like Linux there - is this  
> > really intended?
>
> NetBSD behaves like POSIX and always has.

Does POSIX actually specify this?  The difference probably stems from
whether or not the symlink consumes an inode: on 4.3BSD and prior, it
always did, and on 4.4 and NetBSD it does not (or is arranged to look
as if it does not, in a few uncommon cases, IIRC).

--
Thor Lancelot Simon                                   tls@...
    "Even experienced UNIX users occasionally enter rm *.* at the UNIX
     prompt only to realize too late that they have removed the wrong
     segment of the directory structure." - Microsoft WSS whitepaper

[Joerg Sonnenberger]

On Tue, Sep 30, 2008 at 07:20:56PM -0400, Thor Lancelot Simon wrote:

> On Tue, Sep 30, 2008 at 02:59:32PM +0200, Joerg Sonnenberger wrote:
> > On Tue, Sep 30, 2008 at 01:59:15PM +0200, Hubert Feyrer wrote:
> > > Digging a bit more into this, it's related to the difference in handling  
> > > hardlink to symlinks. On NetBSD, it seems that you get a link to the  
> > > target file these days[1], while on Linux you get a link to the  
> > > symlink[2]. ISTR that NetBSD used to behave like Linux there - is this  
> > > really intended?
> >
> > NetBSD behaves like POSIX and always has.
>
> Does POSIX actually specify this?  The difference probably stems from
> whether or not the symlink consumes an inode: on 4.3BSD and prior, it
> always did, and on 4.4 and NetBSD it does not (or is arranged to look
> as if it does not, in a few uncommon cases, IIRC).

POSIX allows in some places this behavior. But the general rules for
system calls apply to symlink(2) as well, so POSIX doesn't really specify a
mechanism to create. The POSIX rules are intended as you said for
implementing symlinks without separate inodes.

Joerg

[Adam Hoka]

Hubert Feyrer wrote:

>
> On Tue, 30 Sep 2008, Hubert Feyrer wrote:
>> nbmtree: existing entry for `libXaw.so', type `link' does not match
>> type `file'
>
> Digging a bit more into this, it's related to the difference in handling
> hardlink to symlinks. On NetBSD, it seems that you get a link to the
> target file these days[1], while on Linux you get a link to the
> symlink[2]. ISTR that NetBSD used to behave like Linux there - is this
> really intended?
>
> FWIW, Solaris behaves the same way as Linux does.
>

Yes, both of them are "incorrect" (if you can use this term for not
following all other unix systems). :)

See this for a vulnerability because of this misbehavior:
http://securitytracker.com/alerts/2008/Aug/1020700.html

>
>  - Hubert
>
>
> [1]    % set files="/tmp/f /tmp/lf /tmp/hlf" ; rm $files ; touch /tmp/f
> ; ln -s /tmp/f /tmp/lf ; ln /tmp/lf /tmp/hlf ; perl -e 'foreach $f
> (@ARGV) { @x=stat($f);printf "mode=%o for $f\n", $x[2]; }' $files ; ls
> -lad $files
>     mode=100664 for /tmp/f
>     mode=100664 for /tmp/lf
>     mode=100664 for /tmp/hlf
>     -rw-rw-r--  2 feyrer  wheel  0 Sep 30 13:59 /tmp/f
>    ===>    -rw-rw-r--  2 feyrer  wheel  0 Sep 30 13:59 /tmp/hlf
>     lrwxrwxr-x  1 feyrer  wheel  6 Sep 30 13:59 /tmp/lf -> /tmp/f
>
>
> [2]    % set files="/tmp/f /tmp/lf /tmp/hlf" ; rm $files ; touch /tmp/f
> ; ln -s /tmp/f /tmp/lf ; ln /tmp/lf /tmp/hlf ; perl -e 'foreach $f
> (@ARGV) { @x=stat($f);printf "mode=%o for $f\n", $x[2]; }' $files ; ls
> -lad $files
>     mode=100664 for /tmp/f
>     mode=100664 for /tmp/lf
>     mode=100664 for /tmp/hlf
>     -rw-rw-r-- 1 feyrer bedienst 0 Sep 30 13:59 /tmp/f
>    ===>    lrwxrwxrwx 2 feyrer bedienst 6 Sep 30 13:59 /tmp/hlf -> /tmp/f
>     lrwxrwxrwx 2 feyrer bedienst 6 Sep 30 13:59 /tmp/lf -> /tmp/f
>

[Adam Hoka]

>> Digging a bit more into this, it's related to the difference in
>> handling hardlink to symlinks. On NetBSD, it seems that you get a link
>> to the target file these days[1], while on Linux you get a link to the
>> symlink[2]. ISTR that NetBSD used to behave like Linux there - is this
>> really intended?
>>
>> FWIW, Solaris behaves the same way as Linux does.
>>
>
> Yes, both of them are "incorrect" (if you can use this term for not
> following all other unix systems). :)
>
> See this for a vulnerability because of this misbehavior:
> http://securitytracker.com/alerts/2008/Aug/1020700.html

A nicer explanation of the problem:
http://archives.neohapsis.com/archives/postfix/2008-08/0391.html

[Hubert Feyrer-4]

Hi,

the fix below replaces "hardlink to symlink" by "symlink to symlink" and
thus makes building on both NetBSD and Linux work again, see my postings
to current-users@ on the problem[1][2].

Can I commit the patch below?


  - Hubert

[1] http://mail-index.netbsd.org/current-users/2008/09/30/msg004940.html
[2] http://mail-index.netbsd.org/current-users/2008/09/30/msg004941.html



Index: external/mit/xorg/lib/libXaw/Makefile
===================================================================
RCS file: /cvsroot/src/external/mit/xorg/lib/libXaw/Makefile,v
retrieving revision 1.2
diff -u -r1.2 Makefile
--- external/mit/xorg/lib/libXaw/Makefile 13 Sep 2008 04:32:30 -0000 1.2
+++ external/mit/xorg/lib/libXaw/Makefile 30 Sep 2008 21:13:09 -0000
@@ -6,16 +6,16 @@
  LIBOLD= Xaw

  .if ${MKSTATICLIB} != "no"
-LINKS=          ${X11USRLIBDIR}/lib${LIB}.a ${X11USRLIBDIR}/lib${LIBOLD}.a
+SYMLINKS=          lib${LIB}.a ${X11USRLIBDIR}/lib${LIBOLD}.a
  .endif

  .if ${MKPROFILE} != "no"
-LINKS+=         ${X11USRLIBDIR}/lib${LIB}_p.a ${X11USRLIBDIR}/lib${LIBOLD}_p.a
+SYMLINKS+=         lib${LIB}_p.a ${X11USRLIBDIR}/lib${LIBOLD}_p.a
  .endif

  .if ${MKPIC} != "no"
-LINKS+=         ${X11USRLIBDIR}/lib${LIB}.so ${X11USRLIBDIR}/lib${LIBOLD}.so
-LINKS+=         ${X11USRLIBDIR}/lib${LIB}.so.8 ${X11USRLIBDIR}/lib${LIBOLD}.so.8
+SYMLINKS+=         lib${LIB}.so ${X11USRLIBDIR}/lib${LIBOLD}.so
+SYMLINKS+=         lib${LIB}.so.8 ${X11USRLIBDIR}/lib${LIBOLD}.so.8
  .endif

  .PATH: ${X11SRCDIR.Xaw}/src
Index: external/mit/xorg/lib/libXaw6/Makefile
===================================================================
RCS file: /cvsroot/src/external/mit/xorg/lib/libXaw6/Makefile,v
retrieving revision 1.2
diff -u -r1.2 Makefile
--- external/mit/xorg/lib/libXaw6/Makefile 13 Sep 2008 04:32:30 -0000 1.2
+++ external/mit/xorg/lib/libXaw6/Makefile 30 Sep 2008 21:13:09 -0000
@@ -9,7 +9,7 @@
  LIBOLD= Xaw

  .if ${MKPIC} != "no"
-LINKS+=         ${X11USRLIBDIR}/lib${LIB}.so.6 ${X11USRLIBDIR}/lib${LIBOLD}.so.6
+SYMLINKS+=         lib${LIB}.so.6 ${X11USRLIBDIR}/lib${LIBOLD}.so.6
  .endif

  .PATH: ${X11SRCDIR.Xaw}/src
Index: external/mit/xorg/lib/libXaw7/Makefile
===================================================================
RCS file: /cvsroot/src/external/mit/xorg/lib/libXaw7/Makefile,v
retrieving revision 1.2
diff -u -r1.2 Makefile
--- external/mit/xorg/lib/libXaw7/Makefile 13 Sep 2008 04:32:30 -0000 1.2
+++ external/mit/xorg/lib/libXaw7/Makefile 30 Sep 2008 21:13:09 -0000
@@ -6,7 +6,7 @@
  LIBOLD= Xaw

  .if ${MKPIC} != "no"
-LINKS+=         ${X11USRLIBDIR}/lib${LIB}.so.7 ${X11USRLIBDIR}/lib${LIBOLD}.so.7
+SYMLINKS+=         lib${LIB}.so.7 ${X11USRLIBDIR}/lib${LIBOLD}.so.7
  .endif

  .PATH: ${X11SRCDIR.Xaw}/src

[Alan Barrett]

On Wed, 01 Oct 2008, Hubert Feyrer wrote:
> the fix below replaces "hardlink to symlink" by "symlink to symlink" and  
> thus makes building on both NetBSD and Linux work again, see my postings  
> to current-users@ on the problem[1][2].

I don't understand why you want multiple levels of symlinks (e.g. a->b
and b->f, where a and b are symlinks and f is a file) instead of a
single level of symlinks (e.g. a->f and b->f, where a and b are symlinks
and f is a file), or even a single level of hard links (e.g. a = b = f
where all three are hard links to the same file).

--apb (Alan Barrett)

[Rhialto]

On Wed 01 Oct 2008 at 08:50:02 +0200, Joerg Sonnenberger wrote:
> POSIX allows in some places this behavior. But the general rules for
> system calls apply to symlink(2) as well, so POSIX doesn't really specify a
> mechanism to create. The POSIX rules are intended as you said for
> implementing symlinks without separate inodes.

It sounds useful to me to be able to make hard links to symlinks.
That way, you can truely make a "copy" of a directory hierarchy by
making a whole bunch of hard links to all files/devices/symlinks (but
you'll still have to duplicate directories of course). Rather like
lndir(1)/linkfarm(1), but with hard links.

Apparently the NetBSD implementation makes this impossible.

> Joerg
-Olaf.
--
___ Olaf 'Rhialto' Seibert    -- You author it, and I'll reader it.
\X/ rhialto/at/xs4all.nl      -- Cetero censeo "authored" delendum esse.