lm@marvin.jpl.oz (Luigi Martin) (03/02/90)
I had some problems doing backups on a 32000 based machine. In particular, the
find command was complaining that stat() failed since there was no such file
or directory.
However, fsck found no problems and the directories and files involved were
( and still are ) perfectly readable. I found the problem in a subdirectory
called /gnx/src/GNX_TOOLS/bin
( find gave errors on anything after this directory ).
A hd of the guilty directory showed that the .. entry was not the second
file entry. In fact, it was the last entry. Thus .. existed, but find
"assumed" that .. would be the second file entry in the directory.
I would like to know if the .. file HAS to be the second file entry in a
directory; or if the .. file can appear anywhere ( which means there is a bug
in the depths of the find command ).
I have gone through a pile of unix books, and none of them state where the ..
file can, or cannot, appear within a directory.
Thanks
>>> Luigi Martin <<<gwyn@smoke.BRL.MIL (Doug Gwyn) (03/02/90)
In article <428@marvin.jpl.oz> lm@marvin.jpl.oz (Luigi Martin) writes: >I would like to know if the .. file HAS to be the second file entry in a >directory; or if the .. file can appear anywhere ( which means there is a bug >in the depths of the find command ). There need not even be any entries for "." and "..", although the kernel still is obliged to understand their conventional meaning when handling pathnames that contain these as pathname components. Software that depends on "." or ".." being returned via readdir() or equivalent directory scanning procedure is not very universal; software that assumes that such entries are in particular slots in a directory is really out on a limb. It should be fixed.