etc-update Scanning Configuration files... find: ftsfind.c:475: consider_visiting: Assertion `state.type != 0' failed. Reproducible: Always Portage 2.1.6.4 (default/linux/x86/2008.0, gcc-4.2.4, glibc-2.9_p20081201-r1, 2.6.28-gentoo i686) ================================================================= System uname: Linux-2.6.28-gentoo-i686-Genuine_Intel-R-_CPU_T2300_@_1.66GHz-with-glibc2.0 Timestamp of tree: Sat, 03 Jan 2009 06:40:01 +0000 ccache version 2.4 [enabled] app-shells/bash: 3.2_p48 dev-java/java-config: 1.3.7, 2.1.6-r1 dev-lang/python: 2.5.2-r8 dev-python/pycrypto: 2.0.1-r6 dev-util/ccache: 2.4-r7 dev-util/cmake: 2.4.8 sys-apps/baselayout: 2.0.0 sys-apps/openrc: 0.4.1-r1 sys-apps/sandbox: 1.3.2 sys-devel/autoconf: 2.13, 2.63 sys-devel/automake: 1.4_p6, 1.5, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.2 sys-devel/binutils: 2.19 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 2.2.6a virtual/os-headers: 2.6.28-r1 ACCEPT_KEYWORDS="x86 ~x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=prescott -msse3 -pipe -fomit-frame-pointer -mno-tls-direct-seg-refs" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/boot/grub/grub.conf /boot/grub/menu.lst /etc /etc/X11/xorg.conf /etc/conf.d/* /etc/env.d/* /etc/fstab /etc/init.d/* /etc/inittab /etc/make.conf /etc/profile /etc/rc.conf /etc/wpa_supplicant/* /home/iulian/* /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/blackbox/menu /usr/share/config /var/bind" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-O2 -march=prescott -msse3 -pipe -fomit-frame-pointer -mno-tls-direct-seg-refs" DISTDIR="/var/portage/distfiles" EMERGE_DEFAULT_OPTS="--alphabetical" FEATURES="ccache distlocks fixpackages parallel-fetch prelink protect-owned sandbox sfperms strict unmerge-orphans userfetch userpriv usersandbox" GENTOO_MIRRORS="http://gentoo.supp.name/ ftp://ftp.free.fr/mirrors/ftp.gentoo.org/ ftp://gentoo.imj.fr/pub/gentoo/" LANG="en_US.UTF-8" LC_ALL="en_US.UTF-8" LDFLAGS="-Wl,--hash-style=gnu" LINGUAS="en ro" MAKEOPTS="-j3" PKGDIR="/var/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/portage/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage/local/layman/sunrise /usr/portage/local/layman/pda /usr/portage/local/layman/synce /usr/portage/local/layman/voyageur /usr/portage/local/layman/webapps-experimental /usr/portage/local/layman/gnustep /usr/portage/local/layman/kolab /usr/portage/local/layman/vmware /usr/portage/local" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="7zip X aalib acl acpi alsa apm asf bash-completion berkdb bluetooth bzip2 cli cracklib crypt cups dbus dri firefox fortran freedom gdbm gnome gpm gtk gtk2 hal howl hvm iconv irda isdnlog jpeg lm_sensors logrotate midi mmx mp3 mudflap ncurses nls nptl nptlonly ntpl opengl openmp pam pcre perl pic pmu png pppd python quicktime readline reflection samba sdl session smp spl sse sse2 ssl sysfs tcpd tiff truetype tunctl unicode usb wifi win32codecs x86 xorg xulrunner zlib" ALSA_CARDS="hda-intel" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="evdev keyboard mouse synaptics vmmouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en ro" USERLAND="GNU" VIDEO_CARDS="intel i810 i910 i915 vesa vga v4l fbdev vmware" Unset: CPPFLAGS, CTARGET, FFLAGS, INSTALL_MASK, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Which version of sys-apps/findutils is that?
Please collect some information about the filesystem and perhaps the files etc-update is targeting. You ought to be able to find the files find opens using dev-util/strace.
eix findutils [D] sys-apps/findutils Available versions: 4.2.33 4.3.13 4.4.0 (~)4.5.1 (~)4.5.2 {nls selinux static} Installed versions: 4.5.3(06:44:39 PM 01/03/2009)(nls -selinux -static) Homepage: http://www.gnu.org/software/findutils/ Description: GNU utilities for finding files
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb7f05708) = 11708 rt_sigprocmask(SIG_SETMASK, [], find: ftsfind.c:475: consider_visiting: Assertion `state.type != 0' failed. NULL, 8) = 0 rt_sigaction(SIGCHLD, {0x80783f0, [], 0}, {0x80783f0, [], 0}, 8) = 0 --- SIGCHLD (Child exited) @ 0 (0) --- waitpid(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], WNOHANG) = 11708 waitpid(-1, 0xbf8c6f38, WNOHANG) = -1 ECHILD (No child processes) sigreturn() = ? (mask now []) close(4) = 0 read(3, "", 128) = 0 close(3) = 0 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 rt_sigaction(SIGINT, {0x8078f04, [], 0}, {0x80890de, [], 0}, 8) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 rt_sigaction(SIGINT, {0x80890de, [], 0}, {0x8078f04, [], 0}, 8) = 0 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], find: ftsfind.c:475: consider_visiting: Assertion `state.type != 0' failed. read(3, find: ftsfind.c:475: consider_visiting: Assertion `state.type != 0' failed. read(3, find: ftsfind.c:475: consider_visiting: Assertion `state.type != 0' failed. read(3, find: ftsfind.c:475: consider_visiting: Assertion `state.type != 0' failed. read(3, find: ftsfind.c:475: consider_visiting: Assertion `state.type != 0' failed. read(3, find: ftsfind.c:475: consider_visiting: Assertion `state.type != 0' failed. read(3, find: ftsfind.c:475: consider_visiting: Assertion `state.type != 0' failed. read(3, find: ftsfind.c:475: consider_visiting: Assertion `state.type != 0' failed. read(3, find: ftsfind.c:475: consider_visiting: Assertion `state.type != 0' failed. read(3, find: ftsfind.c:475: consider_visiting: Assertion `state.type != 0' failed. read(3, find: ftsfind.c:475: consider_visiting: Assertion `state.type != 0' failed. read(3, find: ftsfind.c:475: consider_visiting: Assertion `state.type != 0' failed. read(3, find: ftsfind.c:475: consider_visiting: Assertion `state.type != 0' failed. read(3, find: ftsfind.c:475: consider_visiting: Assertion `state.type != 0' failed. clone(find: ftsfind.c:475: consider_visiting: Assertion `state.type != 0' failed. read(3, find: ftsfind.c:475: consider_visiting: Assertion `state.type != 0' failed. read(3, find: ftsfind.c:475: consider_visiting: Assertion `state.type != 0' failed. read(3, find: ftsfind.c:475: consider_visiting: Assertion `state.type != 0' failed. clone(find: ftsfind.c:475: consider_visiting: Assertion `state.type != 0' failed. read(3, find: ftsfind.c:475: consider_visiting: Assertion `state.type != 0' failed. read(3, find: ftsfind.c:475: consider_visiting: Assertion `state.type != 0' failed. read(3, find: ftsfind.c:475: consider_visiting: Assertion `state.type != 0' failed. read(3, find: ftsfind.c:475: consider_visiting: Assertion `state.type != 0' failed. read(3, find: ftsfind.c:475: consider_visiting: Assertion `state.type != 0' failed. read(3, find: ftsfind.c:475: consider_visiting: Assertion `state.type != 0' failed. read(3, find: ftsfind.c:475: consider_visiting: Assertion `state.type != 0' failed. read(3, find: ftsfind.c:475: consider_visiting: Assertion `state.type != 0' failed. read(3, find: ftsfind.c:475: consider_visiting: Assertion `state.type != 0' failed. read(3, find: ftsfind.c:475: consider_visiting: Assertion `state.type != 0' failed. read(3, find: ftsfind.c:475: consider_visiting: Assertion `state.type != 0' failed. read(3, find: ftsfind.c:475: consider_visiting: Assertion `state.type != 0' failed. read(3, find: ftsfind.c:475: consider_visiting: Assertion `state.type != 0' failed.
Jeroen didnt mean just a snippet. post the full log as an attachment: strace -f -s 4096 -o log find ....... does it happen regardless of how you execute `find` ? when did this start happening (what did you upgrade recently) ?
Created attachment 177934 [details] Log find
I can confirm the same bug with findutils-4.5.3. In my case it happens when there are a lot of calls like "find . -name 'job.*.local' -print0" in a spool-like directory, where at the same time new files are created or modified. The bug happens randomly in ~10% cases, and is more likely if the directory contents is changing fast. findutils-4.5.2 works perfectly OK (or any previous version). I think, 4.5.3 should be masked until this issue is further investigated. Both were compiled within the same environment.
# find / -name core /lib/modules/2.6.27.4/kernel/sound/core /lib/modules/2.6.29-rc2-git1/kernel/sound/core /lib/modules/2.6.24.7/kernel/sound/core /lib/modules/2.6.26/kernel/sound/core /lib/modules/2.6.22.19/kernel/sound/core [cut] /proc/sys/net/core find: ftsfind.c:475: consider_visiting: Assertion `state.type != 0' failed. Aborted # Have installed findutils-4.5.3. # cat /proc/filesystems nodev sysfs nodev rootfs nodev bdev nodev proc nodev binfmt_misc nodev debugfs nodev sockfs nodev usbfs nodev pipefs nodev anon_inodefs nodev tmpfs nodev inotifyfs nodev configfs nodev devpts ext3 squashfs nodev ramfs vfat msdos iso9660 nodev smbfs nodev autofs nodev fuse fuseblk nodev fusectl udf nodev mqueue # cat /proc/mounts rootfs / rootfs rw 0 0 /dev/root / ext3 rw,noatime,errors=continue,data=ordered 0 0 /none /proc proc rw 0 0 rc-svcdir /lib/rc/init.d tmpfs rw,nosuid,nodev,noexec,size=1024k,mode=755 0 0 sysfs /sys sysfs rw,nosuid,nodev,noexec 0 0 debugfs /sys/kernel/debug debugfs rw,nosuid,nodev,noexec 0 0 udev /dev tmpfs rw,nosuid,size=10240k,mode=755 0 0 devpts /dev/pts devpts rw,nosuid,noexec,gid=5,mode=620 0 0 /none /dev/shm tmpfs rw 0 0 /none /proc/bus/usb usbfs rw 0 0 binfmt_misc /proc/sys/fs/binfmt_misc binfmt_misc rw,nosuid,nodev,noexec 0 0 #
# find /proc -name core /proc/sys/net/core # find /proc -name core /proc/sys/net/core find: ftsfind.c:475: consider_visiting: Assertion `state.type != 0' failed. Aborted # find /proc -name core /proc/sys/net/core # find /proc -name core /proc/sys/net/core find: ftsfind.c:475: consider_visiting: Assertion `state.type != 0' failed. Aborted # find /proc -name core /proc/sys/net/core find: ftsfind.c:475: consider_visiting: Assertion `state.type != 0' failed. # find /proc -name core /proc/sys/net/core find: ftsfind.c:475: consider_visiting: Assertion `state.type != 0' failed. Aborted # find /proc -name core /proc/sys/net/core #
Comment on attachment 177934 [details] Log find this doesnt actually show a crash ...
probably this bug upstream: http://savannah.gnu.org/bugs/?25294
ive added a change from upstream to 4.5.3-r1 that should hopefully fix this lemme know
(In reply to comment #10) > # find /proc -name core > /proc/sys/net/core > # find /proc -name core > /proc/sys/net/core > find: ftsfind.c:475: consider_visiting: Assertion `state.type != 0' failed. > Aborted Confirming that this does not appear with sys-apps/findutils-4.5.3-r1 so far.
I'm seeing this error with sys-apps/findutils-4.5.3-r1... # find / -xdev -type f -name '*.pc' -print find: ftsfind.c:474: consider_visiting: Assertion `ent->fts_info == 11 || state.type != 0' failed. Aborted
(In reply to comment #15) > I'm seeing this error with sys-apps/findutils-4.5.3-r1... > > # find / -xdev -type f -name '*.pc' -print > find: ftsfind.c:474: consider_visiting: Assertion `ent->fts_info == 11 || > state.type != 0' failed. > Aborted > Somebody please re-open.
I just stumbled about https://forums.gentoo.org/viewtopic-p-5560313.html which is another user reporting that findutils-4.5.3-r1 doesn't fix this problem. Reopening...
Fixed with findutils-4.5.4 ..
Is this a related error / bug? # find / -xdev -print >results find: ftsfind.c:475: consider_visiting: Assertion `ent->fts_info == 11 || state.type != 0' failed. Aborted I have sys-apps/findutils-4.5.4 installed.
(In reply to comment #19) > Is this a related error / bug? > > # find / -xdev -print >results > find: ftsfind.c:475: consider_visiting: Assertion `ent->fts_info == 11 || > state.type != 0' failed. > Aborted > > I have sys-apps/findutils-4.5.4 installed. > find / -xdev -print > results This does not give any error here... findutils-4.5.4
> > I have sys-apps/findutils-4.5.4 installed. > > I have findutils-4.5.4 installed and I am getting fls@flst61nb:part1$ find ./var/log find: ftsfind.c:475: consider_visiting: Assertion `ent->fts_info == 11 || state.type != 0' failed. Aborted (core dumped) the permissions on the directories are interesting. fls@flst61nb:var$ ls -la total 420K drwxr-xr-x 3 fls fls 35 12. Okt 23:33 . drwxr-xr-x 7 fls fls 125 12. Feb 02:04 .. drw------- 2 fls fls 21 12. Okt 23:46 log so I am not allowed to cd into log: fls@flst61nb:var$ ls -l log ls: cannot access log/messages: Permission denied total 0 ?????????? ? ? ? ? ? messages whereas: root@flst61nb:var$ ls -lah log total 36M drw------- 2 fls fls 21 12. Okt 23:46 . drwxr-xr-x 3 fls fls 35 12. Okt 23:33 .. -rw------- 1 fls fls 36M 17. Mär 11:15 messages
(In reply to comment #21) one more to add. Even as root find segfaults in my user's home while gnome is running. The reasons seams to be the gnome vfs: root@flst61nb:~$ mount | grep gv gvfs-fuse-daemon on /home/fls/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=fls) as user find asserts again fls@flst61nb:~$ find .gvfs/ .gvfs/ find: ftsfind.c:475: consider_visiting: Zusicherung »ent->fts_info == 11 || state.type != 0« nicht erfüllt. Abgebrochen (Speicherabzug geschrieben) while running as root it states Permission denied: find .gvfs find: `.gvfs': Permission denied but in the strace of a find in my user's home I can see: 1979689 fcntl(4, F_GETFD) = 0 1979690 fcntl(4, F_SETFD, FD_CLOEXEC) = 0 1979691 newfstatat(5, ".gvfs", 0x1786020, AT_SYMLINK_NOFOLLOW) = -1 EACCES (Permission denied) 1979692 lstat(".gvfs", 0x7fffaeb01c30) = -1 EACCES (Permission denied) 1979693 write(2, "find: ftsfind.c:475: consider_vis"..., 99) = 99 1979694 rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0 1979695 tgkill(10371, 10371, SIGABRT) = 0 1979696 --- SIGABRT (Aborted) @ 0 (0) --- 1979697 +++ killed by SIGABRT (core dumped) +++ and what is more disturbing is the display of ls in my users home: ?????????? ? ? ? ? ? .gvfs *gnarg*
(In reply to comment #8) > I can confirm the same bug with findutils-4.5.3. In my case it happens when > there are a lot of calls like "find . -name 'job.*.local' -print0" in a > spool-like directory, where at the same time new files are created or modified. I'm seeing this in 4.5.4, thought it seems slightly different than the original reported bug. I've a set of steps one can do to repro this: cd /tmp && mkdir foo && cd foo && ln -s /dev bar strace -f -s 4096 -o log find -L . -name foo This produced the following log attachment...
Created attachment 195773 [details] strace that shows the bug in 4.5.4 Created by: cd /tmp && mkdir foo && cd foo && ln -s /dev bar strace -f -s 4096 -o findutils-4.5.4_strace.log find -L . -name foo
Well, I just found out that I don't even need to make any directories or anything... ~ $ cd /dev && find -L . -name foo find: File system loop detected; `./fd/3' is part of the same file system loop as `.'. find: ftsfind.c:475: consider_visiting: Assertion `ent->fts_info == 11 || state.type != 0' failed. Aborted /dev $ So, at this point, I guess the real question is "who cares?" It basically finds it's way into "/dev" and then becomes unhappy that file-descriptors are volatile? Is this really a bug just because it asserts, or is there something actually wrong? Should I notify upstream? (don't really want to go make a savannah account :-p )
still happens with sys-apps/findutils-4.5.4 $ ls -al drwx------ 6 user user 4096 Jul 12 2008 . drwxr-x--- 3 user user 4096 Jul 10 2008 .. -rw------- 1 user user 179 Jul 12 2008 entries -rw------- 1 user user 2 Jul 10 2008 format drw------- 2 user user 4096 Jul 10 2008 prop-base drw------- 2 user user 4096 Jul 10 2008 props drw------- 2 user user 4096 Jul 10 2008 text-base drw------- 5 user user 4096 Jul 12 2008 tmp $ ls -al tmp/ total 20 drw------- 5 user user 4096 Jul 12 2008 . drwx------ 6 user user 4096 Jul 12 2008 .. drwx------ 2 user user 4096 Jul 10 2008 prop-base drwx------ 2 user user 4096 Jul 10 2008 props drwx------ 2 user user 4096 Jul 10 2008 text-base Note: the above only works as root. User gets permission denied. $ find tmp/ tmp/ find: ftsfind.c:475: consider_visiting: Assertion `ent->fts_info == 11 || state.type != 0' failed. Aborted I think it has something to do with the wierd permission.
Created attachment 197053 [details] strace find tmp/ strace find tmp/ in the directory described above
(In reply to comment #26) > still happens with sys-apps/findutils-4.5.4 > > $ ls -al > drwx------ 6 user user 4096 Jul 12 2008 . > drwxr-x--- 3 user user 4096 Jul 10 2008 .. > -rw------- 1 user user 179 Jul 12 2008 entries > -rw------- 1 user user 2 Jul 10 2008 format > drw------- 2 user user 4096 Jul 10 2008 prop-base > drw------- 2 user user 4096 Jul 10 2008 props > drw------- 2 user user 4096 Jul 10 2008 text-base > drw------- 5 user user 4096 Jul 12 2008 tmp > > $ ls -al tmp/ > total 20 > drw------- 5 user user 4096 Jul 12 2008 . > drwx------ 6 user user 4096 Jul 12 2008 .. > drwx------ 2 user user 4096 Jul 10 2008 prop-base > drwx------ 2 user user 4096 Jul 10 2008 props > drwx------ 2 user user 4096 Jul 10 2008 text-base > > Note: the above only works as root. User gets permission denied. > > $ find tmp/ > tmp/ > find: ftsfind.c:475: consider_visiting: Assertion `ent->fts_info == 11 || > state.type != 0' failed. > Aborted > > I think it has something to do with the wierd permission. > offtopic and not related :) yes, you have weird permissions. indexing a directory requires the 'x' attribute for a user. root of course isn't normally limited in such manner.
Created attachment 199525 [details] vacuum_mozillas.sh: a test script here is the script that fails on my ~amd64 box it's interesting to note that since the forth run, it stops failing and runs fine, as the disk cache has mattered
Created attachment 199532 [details] the output of strace the strace of the vacuum_mozillas script disk cache seems to be really important: as a matter of fact, if I echo 3 > /proc/sys/vm/drop_caches after a couple of successful runs, the problem raises again
just a note federico@neonato ~ $ find --version find (GNU findutils) 4.5.4 Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: [...] Written by Eric B. Decker, James Youngman, and Kevin Dalley. Built using GNU gnulib version 86a37c05846ff3772afd1300f135866dd1d271c6 Features enabled: D_TYPE O_NOFOLLOW(enabled) LEAF_OPTIMISATION FTS(FTS_CWDFD) CBO(level=2)
(In reply to comment #21) > the permissions on the directories are interesting. Goot catch, I think. Steps to reproduce, even without any special nodes like devices or symlinks: $ mkdir -p foo/bar $ chmod a-x foo $ find foo foo find: ftsfind.c:475: consider_visiting: Assertion `ent->fts_info == 11 || state.type != 0' failed. Aborted
(In reply to comment #32) > Steps to reproduce, even without any special nodes like devices or symlinks: Reported this variation upstream, along with some more thorough discussion: https://savannah.gnu.org/bugs/?27213
still brocken in 4.5.5
For clarification, which versions of findutils does not experience this issue? I need to know what version I should downgrade to (I'm using 4.5.5 now).
(In reply to comment #35) > For clarification, which versions of findutils does not experience this issue? > I need to know what version I should downgrade to (I'm using 4.5.5 now). > I _think_ 4.5.3-r1 is working for me although there seem to be reports that its not working -.- Can't reproduce using mkdir foo ; chmod -x foo ; find foo initially I masked >=sys-apps/findutils-4.5.4 - so I think that was the first non-working version on my side.
if you're gong to mask versions, you really should mask all of 4.5.x. this is the unstable upstream series and we wont be stabilizing it.
Created attachment 206227 [details, diff] Patch from upstream #27213 I've got a patch attached to https://savannah.gnu.org/bugs/?27213 which I'll now attach here as well for your convenience. Hasn't been commented on by upstream yet, after more than two months, but it works for me, and I guess you might include it in a findutils revbump at the distro level. And of course I'd love for subscribers of this bug to give it a try and report whether it fixes their aspect of the problem as well. Changes introduced by the patch: 1. Always print error message for FTS_NS. I can't imagine a case where you wouldn't want to learn about a stat error, especially if this could prevent you from knowing whether an inode is a directory or not. 2. assert stat.type == 0 in the case of FTS_NS. This is closer to the old !state.have_type, so I guess that's what was meant. 3. Moved some post-condition assertions in get_info from the failure case to the success case. 4. Added some comments, specially pointing out an issue with duplicate error messages. For further details please refer to the upstream bug report or ask me.
(In reply to comment #38) > Created an attachment (id=206227) [details] > Patch from upstream #27213 ... any hope of seeing this pushed out for sys-apps/findutils, ever?
> Created an attachment (id=206227) [details] [details] > Patch from upstream #27213 This patch seems to fix the find utility on my system as well. Please consider including it.
jeroen@elmer ~ $ mkdir -p foo/bar jeroen@elmer ~ $ chmod a-x foo jeroen@elmer ~ $ find foo foo find: ftsfind.c:477: consider_visiting: Assertion `ent->fts_info == 11 || state.type != 0' failed. Aborted jeroen@elmer ~ $ eversion findutils sys-apps/findutils-4.5.5
--disable-assert
If you try as root the next command # find / -iname "*~" -type f It will be very probable that the find aborts it's operation with the message (or something similar) find: ftsfind.c:477: consider_visiting: Assertion `ent->fts_info == 11 || state.type != 0' failed. The problem arises when find searches the home folder. Many users and applications don't allow reading (implies executing) directories for anybody different than the user propietary of the home folder. Martin von Gagern, thanks for the patch. I think it is impossible for "find" to change the inode if the user doesn't give the correct permisions to folders, am i wrong? If this is the case, your patch avoids the abort and continues? searching?
(In reply to comment #43) > Martin von Gagern, thanks for the patch. I think it is impossible for "find" > to change the inode if the user doesn't give the correct permisions to > folders, am i wrong? By "change the inode" you mean "change the permissions of the inode"? I'd not whish for find to perform any kind of file system modification, even in cases where this might be possible. So changing inodes would feel very wrong indeed. Or if you refer to changing the current working directory or something like that, then know that find doesn't usually chdir at all, and that it couldn't change to a non-executable directory. So in this case you are right. > If this is the case, your patch avoids the abort and continues? searching? Avoids the abort, prints an error message (or two), continues searching, yes.
Fix committed upsream, see http://git.savannah.gnu.org/cgit/findutils.git/commit/?id=20171febf2f583d83e1de0d447fa11d3e30f0ba0 through http://git.savannah.gnu.org/cgit/findutils.git/commit/?id=fb8705fc9fe8d852bbe3c47246bd44081fdff388 According to http://savannah.gnu.org/bugs/?27213 the next 4.3.x release of findutils should include this fix.
(In reply to comment #45) > Fix committed upsream, see [...] through [...] And here it is all in one diff: http://git.savannah.gnu.org/cgit/findutils.git/diff/?id=fb8705fc9fe8d852bbe3c47246bd44081fdff388&id2=969f7feed34a7ac3682d354eda6a66d80336711a
Fix released by upstream in findutils 4.5.8, please bump.
You can find a quickbumped sys-apps/findutils-4.5.8 in the sping overlay if you feel like testing...
bump requests really should be new bugs as Sebastian did
