[bug #26641] Wrong directory hard link count message on automounted directory.

[anonymous]

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/