On Sunday, July 22, 2018 10:09:49 PM CEST James Youngman wrote: > On Thu, Jul 12, 2018 at 10:37 PM, Jonathan M. Wilbur > > <jonathan@wilbur.space> wrote: > > “find: ../../find/util.c:297: get_info: Assertion `p->st_ino' failed.” > > Let's start by checking the symptom directly. Assuming the problem > is easily reproducible with a single file, please run the `stat` > command on that file and show us the output. You would do that like > this: > > $ stat README > File: README > Size: 4693 Blocks: 16 IO Block: 4096 regular file > Device: fd04h/64772d Inode: 144515 Links: 1 > Access: (0644/-rw-r--r--) Uid: ( 1027/ james) Gid: ( 1027/ james) > Access: 2018-07-06 09:41:30.650016507 +0100 > Modify: 2018-04-21 00:52:36.797927169 +0100 > Change: 2018-07-05 22:25:31.282307251 +0100 > Birth: - > > Here we see that this file is inode number 144515. I'm wondering if > the file you are having a problem with really appears (to stat(1)) to > have st_ino==0, or not. > > > I get this error when I run find on a mounted vboxsf filesystem. > > I've not encountered these. Could you provide - or point to - > step-by-step instructions for reproducing your problem, please? > > Thanks, > James.
I am pretty sure this is caused by stat() returning st_ino==0. There is a (private) bug in Red Hat Bugzilla about find(1) crashing on the same assertion failure while traversing an Azure CIFS file system. In that case it was confirmed by strace that stat() returning st_ino==0 is the actual cause of the crash. However, I considered it to be rather a bug in the file system implementation, not in the find(1) utility. Kamil