Re: installworld failure due to cross-device links
On 01/02/13 13:26, Nathan Whitehorn wrote: Thanks for the patch! I've committed it (slightly modified) as r244958. I haven't taken any action on the chgrp/chown issue, though. Similarly, 'make distribution' fails when /root is a separate filesystem: cd /usr/src/etc/root; install -o root -g wheel -m 644 dot.profile /tmproot/root/.profile; rm -f /tmproot/.profile; ln /tmproot/root/.profile /tmproot/.profile ln: /tmproot/.profile: Cross-device link *** [distribution] Error code 1 Is there any real advantage of hard links over symlinks nowadays? -- Sorry for the following... The information contained in this message is confidential and intended for the addressee only. If you have received this message in error, or there are any problems with its content, please contact the sender. iCritical is a trading name of Critical Software Ltd. Registered in England: 04909220. Registered Office: IC2, Keele Science Park, Keele, Staffordshire, ST5 5NH. This message has been scanned for security threats by iCritical. www.icritical.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: installworld failure due to cross-device links
On Fri, Jan 11, 2013 at 6:18 AM, Matt Burke mattbli...@icritical.com wrote: On 01/02/13 13:26, Nathan Whitehorn wrote: Thanks for the patch! I've committed it (slightly modified) as r244958. I haven't taken any action on the chgrp/chown issue, though. Similarly, 'make distribution' fails when /root is a separate filesystem: cd /usr/src/etc/root; install -o root -g wheel -m 644 dot.profile /tmproot/root/.profile; rm -f /tmproot/.profile; ln /tmproot/root/.profile /tmproot/.profile ln: /tmproot/.profile: Cross-device link *** [distribution] Error code 1 Is there any real advantage of hard links over symlinks nowadays? Yes. In fact, hard links are essential for some purposes. Key advantage of hard links is that you can create and use them as long as needed and then just delete them. Any remaining hard links are unaffected. When the last hard link is deleted, so is the file. Symlinks, on the other hand are simply pointer to a real file and if the file is deleted, the symlink remains, but is broken. Of course, symlinks can cross file systems when hard links can't. Both are likely to remain useful and neither is appropriate for all applications. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: installworld failure due to cross-device links
Am 02.01.2013 14:26, schrieb Nathan Whitehorn: On 01/02/13 07:04, Stefan Esser wrote: I'd be interested in the general policy on LINKS vs. SYMLINKS between directories that might end up on different file systems. There seems to be an assumption that system directories in /usr (e.g. /usr/bin, /usr/sbin, /usr/libexec) are on the same file system, but I do not think that this assumption is documented. I'm using a ZFS only installation of -CURRENT and have separate file systems for several of the directories in / and /usr, that usually share a file system (e.g. /bin, /sbin, but also /usr/bin/, /usr/sbin and /usr/libexec are independent file systems). An older case is the link from /usr/bin/chgrp to /usr/sbin/chown (see usr.sbin/chown/Makefile), which is easily fixed by using a SMYLINK instead of a LINK. And now there is usr.sbin/bsdinstall/partedit/Makefile, which as of r244859 creates a link from /usr/libexec/bsdinstall to /usr/sbin/sade. This breaks with /usr/bin and /usr/sbin on different file systems, while it should not according to the commit message: Thanks for the patch! I've committed it (slightly modified) as r244958. I haven't taken any action on the chgrp/chown issue, though. Thanks for the fix. Seems I had a wrong idea of the semantics of the (SYM)LINKS macro, as I had assumed that the build target would be linked to the list of names (instead of pairs of source/dest). I did not expect you to do anything with chown/chgrp, but I still think there should be a policy on whether hard links may be used to connect files in different directories (which might be in different file systems). Regards, STefan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
installworld failure due to cross-device links
I'd be interested in the general policy on LINKS vs. SYMLINKS
between directories that might end up on different file systems.
There seems to be an assumption that system directories in /usr
(e.g. /usr/bin, /usr/sbin, /usr/libexec) are on the same file
system, but I do not think that this assumption is documented.
I'm using a ZFS only installation of -CURRENT and have separate file
systems for several of the directories in / and /usr, that usually
share a file system (e.g. /bin, /sbin, but also /usr/bin/, /usr/sbin
and /usr/libexec are independent file systems).
An older case is the link from /usr/bin/chgrp to /usr/sbin/chown
(see usr.sbin/chown/Makefile), which is easily fixed by using a
SMYLINK instead of a LINK.
And now there is usr.sbin/bsdinstall/partedit/Makefile, which as of
r244859 creates a link from /usr/libexec/bsdinstall to /usr/sbin/sade.
This breaks with /usr/bin and /usr/sbin on different file systems,
while it should not according to the commit message:
--
r244859 | nwhitehorn | 2012-12-30 15:35:00 +0100 (Sun, 30 Dec 2012) | 7
lines
Replace sade the extracted piece of sysinstall with sade the extracted
piece of bsdinstall (although this time with a symlink instead of
duplicated source code).
Discussed on: freebsd-geom
MFC after: 3 months
--
The SYMLINK mentioned in the commit message is a LINK to a different
directory, which might be on a different file system, actually.
This should be fixed by the attached patch, to remove the implied
assumption and to make the Makefile match the commit message.
Regards, STefan
Index: Makefile
===
--- Makefile(revision 244957)
+++ Makefile(working copy)
@@ -2,7 +2,8 @@
BINDIR= /usr/libexec/bsdinstall
PROG= partedit
-LINKS= ${BINDIR}/partedit ${BINDIR}/autopart ${BINDIR}/partedit /usr/sbin/sade
+LINKS= ${BINDIR}/partedit ${BINDIR}/autopart ${BINDIR}/partedit
+SYMLINKS= /usr/sbin/sade
LDADD= -lgeom -lncursesw -lutil -ldialog -lm
PARTEDIT_ARCH= ${MACHINE}
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: installworld failure due to cross-device links
On 01/02/13 07:04, Stefan Esser wrote: I'd be interested in the general policy on LINKS vs. SYMLINKS between directories that might end up on different file systems. There seems to be an assumption that system directories in /usr (e.g. /usr/bin, /usr/sbin, /usr/libexec) are on the same file system, but I do not think that this assumption is documented. I'm using a ZFS only installation of -CURRENT and have separate file systems for several of the directories in / and /usr, that usually share a file system (e.g. /bin, /sbin, but also /usr/bin/, /usr/sbin and /usr/libexec are independent file systems). An older case is the link from /usr/bin/chgrp to /usr/sbin/chown (see usr.sbin/chown/Makefile), which is easily fixed by using a SMYLINK instead of a LINK. And now there is usr.sbin/bsdinstall/partedit/Makefile, which as of r244859 creates a link from /usr/libexec/bsdinstall to /usr/sbin/sade. This breaks with /usr/bin and /usr/sbin on different file systems, while it should not according to the commit message: Thanks for the patch! I've committed it (slightly modified) as r244958. I haven't taken any action on the chgrp/chown issue, though. -Nathan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
