[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug #26641] Wrong directory hard link count message on automounted dire
From: |
anonymous |
Subject: |
[bug #26641] Wrong directory hard link count message on automounted directory. |
Date: |
Fri, 22 May 2009 17:01:39 +0000 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.10) Gecko/2009042718 CentOS/3.0.10-1.el5.centos Firefox/3.0.10 |
URL:
<http://savannah.gnu.org/bugs/?26641>
Summary: Wrong directory hard link count message on
automounted directory.
Project: findutils
Submitted by: None
Submitted on: Fri 22 May 2009 05:01:37 PM UTC
Category: find
Severity: 3 - Normal
Item Group: Wrong result
Status: None
Privacy: Public
Assigned to: None
Originator Name: Phil Dumont
Originator Email: address@hidden
Open/Closed: Open
Discussion Lock: Any
Release: 4.2.27
Fixed Release: None
_______________________________________________________
Details:
On a linux distro (CentOS 5.2, 5.3 and 5.4) an invocation of this command:
$ find /net/fs/export/vtrak3b/keeper/
...resulted in this message to stderr:
find: WARNING: Hard link count is wrong for /net/fs/export/vtrak3b/keeper/:
this may be a bug in your filesystem driver. Automatically turning on find's
-noleaf option. Earlier results may have failed to include directories that
should have been searched.
The problem seems to be a result of interaction with automount.
As soon as you access /net/host, if host is exporting any paths other than /,
the automount daemon will create a mount point /net/host/path/to/export for
every path exported by host, but doesn't actually mount anything until you
read the directory at the root of the exported path.
At first, find sees a hard link count of 2 on /net/fs/export/vtrak3b/keeper,
because the mount point was there, but the mount hadn't occurred yet, and it
was the mount point being stat(2)ed. Since the directory was newly created
and empty (no subdirs), the only links were keeper's '.' and vtrak3b's
'keeper'. Once find tried to read keeper, that triggered the automount, and
thenceforth the mount point was hidden and it was the mounted directory (which
did have sub-directories and therefore a higher hard link count) being seen.
There doesn't seem to be a Real Problem, but the message seems a bit ominous
until you figure out what's going on (which took me a while). Any chance it
could be avoided? Maybe postpone the stat of the directory until after
opening the directory triggers the automount?
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?26641>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
- [bug #26641] Wrong directory hard link count message on automounted directory.,
anonymous <=