[bug #58458] Using -L option and -samefile test will match both hard links and symbolic links, but the manual is incorrect

URL: Summary: Using -L option and -samefile test will match both hard links and symbolic links, but the manual is incorrect Project: findutils Submitted by: comppreper Submitted on: Thu 28 May 2020 0

[bug #58458] Using -L option and -samefile test will match both hard links and symbolic links, but the manual is incorrect

Follow-up Comment #3, bug #58458 (project findutils): I refer to patch file #49281: Line 135: +Directories normally have at least two hard Line 136: links; their @file{.} entry is the second one. If they have It sounds a little odd to me to describe the "." directory entry as the "second one",

[bug #14991] mtime documented incorrect or bug?

URL: Summary: mtime documented incorrect or bug? Project: findutils Submitted by: bigredradio Submitted on: Wed 11/16/05 at 21:22 Category: find

[bug #14991] mtime documented incorrect or bug?

Follow-up Comment #2, bug #14991 (project findutils): This being the case, how would perform a find for files that are 1 day old and greater. If -mtime 1 will only result in files that are 24-48 hours old. There is no +0? This still appears to be a bug. __

[bug #14991] mtime documented incorrect or bug?

Follow-up Comment #4, bug #14991 (project findutils): Why this change was made is beyond me, but I noticed that other UNIX does not work this way, however are starting to impletment this due to IEEE Std 1003.1, specs. -mtime n The primary shall evaluate as true if the file modification time su

cpio doesn't follow umask

eated with drwx-- rights, but subdirectories are OK! The -print find option, doesn't modify this behavior. In tcsh I receive the same result. I think this is the duplication of: http://lists.gnu.org/archive/html/bug-cpio/2006-03/msg4.html, but the extra is the find -name behavi

[bug #20310] updatedb generates an invalid database of (1) one filename (=concatenation of all filenames on the fs)

at 14:21 Category: updatedb Severity: 3 - Normal Item Group: Wrong result Status: None Privacy: Public Assigned to: None Originator Name: David Purdy Originator Email: Open/

[bug #20310] updatedb generates an invalid database of (1) one filename (=concatenation of all filenames on the fs)

Follow-up Comment #1, bug #20310 (project findutils): A clarification: locate spews the single very-long filename locate correctly returns nothing... ___ Reply to this item at: _

[bug #20310] updatedb generates an invalid database of (1) one filename (=concatenation of all filenames on the fs)

Follow-up Comment #5, bug #20310 (project findutils): Thank you, jay: most coreutils (including sort) are provided through busybox-1.5.1 1. from /usr/bin/sort I have the following code snippet: ... if true then sort="/usr/bin/sort -z" print_option="-print0"

[bug #20310] updatedb generates an invalid database of (1) one filename (=concatenation of all filenames on the fs)

Follow-up Comment #6, bug #20310 (project findutils): jay, the patch worked well. Thank You Very Much! :^) updatedb and locate now work as they should! I will pass the patch (& the configure file) along to the project leader. w/ gratitude, Dave __

error message on update and bios update

1. When I try to update the bios, I get the message 'bios too old', and then nothing happens 2. When I try to update other applications, I get the message Try 'Apt-get-f install' with no packages. What can I do to sort this all out David Tanner

[bug #37093] /usr/bin/xargs: rm: Argument list too long during make distclean in cross chroot

Follow-up Comment #1, bug #37093 (project findutils): A bug report has also been filed on QEMU: https://bugs.launchpad.net/qemu/+bug/1036645 ___ Reply to this item at:

[bug #37093] /usr/bin/xargs: rm: Argument list too long during make distclean in cross chroot

Follow-up Comment #3, bug #37093 (project findutils): > What version of findutils did you experience this problem > with? [user@host:/]: xargs --version xargs (GNU findutils) 4.4.2 Copyright (C) 2007 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later

[bug #40339] mountlist.c:936]: (error) Resource leak: dirp

URL: Summary: mountlist.c:936]: (error) Resource leak: dirp Project: findutils Submitted by: dcb314 Submitted on: Mon 21 Oct 2013 20:19:46 GMT Category: None Severity:

-size option

Hello, I noticed some strange behaviour of the ‘-size’ option of ‘find’, it doesn’t seem to behave like documented here , and i read this is the mailing list to report it. Please see below, i doubt it’s a bug… but does thi

Potential linux find utility bug / misdocumentation

I performed the following find on a fedora 21 linux i686 32-bit system [fedora21@localhost ~]$ find . -iname Bon* ./BonAirPainting [fedora21@localhost ~]$ find . -iname bon* ./MiscNetflix/bonbon.txt ./BonAirPainting I expected the same output since I used the -iname (ignore case name op

[bug #59991] Please update gnulib and re-release

URL: Summary: Please update gnulib and re-release Project: findutils Submitted by: dgilmangnu Submitted on: Tue 02 Feb 2021 03:54:03 PM UTC Category: find Severity: 3