[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: find reports "No such file or directory"

From: Bernhard Voelker
Subject: Re: find reports "No such file or directory"
Date: Fri, 26 Jul 2019 17:49:17 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0

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 
email are unenforcable on a public mailing list like this one.  I recommend to 
an email account which does not automatically add such pointless claims.


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 

results in following error message:

`/data/sysprog/095/reports/01RPTTT127EUREX2019071720190717.XML.inc': No such 
file or directory

The mentioned file
has been created in parallel by another process and has then be renamed 
afterwards to

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,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]