bug-findutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[PATCH] Be specific about incorrect hardlink counts


From: Daniel Drake
Subject: [PATCH] Be specific about incorrect hardlink counts
Date: Sun, 03 Apr 2005 14:14:04 +0100
User-agent: Mozilla Thunderbird 1.0 (X11/20041209)

Hi,

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).

Please consider applying this.

Daniel
--- 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 via email to

[Prev in Thread] Current Thread [Next in Thread]