Re: find reports "No such file or directory"

[Bernhard Voelker]

On 7/26/19 9:29 AM, Armin Noll wrote:
> The below email is classified: Internal

It looks like classifications and disclaimers like this and at the end of your 
original
email are unenforcable on a public mailing list like this one.  I recommend to 
use
an email account which does not automatically add such pointless claims.

> Hello,
>
> we use findutils version 4.4.2 on Red Hat Enterprise Linux 6.9.
>
> Executing the following call to find
>
> /usr/bin/find /data/sysprog/095/reports -maxdepth 1 -type f -regextype posix-egrep -regex 
> "/data/sysprog/095/reports/95RPTAB001EUREX20190717[0-9]{8}_XETCASH.*[.]DAT"
>
> results in following error message:
>
> /usr/bin/find: 
> `/data/sysprog/095/reports/01RPTTT127EUREX2019071720190717.XML.inc': No such 
> file or directory
>
> The mentioned file
> /data/sysprog/095/reports/01RPTTT127EUREX2019071720190717.XML.inc
> has been created in parallel by another process and has then be renamed 
> afterwards to
> /data/sysprog/095/reports/01RPTTT127EUREX2019071720190717.XML

This is exactly the analysis of what happened. find(1) is supposed to report
this error ... and this is why the -ignore_readdir_race option exists.

It's worth mentioning that we have an open bug report for that option
saying it's not working in some certain circumstances, but in the common
case it should work quite well.

> According to log output we have, the find takes ca. 9 seconds before it reports 
> the shown error message and terminates.

I assume you have many thousands of files in that directory, right?
Some (or many) file systems become pretty slow when there are more
than 100.000 or even a million files in one directory, or when the
file system is remote (like nfs or sshfs).  There's probably not much
that find(1) can do about it.  You could run it via strace with
timing (-tt) to find out where the time is being spent, but I guess
it is in the syscalls.

> This has been observed just once.
> We tried to reproduce this but were not successful.

This happens quite more often with more volatile file systems like /proc.

> How can this be explained?

You did. :-)

> Is this maybe a bug?

Not as long as you run it without -ignore_readdir_race.

Have a nice day,
Berny