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

Update of bug #26641 (group findutils): Status: Need Info => None ___ Reply to this item at: ___ Mess

Re: man find: unify symlink / symbolic link

On 2019-11-13 00:29, 積丹尼 Dan Jacobson wrote: > Bernhard Voelker writes: >> WDYT? > Great. Thanks for the review. Pushed at: https://git.sv.gnu.org/cgit/findutils.git/commit/?id=a0169f9aac1 Have a nice day, Berny

Re: man find: unify symlink / symbolic link

> "BV" == Bernhard Voelker writes: BV> WDYT? Great.

Re: man find: unify symlink / symbolic link

' - and additionally in 2 places in the Texinfo manual - with the attached patch. WDYT? Have a nice day, Berny >From a0169f9aac1fd65e835b9c0df4001a792716c589 Mon Sep 17 00:00:00 2001 From: Bernhard Voelker Date: Wed, 13 Nov 2019 00:15:28 +0100 Subject: [PATCH] doc: use "symbolic link

man find: unify symlink / symbolic link

On man find, the only line that talks about "symlinks" is %Y File's type (like %y), plus follow symlinks: `L'=loop, `N'=nonexistent, `?' for any other error when determining the type of the symlink target. All the many rest on that page call them symbo

Re: link

Pascal writes: > I think I misled on "*except while processing the command line argument*" > for the -H option, wich is for find and not for exec command :-( > after some internet research, I tried this : > > find . -type l -exec sh -c "md5sum \$( readlink {} )" \; > d41d8cd98f00b204e9800998ecf842

Re: link

mand line arguments. When find examines or prints > information about files, the information used shall be taken > from the prop‐ erties of the symbolic link itself. The only > exception to this behaviour is when a file specified on the > c

Re: link

Pascal writes: > how find links and exec command on pointed files ? > > $ touch a > $ ln -s a b > $ ll > a > b -> a > $ find -H . -type l -exec md5sum '{}' \; > d41d8cd98f00b204e9800998ecf8427e ./b > > md5sum is running on "./b" and not on "./a" like excepted :-( But that is the behavior expecte

link

hi, how find links and exec command on pointed files ? $ touch a $ ln -s a b $ ll a b -> a $ find -H . -type l -exec md5sum '{}' \; d41d8cd98f00b204e9800998ecf8427e ./b md5sum is running on "./b" and not on "./a" like excepted :-( regards

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

Follow-up Comment #10, bug #26641 (project findutils): I could not find findutils-4.3.8. ftp://ftp.gnu.org/gnu/findutils goes from 4.2.x to 4.4.x. So I grabbed 4.4.2 (the most recent available at the time). The problem still occurs with findutils-4.4.2/find/oldfind. It does not occur with fin

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

Update of bug #26641 (project findutils): Status:None => Need Info ___ Follow-up Comment #9: Does this problem still apply to "oldfind" in findutils-4.3.8? Are you able to test patches

Re: [PATCH] frcode: avoid link failure due to multiple program_name definitions

Applied and pushed. Thanks! James.

[PATCH] frcode: avoid link failure due to multiple program_name definitions

te: Mon, 5 Apr 2010 14:10:26 +0200 Subject: [PATCH] frcode: avoid link failure due to multiple program_name definitions * locate/frcode.c: Include "progname.h". (program_name): Remove two declarations. Now the definition comes from gnulib. --- ChangeLog |7 +++ locate/frcode

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

Follow-up Comment #8, bug #26641 (project findutils): On further reflection, fstat *would* work. The variable I was calling "dirfd" will have come from an open(2) (or dirfd(opendir()) or something like that), which will have triggered the automount, and the file descriptor will be for the mounte

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

Follow-up Comment #7, bug #26641 (project findutils): Regarding my previous comment: Oops. Can't do fstat. That will just give the stat of the (now hidden) mount point. Have to stat the path. ___ Reply to this item at:

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

that find does: printf("WARNING: Hard link count is wrong..."); turn_on_noleaf(); change it to fstat(dirfd, &new_stat_buf); if (stat_buf.st_dev != new_stat_buf.st_dev) /* probably an automount happened; just update stat info */ stat_buf = new_stat_buf; else {

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

Follow-up Comment #5, bug #26641 (project findutils): I don't use autofs, nor do I know where to report such a bug. As a user, your bug report will probably go further (but do feel free to point them to this page). Any code that is not prepared to handle st_nlink count of 1 is already broken.

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

Follow-up Comment #4, bug #26641 (project findutils): Could you ask this of the autofs folks yourself? I am, of course, willing to do my part to help resolve this issue, but I would think that me being a middle-man between findutils developers and autofs developers would be more of a hindrance t

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

Follow-up Comment #3, bug #26641 (project findutils): Could the folks at aut...@linux.kernel.org instead be persuaded that for any directory that contains auto mount points that the containing directory return a st_link count of 1 (meaning unknown number of subdirectories)? That alone would be e

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

Follow-up Comment #2, bug #26641 (project findutils): I posted to aut...@linux.kernel.org, asking whether it would make sense for automount to do a mount triggered by a stat() of the mount point. They replied that this is avoided, by design, to prevent a "mount storm" whenever a stat()ing 'ls' (

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

Follow-up Comment #1, bug #26641 (project findutils): I reckon it could be argued that the bug is with automount. Perhaps a stat(2) of an automounted mount point should trigger the automount? Still, if it's not too difficult for find to take evasive action, it would be nice. __

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

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

findutils-4.3.8: link-time failures on several platforms

Builds of findutils-4.3.8 failed on several platforms because of a missing (and nonstandard) symbol at link time: NetBSD 1.6 IA-32 with gcc, Solaris 8 SPARC, Solaris 10 IA-32, Solaris 10 SPARC, SGI IRIX 6.5 with gcc: Unresolved text symbol "strcasestr" -- 1st referenced b

[bug #19966] find should link against -lm for modf() and fabs()

Update of bug #19966 (project findutils): Open/Closed:Open => Closed Fixed Release:None => 4.3.7 ___ Reply to this item at:

[bug #19966] find should link against -lm for modf() and fabs()

Update of bug #19966 (project findutils): Summary: find should link against -lm for modf() => find should link against -lm for modf() and fabs() ___ Follow-up Comment #1: Ditto fabs() and Sola

[bug #19966] find should link against -lm for modf()

URL: <http://savannah.gnu.org/bugs/?19966> Summary: find should link against -lm for modf() Project: findutils Submitted by: jay Submitted on: Saturday 05/26/2007 at 10:20 Category: find Sever

[bug #19613] findutils 4.3.3 assertion failure on symbolic link loop on NetBSD

Update of bug #19613 (project findutils): Open/Closed:Open => Closed Fixed Release:None => 4.3.4 ___ Reply to this item at:

[bug #19613] findutils 4.3.3 assertion failure on symbolic link loop on NetBSD

Update of bug #19613 (project findutils): Status:None => Fixed ___ Reply to this item at: ___

[bug #19613] findutils 4.3.3 assertion failure on symbolic link loop on NetBSD

Follow-up Comment #1, bug #19613 (project findutils): This bug affectes only findutils-4.3.3 (that is, not previous versions). ___ Reply to this item at: ___

[bug #19613] findutils 4.3.3 assertion failure on symbolic link loop on NetBSD

URL: <http://savannah.gnu.org/bugs/?19613> Summary: findutils 4.3.3 assertion failure on symbolic link loop on NetBSD Project: findutils Submitted by: jay Submitted on: Tuesday 04/17/2007 at 07:55 Category

[bug #15800] "Hard link count is wrong" reports wrong directory

Update of bug #15800 (project findutils): Open/Closed:Open => Closed Fixed Release:None => 4.2.28 ___ Reply to this item at:

[bug #15800] "Hard link count is wrong" reports wrong directory

Follow-up Comment #2, bug #15800 (project findutils): SO what is a guy to do with this attached file? ___ Reply to this item at: ___

[bug #15800] "Hard link count is wrong" reports wrong directory

Update of bug #15800 (project findutils): Item Group:None => Wrong result Status:None => Fixed ___ Follow-up Comment #1: Fixed in both 4.

[bug #15800] "Hard link count is wrong" reports wrong directory

URL: <http://savannah.gnu.org/bugs/?func=detailitem&item_id=15800> Summary: "Hard link count is wrong" reports wrong directory Project: findutils Submitted by: None Submitted on: Sun 02/19/06 at 09:20