public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Daniel Drake <dsd@gentoo.org>
To: Clemens Koller <clemens.koller@anagramm.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Kernel 2.6.14.2 - Hard link count is wrong
Date: Sat, 19 Nov 2005 02:08:04 +0000	[thread overview]
Message-ID: <437E8904.40001@gentoo.org> (raw)
In-Reply-To: <437E2494.6010005@anagramm.de>

[-- Attachment #1: Type: text/plain, Size: 752 bytes --]

Clemens Koller wrote:
> I get
> 
> .....
> find: WARNING: Hard link count is wrong for .: 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.
> 
> According to google, this might be a kernel bug due to some problems in 
> /proc, see:
> https://www.redhat.com/archives/fedora-list/2005-September/msg02474.html
> Well, how to debug that problem?

That find check is somewhat incorrect (hard link count can be legally modified 
after the search was started and before it finished), but I did fix up the 
/proc problems that existed a while back.

This patch will give you a more useful error from findutils.

Daniel

[-- Attachment #2: be-specific-about-hardlink-counts.patch --]
[-- Type: text/x-patch, Size: 1512 bytes --]

findutils-4.2.20 made me aware of the incorrect hardlink counts in /proc and
I've been fixing them up.

Although find made me aware of the issue, the message it prints could be more
useful: it doesn't show an accurate location of where the incorrect count
exists (instead, it seems to use the path that you gave to find on the command
line), and it would be nice if it could also report the hardlink count which
it read (on pseudo-filesystems like /proc this isn't very static). 

--- findutils-4.2.20/find/find.c.orig	2005-03-03 22:30:10.000000000 +0000
+++ findutils-4.2.20/find/find.c	2005-04-03 13:45:06.000000000 +0100
@@ -1811,8 +1811,8 @@ process_dir (char *pathname, char *name,
 		   * doesn't really handle hard links with Unix semantics.
 		   * In the latter case, -noleaf should be used routinely.
 		   */
-		  error(0, 0, _("WARNING: Hard link count is wrong for %s: 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."),
-			parent);
+		  error(0, 0, _("WARNING: Hard link count (%d) is wrong for %s: 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."),
+			statp->st_nlink, pathname);
 		  state.exit_status = 1; /* We know the result is wrong, now */
 		  options.no_leaf_check = true;	/* Don't make same
 						   mistake again */

  reply	other threads:[~2005-11-19  2:08 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-18 18:59 Kernel 2.6.14.2 - Hard link count is wrong Clemens Koller
2005-11-19  2:08 ` Daniel Drake [this message]
2005-11-20 14:41   ` Massimiliano Hofer
     [not found] ` <200511201522.35660.max@bbs.cc.uniud.it>
     [not found]   ` <4380914C.1010903@gentoo.org>
2005-11-20 15:14     ` Massimiliano Hofer
2005-11-20 18:27       ` Massimiliano Hofer
2005-11-21 11:17         ` Clemens Koller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=437E8904.40001@gentoo.org \
    --to=dsd@gentoo.org \
    --cc=clemens.koller@anagramm.de \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox