Here's the output: [...] PASS: trailing-slash PASS: deref PASS: two-args df: no file systems processed FAIL: slink ====================================== 1 of 19 tests failed (1 tests were not run) Please report to bug-coreutils@gnu.org ====================================== [...] When running the coreutils-6.6/tests/slink test manually on the /var/tmp filesystem, I get the same result: ./slink; echo $? df: no file systems processed 1 And in /tmp (which is a tmpfs filesystem): df: no file systems processed 0 Ditto /root, which is reiserfs. Note that the "df: no file systems processed" output is irrelevant, as it merely triggers when one doesn't have any xfs filesystems. Back to reiser4, the test fails at the last check, which is: grep '^[1-9]' out > /dev/null || fail=1 the 'out' temporary file contains: 0 1 0 15 0 16 0 31 0 32 0 59 0 60 0 63 0 64 0 127 0 128 0 255 0 256 0 511 0 512 0 1024 Which is produced by the previous line in the test script: du -a $symlinks > out || fail=1 All the symlink nodes indeed appear to occupy 0 blocks according to du. Even when creating a link to a 3072-byte filename, du reports 0 blocks. However, 'du -b' on any of the files appear to work as expected, counting as many bytes as the link's length. For the record, here's the stat output for this file: File: `3072' -> `yyyyyyyyyyyyyyyyyyyyyyyy...' Size: 3072 Blocks: 0 IO Block: 65536 symbolic link Device: fe04h/65028d Inode: 1757976 Links: 1 Access: (0777/lrwxrwxrwx) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2006-12-01 21:25:06.219126555 +0200 Modify: 2006-12-01 21:25:06.219126555 +0200 Change: 2006-12-01 21:25:06.220126350 +0200 I don't think reiser4 can be considered broken for reporting 0-block file size for every symbolic link, and neither would I consider du broken for repeating something the filesystem layer tells it. So I would guess that the test is flawed, as it assumes that the filesystem will report at least 1 block for the maximum supported symbolic link length, while the filesystem limit might be even less than 1024. Anyway, appendix follows, emerge --info: Portage 2.1.1-r2 (default-linux/amd64/2006.1, gcc-4.1.1, glibc-2.5-r0, 2.6.18-mm3-non14 x86_64) ================================================================= System uname: 2.6.18-mm3-non14 x86_64 AMD Athlon(tm) 64 Processor 3000+ Gentoo Base System version 1.12.6 Last Sync: Fri, 01 Dec 2006 17:50:01 +0000 app-admin/eselect-compiler: [Not Present] dev-java/java-config: 1.3.7, 2.0.30 dev-lang/python: 2.4.4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: 0.4.2-r1 sys-apps/sandbox: 1.2.18.1 sys-devel/autoconf: 2.13, 2.61 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.17 sys-devel/gcc-config: 1.3.14 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r1 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-fstack-protector -pipe -O2 -march=athlon64 -mtune=athlon64 -fomit-frame-pointer" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/init.d /etc/java-config/vms/ /etc/revdep-rebuild /etc/terminfo /usr/share/X11" CXXFLAGS="-fstack-protector -pipe -O2 -march=athlon64 -mtune=athlon64 -fomit-frame-pointer" DISTDIR="/usr/distfiles" FEATURES="autoconfig distlocks metadata-transfer parallel-fetch sandbox sfperms strict test userfetch userpriv usersandbox" GENTOO_MIRRORS="ftp://ftp.ipv6.linux.ee/pub/gentoo/distfiles/ http://ftp.linux.ee/pub/gentoo/distfiles/" LANG="en_US" LC_ALL="en_US.UTF-8" LINGUAS="en en_US en_GB et" MAKEOPTS="-j1" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage/musicbrainz-overlay /usr/local/portage /usr/portage/local/layman/xgl-coffee" SYNC="rsync://rsync1.fi.gentoo.org/gentoo-portage" USE="amd64 X a52 aac aalib adns alsa ao asf berkdb bitmap-fonts browserplugin bzip2 cairo cap caps cddb cli cracklib crypt cscope curl dbus dga dlloader dri dvd elibc_glibc exif fastcgi fbcon ffmpeg firefox flac gd gdbm gimp glitz glut gmp gnome gphoto2 gpm gtk hal iconv idn imagemagick input_devices_joystick input_devices_keyboard input_devices_mouse ipv6 isdnlog jbig joystick jpeg jpeg2k kernel_linux lcms libcaca libg++ linguas_en linguas_en_GB linguas_en_US linguas_et logrotate lzo mad matroska mikmod mmap mng motif mozilla moznoirc mozsvg mp3 mpeg mplayer musepack musicbrainz ncurses nptl nptlonly nsplugin ntfs offensive ogg oggvorbis openal opengl opensc pam pcre pcsc-lite perl png postgres ppds pppd python qt3 qt4 quotas randr readline reflection reiser4 reiserfs rtc samba sdl session smartcard speex spl sqlite ssl startup-notification svg theora tiff truetype truetype-fonts type1-fonts udev unicode userland_GNU v4l v4l2 video_cards_fglrx video_cards_none video_cards_r200 video_cards_radeon video_cards_vesa vim-syntax vorbis wxwindows xgetdefault xine xml xml2 xorg xv xvid xvmc zlib" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS
We don't support ricer4 filesystem...
It's a bug in coreutils to rely on such silly assumptions, not a bug in reiser4.
The test script already treats the XFS filesystem differently, by skipping it. I guess a similar section could be added for reiser4: df --type=xfs . | tail -n +2 > tmp if test -s tmp; then # At least on Irix-6.5.19, when using an xfs file system, # each created symlink (name lengths up to 255) would have a size of `0'. echo "$0: skipping this test, since \`.' is on an XFS file system" 1>&2 (exit 77); exit 77 fi
*** This bug has been marked as a duplicate of 75934 *** *** This bug has been marked as a duplicate of 75934 ***
