5
When I pass --color=always
to ls, it occasionally outputs a number of No such file or directory
errors, like this:
~/svn/projects/submm/adda/scat$ /bin/ls --color=always
ls: cannot access adda_output_f89: No such file or directory
ls: cannot access adda_output_f150: No such file or directory
ls: cannot access adda_output_f183: No such file or directory
ls: cannot access adda_output_f186: No such file or directory
ls: cannot access adda_output_f190: No such file or directory
...
Later follow the contents of the directory, including the subdirectory adda_output_f89
coloured as a directory.
There is a process running that is operating on files in this directory, but I don't think it's doing anything with the directories that ls
is mentioning.
It is not fully reproducible. I have so far not succeeded in finding out a pattern when it happens and when it doesn't happen. It appears to happen in waves. Perhaps a process is rapidly creating and removing directories, but I don't think that's true.
It appears to be happening only when I pass --color=always
, but I am not 100% sure that this is the case. Normally I use an alias, ls='ls --classify --color=always --human-readable'
where it does happen, but when I call /bin/ls
it appears that it does not happen.
Edit:
ls -i
gives for those files:
? adda_output1_f243/ ? adda_output_f243/
etc.
Edit:
This is a nfs filesystem.
What might cause this behaviour? Is it some kind of race condition?
Are you sure the error only occurs when using
--color=always
? Also, are you sure you always use/bin/ls
and not an alias? – terdon – 2013-01-16T15:01:26.740Normally I use
ls
, which is for me an alias forls --classify --color=always --human-readable
. It does not happen when I use a pure/bin/ls
or/bin/ls --classify
. I did not try all combinations of options. – gerrit – 2013-01-16T15:03:16.550What happens with
"ls" --color=always
? – speakr – 2013-01-16T15:03:49.200@speakr Unfortunately I haven't yet been able to find a way to reliably reproduce the issue, and right now it's not happening at all... I'll update if the problem returns. – gerrit – 2013-01-16T15:07:56.417
I think you found the answer, "Perhaps a process is rapidly creating and removing directories" I can't really imagine another reason. – terdon – 2013-01-16T15:10:59.437
@terdon Right, but why would that cause the observed problem? Does
ls
go through the contents of a directory twice? – gerrit – 2013-01-16T15:12:12.5702@gerrit: It finds the dir name using some kind of a
readdir
. It then tries tostat
the dir to get the details, but the directory suddenly does not exist. – choroba – 2013-01-16T15:39:31.970@choroba Right. How can I test that this is indeed the case? Note my edit; it doesn't report any inode for those directories either, but it does recognise that they are directories (with
-F
). – gerrit – 2013-01-16T15:56:30.390It could also be filesystem corruption -- dirent table corrupted or so. Run your filesystem's
fsck
tool in read-only mode to see if the volume is in a consistent state. – allquixotic – 2013-01-16T16:03:30.827@allquixotic I'll ask my sysop tomorrow. Your comments remind me of a possibly relevant fact: it's NFS. – gerrit – 2013-01-16T16:07:37.870