from:"anonymous"

[bug #65609] [wishlist] give find a "secure" or "safe" option

2024-04-18 Thread anonymous

URL:
  <https://savannah.gnu.org/bugs/?65609>

 Summary: [wishlist] give find a "secure" or "safe" option
   Group: findutils
   Submitter: None
   Submitted: Thu 18 Apr 2024 01:36:17 PM UTC
Category: find
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: John Devitofranceschi
Originator Email: j...@yahoo.com
 Open/Closed: Open
 Release: 4.6.0
 Discussion Lock: Any
   Fixed Release: None


___

Follow-up Comments:


---
Date: Thu 18 Apr 2024 01:36:17 PM UTC By: Anonymous
This is a "wishlist" item.

The 'top' command has a "secure" command line option (-s)

I think that it would be useful for find to also have a secure or safe option.
This option would inhibit potentially destructive or system/file altering
actions (eg, prevent -ok* -fprint* -exec* -delete, etc)

This would be useful to simplify the specification of "read-only" find
execution via 'sudo' and similar privilege escalation tools.

jd







___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65609>

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #65386] unknown predicate error when using '-1M' as lt 1

2024-02-28 Thread anonymous

URL:
  <https://savannah.gnu.org/bugs/?65386>

 Summary: unknown predicate error when using '-1M' as lt 1
   Group: findutils
   Submitter: None
   Submitted: Thu 29 Feb 2024 03:58:40 AM UTC
Category: find
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: Andrew Scott
Originator Email: as.w...@gmail.com
 Open/Closed: Open
 Release: 4.9.0
 Discussion Lock: Any
   Fixed Release: None


___

Follow-up Comments:


---
Date: Thu 29 Feb 2024 03:58:40 AM UTC By: Anonymous
find . (-type f) -a (-size -1M) recup_dir.101
bash: syntax error near unexpected token `('
find . (-type f) -a -size'-1M' recup_dir.101
bash: syntax error near unexpected token `('
find . -type f -a -size'-1M' recup_dir.101
find: unknown predicate `-size-1M'
find . -type f -a -size -1M recup_dir.101
find: paths must precede expression: `recup_dir.101'
find: possible unquoted pattern after predicate `-size'?
man find 
find . -type f -a -size -999k recup_dir.101
find: paths must precede expression: `recup_dir.101'
find: possible unquoted pattern after predicate `-
find . -type f -a -size %-999k recup_dir.101
find: Invalid argument `%-999k' to -size
find . -type f -a -size-999k recup_dir.101
find: unknown predicate `-size-999k'
find --version
find (GNU findutils) 4.9.0
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.








___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65386>

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #65378] B or b?

2024-02-27 Thread anonymous

URL:
  <https://savannah.gnu.org/bugs/?65378>

 Summary: B or b?
   Group: findutils
   Submitter: None
   Submitted: Tue 27 Feb 2024 06:39:27 PM UTC
Category: documentation
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: 
Originator Email: 
 Open/Closed: Open
 Release: None
 Discussion Lock: Any
   Fixed Release: None


___

Follow-up Comments:


---
Date: Tue 27 Feb 2024 06:39:27 PM UTC By: Anonymous
findutils doc for Test: -newerXY reference.

‘B’  Birth time of reference

while in the text just following, `b` is mentioned.

Which should be used, `B`(uppercase)  or `b` (lowercase) , or maybe both
variants work?

https://git.savannah.gnu.org/cgit/findutils.git/tree/doc/find.texi#n1035

PS: 
Sorry I cannot test this, Birth is not stored in my filesystem







___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65378>

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #65349] Wrong statement in -xtype documentation

2024-02-23 Thread anonymous

URL:
  <https://savannah.gnu.org/bugs/?65349>

 Summary: Wrong statement in -xtype documentation
   Group: findutils
   Submitter: None
   Submitted: Fri 23 Feb 2024 05:20:48 PM UTC
Category: documentation
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: 
Originator Email: 
 Open/Closed: Open
 Release: None
 Discussion Lock: Any
   Fixed Release: None


___

Follow-up Comments:


---
Date: Fri 23 Feb 2024 05:20:48 PM UTC By: Anonymous
findutils 4.9.0

The docs [1] say that for a symbolic link `-L -xtype X` is false unless the
symbolic link is broken.

This statement seems false: in the following example link-to-inexistent is a
broken symbolic link and is not printed.

$ rm -f inexistent; ln -s inexistent link-to-inexistent; find -L . -xtype f
$ ls -l
total 0
lrwxrwxrwx 1 xxx xxx 10 Feb 23 18:01 link-to-inexistent -> inexistent
$ find -version
find (GNU findutils) 4.9.0
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Eric B. Decker, James Youngman, and Kevin Dalley.
Features enabled: D_TYPE O_NOFOLLOW(enabled) LEAF_OPTIMISATION FTS(FTS_CWDFD)
CBO(level=2) 
$ 


[1] https://git.savannah.gnu.org/cgit/findutils.git/tree/doc/find.texi#n1217







___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65349>

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #65337] Unexepected results from complete tests on -mtime/-mmin/-daystart

2024-02-20 Thread anonymous

Follow-up Comment #2, bug#65337 (group findutils):

Sorry error sign in the creation times, the correction is:

* x0 modified at T0 - epsi0 => AGE = epsi0/P
* x1 modified at T0 - P/2 - epsi1   => AGE = 1/2 + epsi1/P
* x2 modified at T0 - P - epsi2 => AGE = 1 + epsi2/P
* x3 modified at T0 - 3/2 P - epsi3 => AGE = 3/2 + epsi3/P
* x4 modified at T0 - 2 P - epsi4   => AGE = 2 + epsi4/P
* x5 modified at T0 - 5/2 P - epsi5 => AGE = 5/2 + epsi5/P

I attached a schematic plot to clarify.

(file #55725)

___

Additional Item Attachment:

File name: test-setup.pdf Size:112 KB



AGPL NOTICE

These attachments are served by Savane. You can download the corresponding
source code of Savane at
https://git.savannah.nongnu.org/cgit/administration/savane.git/snapshot/savane-24d3702d7a77e2ff4eb0f39b986d772d82c134fd.tar.gz


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #65337] Unexepected results from complete tests on -mtime/-mmin/-daystart

2024-02-20 Thread anonymous

Follow-up Comment #1, bug#65337 (group findutils):

Sorry my email was cut during submission: r.duc...@gmail.com


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #65337] Unexepected results from complete tests on -mtime/-mmin/-daystart

2024-02-20 Thread anonymous

URL:
  <https://savannah.gnu.org/bugs/?65337>

 Summary: Unexepected results from complete tests on
-mtime/-mmin/-daystart
   Group: findutils
   Submitter: None
   Submitted: Tue 20 Feb 2024 04:58:22 PM UTC
Category: find
Severity: 3 - Normal
  Item Group: Test suite failure
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: 
Originator Email: r.duc...@gmail.com
 Open/Closed: Open
 Release: 4.9.0
 Discussion Lock: Any
   Fixed Release: None


___

Follow-up Comments:


---
Date: Tue 20 Feb 2024 04:58:22 PM UTC By: Anonymous
1 the version of findutils you are using (e.g. run "find --version" and
include the output)
findutils 4.9.0

2  what you were trying to do
Making precise checks to try to understand the precise tests associated to the
primaries -mtime -mmin, -daystart

3 the exact command line that you used
 See attached file find-time-tests-.bash

4 what you expected to happen
5 precisely what did happen.
 See discussion below, the attached file find-time-tests.out and the table in
find-time-tests-results.md (Markdown)

---
Dear maintainers of findutis

I would like to report the results of some tests I did (with findutils 4.9.0)
on the behavior of find with the primaries -mtime -mmin and with or without
-daystart.

My motivation was to understand the precise tests associated to the primaries
-mtime -mmin, -daystart because I found the docs incomplete/unclear [1]

I found a few unexpected results, I honestly do not know if these can be
qualified as bug(s) or as "well known features" not enough described in the
documentation to reach my comprehension (in which case you might want to
consider improving the documentation).

=== notations ===

To talk precisely about the expected behavior of find, let me first introduce
some definitions. (Please stay with me!)

Independently of the details of the internal code, the possible cases can be
treated by defining the AGE of a file and its rounded version RAGE as:

AGE:= (T0 - TM) / P
RAGE:= Floor[(T0 - TM) / P]

where:
* TM is the modification time
* T0 is "NOW" (execution time of find) or TOMORROW at 00:00
* P is the period or window
* all the times are measured in seconds.

Note that, according to the properties of Floor-rounding [2], for any integer
n the following holds. (Equivalence does not hold with the > sign!)

AGE < n is equivalent to RAGE < n
RAGE > n implies AGE > n
AGE > n implies RAGE >= n
AGE >= n implies RAGE >= n


To approach the current implementation, it is useful to remark that

(R)AGE < n is equivalent to T0 - n P < TM
(R)AGE >= n is equivalent to T0 - n P >= TM
AGE > n is equivalent to T0 - n P > TM


=== expectations ===

Now, what to expect from find with the primaries -mtime -mmin and -daystart?

* POSIX [3] states clearly that the primary -mtime n with n an unsigned
integer should be true if, with P=86400 T0=NOW, RAGE = n

The rest is not POSIX; from the docs [1]  I understand:

* -daystart -mtime n should be true if, with P=86400 T0=TOMORROW at 00:00,
RAGE = n

* For -mmin n  with n an unsigned integer true if, with P=60 T0=NOW, RAGE = n

* For -daystart -mmin n  with n an unsigned integer true if, with P=60
T0=TOMORROW at 00:00, RAGE = n

When signed numbers +n /-n are used (age ranges) I would expect something
like:

* A test -mtime/-mmin +n is true if AGE>n with P=86400/60 and T0=TOMORROW
00:00 or NOW according to if -startday is used or not. (Note that it is not
clear from the docs if RAGE > n should be used instead here : as stated the
two conditions are not equivalent)

* A test -mtime/-mmin -n is true if AGE < n with P=86400/60 and T0=TOMORROW
00:00 or NOW according to if -startday is used or not. (Note that RAGE < n is 
equivalent to AGE https://www.gnu.org/software/findutils/manual/html_mono
[2] https://en.wikipedia.org/wiki/Floor_and_ceiling_functions
[3] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/find.html







___
File Attachments:


---
Name: find-time-tests.bash  Size: 5KiB
<http://savannah.gnu.org/bugs/download.php?file_id=55722>
---
Name: summary-find-time-tests-results.md  Size: 2KiB
<http://savannah.gnu.org/bugs/download.php?file_id=55723>
---
Name: find-time-tests.out  Size: 11KiB
<http://savannah.gnu.org/bugs/download.php?file_id=55724>

AGPL NOTICE

These attachments are ser

[bug #65305] @var{name} should be @var{NAME}

2024-02-13 Thread anonymous

URL:
  <https://savannah.gnu.org/bugs/?65305>

 Summary: @var{name} should be @var{NAME}
   Group: findutils
   Submitter: None
   Submitted: Tue 13 Feb 2024 03:50:11 PM UTC
Category: documentation
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: 
Originator Email: 
 Open/Closed: Open
 Release: None
 Discussion Lock: Any
   Fixed Release: None


___

Follow-up Comments:


---
Date: Tue 13 Feb 2024 03:50:11 PM UTC By: Anonymous
To conform with

@deffn Test -samefile NAME in 872

all @var{name} should be @var{NAME} between 873 and 887

https://git.savannah.gnu.org/cgit/findutils.git/tree/doc/find.texi#n872







___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65305>

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #65297] -regexp incompatible statements concerning default

2024-02-12 Thread anonymous

URL:
  <https://savannah.gnu.org/bugs/?65297>

 Summary: -regexp  incompatible statements concerning default
   Group: findutils
   Submitter: None
   Submitted: Mon 12 Feb 2024 07:40:12 PM UTC
Category: documentation
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: 
Originator Email: 
 Open/Closed: Open
 Release: None
 Discussion Lock: Any
   Fixed Release: None


___

Follow-up Comments:


---
Date: Mon 12 Feb 2024 07:40:12 PM UTC By: Anonymous
"There are several varieties of regular expressions; by default this test uses
POSIX basic regular expressions, but this can be changed with the option
‘-regextype’. "

https://git.savannah.gnu.org/cgit/findutils.git/tree/doc/find.texi#n581

The above is incompatible with

‘emacs’

Regular expressions compatible with GNU Emacs; this is also the default
behaviour if this option is not used. 

https://git.savannah.gnu.org/cgit/findutils.git/tree/doc/find.texi#n597

which one is correct, I do not know :)







___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65297>

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #65283] Misleading statement, I believe

2024-02-09 Thread anonymous

URL:
  <https://savannah.gnu.org/bugs/?65283>

 Summary: Misleading statement, I believe
   Group: findutils
   Submitter: None
   Submitted: Fri 09 Feb 2024 08:12:46 PM UTC
Category: documentation
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: 
Originator Email: 
 Open/Closed: Open
 Release: None
 Discussion Lock: Any
   Fixed Release: None


___

Follow-up Comments:


---
Date: Fri 09 Feb 2024 08:12:46 PM UTC By: Anonymous
"The differences are that the locate information might be out of date, and
that locate handles wildcards in the pattern slightly differently than find
(see Shell Pattern Matching)."

https://git.savannah.gnu.org/cgit/findutils.git/tree/doc/find.texi#n651

I checked the section Shell Pattern Matching and I absolutely see no
difference among locate and find.

Maybe the writer thinks to 

locate pattern

where pattern does not contain wildcards, but this has already been explained
just above line 651.







___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65283>

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #65282] Positional option -regextype not mentioned

2024-02-09 Thread anonymous

URL:
  <https://savannah.gnu.org/bugs/?65282>

 Summary: Positional option -regextype not mentioned
   Group: findutils
   Submitter: None
   Submitted: Fri 09 Feb 2024 08:06:27 PM UTC
Category: documentation
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: 
Originator Email: 
 Open/Closed: Open
 Release: None
 Discussion Lock: Any
   Fixed Release: None


___

Follow-up Comments:


---
Date: Fri 09 Feb 2024 08:06:27 PM UTC By: Anonymous
Positional option -regextype not mentioned below:

"Therefore, for clarity, it is best to place them at the beginning of the
expression. There are two exceptions to this; ‘-daystart’ and
‘-follow’ have different effects depending on where in the command line
they appear."

https://git.savannah.gnu.org/cgit/findutils.git/tree/doc/find.texi#n339







___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65282>

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64876] Minor typo in updatedb(1) man page

2023-11-09 Thread anonymous

URL:
  <https://savannah.gnu.org/bugs/?64876>

 Summary: Minor typo in updatedb(1) man page
   Group: findutils
   Submitter: None
   Submitted: Thu 09 Nov 2023 03:06:44 PM UTC
Category: updatedb
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: 
Originator Email: 
 Open/Closed: Open
 Release: 4.9.0
 Discussion Lock: Any
   Fixed Release: None


___

Follow-up Comments:


---
Date: Thu 09 Nov 2023 03:06:44 PM UTC By: Anonymous
Line 31 in locate/updatedb.1 is ".B LOCATGE02" -- should be ".B LOCATE02".








___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?64876>

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64741] Graceful stop of xargs

2023-10-03 Thread anonymous

URL:
  <https://savannah.gnu.org/bugs/?64741>

 Summary: Graceful stop of xargs
   Group: findutils
   Submitter: None
   Submitted: Tue 03 Oct 2023 04:36:19 PM UTC
Category: xargs
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: 
Originator Email: 
 Open/Closed: Open
 Release: None
 Discussion Lock: Any
   Fixed Release: None


___

Follow-up Comments:


---
Date: Tue 03 Oct 2023 04:36:19 PM UTC By: Anonymous
Hello.
At this time there is no way to gracefully stop xargs.
If I kill main process all current running jobs will be killed too.
The most graceful way I know is to decrease maxprocs to 1, wait for this one
new process to start and then kill xargs.

Am I missing something?
If no - I suggest to allow to decrease maxprocs to 0 (or use any other signal)
to tell xargs it needs to stop after batch will be done.







___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?64741>

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64717] find-4.9.0: aborted after assertion at line 3179 of parser.c

2023-09-26 Thread anonymous

URL:
  <https://savannah.gnu.org/bugs/?64717>

 Summary: find-4.9.0: aborted after assertion at line 3179 of
parser.c
   Group: findutils
   Submitter: None
   Submitted: Tue 26 Sep 2023 12:03:18 PM UTC
Category: find
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: Jaehan Yoon
Originator Email: jaehan.y...@g.skku.edu
 Open/Closed: Open
 Release: 4.9.0
 Discussion Lock: Any
   Fixed Release: None


___

Follow-up Comments:


---
Date: Tue 26 Sep 2023 12:03:18 PM UTC By: Anonymous
On find-4.9.0, "find -amin NAN" results in abortion.

I get terminal outputs as follow:
find: ../../find/parser.c:3149: get_relative_timestamp: Assertion `nanosec <
nanosec_per_sec' failed.
Aborted

I think correct result should be same with result of "find -amin na" as:
find: invalid argument 'NAN' to '-amin'

same result occured with input like: find -amin "NAN" and I've got same result
in previous versions, 4.7.0 and 4.8.0.
I attach the image file containing terminal output.







___
File Attachments:


---
Date: Tue 26 Sep 2023 12:03:18 PM UTC  Name: find_report.png  Size: 11KiB  
By: None

<http://savannah.gnu.org/bugs/download.php?file_id=55170>

___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?64717>

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64605] Add support for extended attributes

2023-08-28 Thread anonymous

URL:
  <https://savannah.gnu.org/bugs/?64605>

 Summary: Add support for extended attributes
   Group: findutils
   Submitter: None
   Submitted: Mon 28 Aug 2023 04:49:02 PM UTC
Category: find
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: Avid Seeker
Originator Email: avidseek...@protonmail.com
 Open/Closed: Open
 Release: None
 Discussion Lock: Any
   Fixed Release: None


___

Follow-up Comments:


---
Date: Mon 28 Aug 2023 04:49:02 PM UTC By: Anonymous
XDG Extended Attributes guidelines include metadata about files that is
supported on the file system level. Many programs attach this metadata to
downloaded or produced files, and it would seem an essential feature for a
file finder.

https://www.freedesktop.org/wiki/CommonExtendedAttributes







___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?64605>

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64451] Unexpected behaviour of xargs when multiple children exit with 255 in parallel

2023-07-20 Thread anonymous

Follow-up Comment #5, bug #64451 (project findutils):

>From wait(2):
*WIFSTOPPED(*_wstatus_*)*
returns true if the child process was stopped by delivery of a signal;
this is possible only if the call was done using *WUNTRACED* or when the child
is being traced (see *ptrace*(2)).

OK so I guess this functionality is not supposed to be used as was testing
it.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64451] Unexpected behaviour of xargs when multiple children exit with 255 in parallel

2023-07-20 Thread anonymous

Follow-up Comment #4, bug #64451 (project findutils):

I still can't figure out how catching SIGSTOP is supposed to work. Neither
SIGSTOP nor SIGTSTP seem to be caught.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64451] Unexpected behaviour of xargs when multiple children exit with 255 in parallel

2023-07-20 Thread anonymous

Follow-up Comment #3, bug #64451 (project findutils):

I've been able to fix this behaviour by explicitly calling
_wait_for_proc_all_(). I can't imagine any reprocussions from doing this, but
the current code expects _wait_for_proc_all_() to be called _atexit_() so I
would need some insight into whether this is good or bad.

(file #54946)

___

Additional Item Attachment:

File name: 0001-Add-quick-and-dirty-fix-for-bug-64451.patch Size:2 KB
   




___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64451] Unexpected behaviour of xargs when multiple children exit with 255 in parallel

2023-07-20 Thread anonymous

Follow-up Comment #2, bug #64451 (project findutils):

Because checks for WSTOPSIG and WTERMSIG are done in the same place,
sending SIGTERM or SIGSTOP to the children should also cause the same
behaviour. In reality though trying to _kill_ chuldren with this tester

seq 3 | xargs -n1 -P0 sh -c 'for i do echo start $i; sleep 20; echo stop $i;
done' _; echo xargs exited here with $?

I discovered that _kill pid_ causes this behaviour.

start 1
start 2
start 3
xargs: sh: terminated by signal 15 # I run "kill pid" on another terminal
xargs exited here with 125
stop 1
stop 3

But _kill -STOP pid_ causes this:

start 1
start 2
start 3
# I run "kill -STOP pid" on another terminal
stop 1
stop 3
# xargs now just waits. I run "kill -CONT pid" on another terminal.
stop 2
xargs exited here with 0




___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64451] Unexpected behaviour of xargs when multiple children exit with 255 in parallel

2023-07-20 Thread anonymous

Follow-up Comment #1, bug #64451 (project findutils):

A workaround for scripts is to perform checks as soon as possible and exit
1 (or other value) instead. Potentially hundreds of processes will still be
spawned but this avoids potentially processing outputs that are not yet
complete.
Another way is to catch 124 and interrupt the script right there.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64451] Unexpected behaviour of xargs when multiple children exit with 255 in parallel

2023-07-20 Thread anonymous

URL:
  <https://savannah.gnu.org/bugs/?64451>

 Summary: Unexpected behaviour of xargs when multiple children
exit with 255 in parallel
   Group: findutils
   Submitter: None
   Submitted: Thu 20 Jul 2023 07:46:06 AM UTC
Category: xargs
Severity: 3 - Normal
  Item Group: Wrong result
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: 
Originator Email: 
 Open/Closed: Open
 Release: 4.9.0
 Discussion Lock: Any
   Fixed Release: None


___

Follow-up Comments:


---
Date: Thu 20 Jul 2023 07:46:06 AM UTC By: Anonymous
= Synopsis =
When xargs is invoked with *-P* option set to a value other than 1 or 2
and more that one child exits with 255, xargs fails to wait on all children
before exiting.
*-P0* breaks in the same manner on just one exit 255.
The case for *-P2* is a degenerate case where the second child exiting
would cause this bug, but as it is the last running child, exiting with 255
does not cause any misbehaviour.
= Examples =

# One exit 255
seq 10 | xargs -n1 -P4 sh -c 'for i do echo start $i; sleep $i; if [ $i -eq 3
]; then echo exit $i; exit 255; fi; echo stop $i; done' _; echo xargs exited
here with $?
start 1
start 2
start 3
start 4
stop 1
start 5
stop 2
start 6
exit 3
xargs: sh: exited with status 255; aborting
stop 4
stop 5
stop 6
xargs exited here with 124

After job 3 exited with 255, xargs correctly waits for already started
jobs to finish.

# Two exit 255s
seq 10 | xargs -n1 -P4 sh -c 'for i do echo start $i; sleep $i; if [ $i -ge 3
] && [ $i -le 4 ]; then echo exit $i; exit 255; fi; echo stop $i; done' _;
echo xargs exited here with $?
start 1
start 2
start 3
start 4
stop 1
start 5
stop 2
start 6
exit 3
xargs: sh: exited with status 255; aborting
exit 4
xargs: sh: exited with status 255; aborting
xargs exited here with 124
stop 5
stop 6

xargs exits after job 4. Jobs 5 and 6 continue to run in background. It
can no longer be guaranteed that jobs 5 and 6 will complete before further
processing in some script.
= POSIX compliance =
This breaks a POSIX requirement.
>From xargs(1p):
Implementations wanting to provide parallel operation of the invoked
utilities are encouraged to add an option enabling parallel invocation, but
should still wait for termination of all of the children before _xargs_
terminates normally.
= Quick debugging =
After adding unconditional error messages to the _wait_for_proc_all_()
function

diff --git a/xargs/xargs.c b/xargs/xargs.c
index fdede10..9bc7aa7 100644
--- a/xargs/xargs.c
+++ b/xargs/xargs.c
@@ -1597,6 +1597,7 @@ wait_for_proc (bool all, unsigned int minreap)
 static void
 wait_for_proc_all (void)
 {
+  error (0, 0, _("wait_for_proc_all enter"));
   static bool waiting = false;

   /* This function was registered by the original, parent, process.
@@ -1614,6 +1615,7 @@ wait_for_proc_all (void)
   wait_for_proc (true, 0u);
   waiting = false;

+  error (0, 0, _("wait_for_proc_all before child_error test"));
   if (original_exit_value != child_error)
 {
   /* wait_for_proc () changed the value of child_error ().  This

and testing xargs again, the following is observed:

# One exit 255
seq 10 | ./xargs -n1 -P4 sh -c 'for i do echo start $i; sleep $i; if [ $i -ge
3 ] && [ $i -le 3 ]; then echo exit $i; exit 255; fi; echo stop $i; done' _;
echo xargs exited here with $?
start 1
start 2
start 3
start 4
stop 1
start 5
stop 2
start 6
exit 3
./xargs: sh: exited with status 255; aborting
./xargs: wait_for_proc_all enter
stop 4
stop 5
stop 6
./xargs: wait_for_proc_all before child_error test
xargs exited here with 124


# Two exit 255s
seq 10 | ./xargs -n1 -P4 sh -c 'for i do echo start $i; sleep $i; if [ $i -ge
3 ] && [ $i -le 4 ]; then echo exit $i; exit 255; fi; echo stop $i; done' _;
echo xargs exited here with $?
start 1
start 2
start 3
start 4
stop 1
start 5
stop 2
start 6
exit 3
./xargs: sh: exited with status 255; aborting
./xargs: wait_for_proc_all enter
exit 4
./xargs: sh: exited with status 255; aborting
xargs exited here with 124
stop 5
stop 6

It can be seen that in the second case _wait_for_proc_all_() did not reach
_before child_error test_ line.
= My hypothesis =
As _wait_for_proc_all_() is registered via _atexit_() it is called when
the first exit 255 is handled with _error_() (which itself calls _exit_()),
then _wait_for_proc_all_() calls _wait_for_proc_() inside of which another
_exit_() is called.
According to atexit(3):
POSIX.1 says that the result of calling *exit*(3) more than once (i.e.,
calling *exit*(3) within a function registered using *atexit*()) is undefined.
On some systems (but not Linux), this can resu

[bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

2023-07-19 Thread anonymous

Follow-up Comment #11, bug #64442 (project findutils):

It is probably more reasonable to test with USR2 as pkill will signal any
xargs running on the system.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

2023-07-19 Thread anonymous

Follow-up Comment #10, bug #64442 (project findutils):

An automated test for this issue can be done with

sleep 0.2 && pkill -USR1 xargs & { sleep 0.5 && echo success; } | xargs




___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

2023-07-19 Thread anonymous

Follow-up Comment #9, bug #64442 (project findutils):

I decided to strace xargs on my phone and curiously read() is interrupted
there as well but does not cause any problems.

(file #54945)

___

Additional Item Attachment:

File name: strace-android.txt Size:33 KB




___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

2023-07-19 Thread anonymous

Follow-up Comment #8, bug #64442 (project findutils):

I retract my previous statement the patch works, I just accidentaly ran system
xargs instead of the locally built one.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

2023-07-19 Thread anonymous

Follow-up Comment #7, bug #64442 (project findutils):

After testing further I found that SA_RESTART only fixes the case of waiting
on read.
I managed to trigger _xargs: error closing file_ by running this

c=1; while true; do printf '%s\n' "$c"; c=$((c+1)); done | xargs

and sending USR1 to xargs.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

2023-07-19 Thread anonymous

Follow-up Comment #6, bug #64442 (project findutils):

Setting _sa_flags_ to SA_RESTART fixes this.

(file #54944)

___

Additional Item Attachment:

File name: sa_flags.diff  Size:0 KB




___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

2023-07-19 Thread anonymous

Follow-up Comment #5, bug #64442 (project findutils):


>From sigaction(3p)
...
The _sa_flags_ field can be used to modify the behavior of the specified
signal.
...
SA_RESTART
This flag affects the behavior of interruptible functions; that is, those
specified to fail with errno set to *[EINTR]*. If set, and a function
specified as interruptible is interrupted by this signal, the function shall
restart and shall not fail with *[EINTR]* unless otherwise specified. If an
interruptible function which uses a timeout is restarted, the duration of the
timeout following the restart is set to an unspecified value that does  not
exceed the original timeout value. If the flag is not set, interruptible
functions interrupted by this signal shall fail with _errno_ set to
*[EINTR]*.
...

xargs sets _sa_flags_ to 0

xargs.c:735
xargs.c:741
  sigact.sa_flags = 0;

so read() is interrupted.

safe_read() is supposed to handle that but somehow doesn't.
Also safe_read() is supposed to but does not set SAFE_READ_ERROR for some
reason.

xargs.c:1377
  /* We use safe_read here in order to avoid an error if
 SIGUSR[12] is handled during the read system call. */




___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

2023-07-19 Thread anonymous

Follow-up Comment #4, bug #64442 (project findutils):

Here is a diff between a normal xargs execution and one interrupted with
SIGUSR1.
Normal execution is just running xargs and entering ^D.

--- strace-normal.txt   2023-07-19 14:31:18.639157032 +0300
+++ strace-usr1.txt 2023-07-19 14:21:40.390915386 +0300
 newfstatat(0, "", {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0x9), ...},
AT_EMPTY_PATH) = 0
-read(0, "", 1024)   = 0
+read(0, 0x565271e47710, 1024)   = ? ERESTARTSYS (To be restarted if
SA_RESTART is set)
+--- SIGUSR1 {si_signo=SIGUSR1, si_code=SI_USER, si_pid=946742, si_uid=1000}
---
+rt_sigreturn({mask=[]}) = -1 EINTR (Interrupted system call)
 pipe2([3, 4], 0)= 0
 fcntl(4, F_SETFD, FD_CLOEXEC)   = 0
-clone(child_stack=NULL,
flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0x7f9e4a386a10) = 947550
+clone(child_stack=NULL,
flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0x7fdbe000fa10) = 946743
 close(4)= 0
 read(3, "", 4)  = 0
 close(3)= 0
 SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=947550,
si_uid=1000, si_status=0, si_utime=0, si_stime=0} ---
-getpid()= 947549
-wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 947550
+getpid()= 946735
+wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 946743
+--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=946743,
si_uid=1000, si_status=0, si_utime=0, si_stime=0} ---
 lseek(0, 0, SEEK_CUR)   = -1 ESPIPE (Illegal seek)
 close(0)= 0
+openat(AT_FDCWD, "/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 0
+newfstatat(0, "", {st_mode=S_IFREG|0644, st_size=2998, ...}, AT_EMPTY_PATH) =
0
+read(0, "# Locale name alias data base.\n#"..., 4096) = 2998
+read(0, "", 4096)   = 0
+close(0)= 0
+openat(AT_FDCWD, "/usr/share/locale/en_US.UTF-8/LC_MESSAGES/findutils.mo",
O_RDONLY) = -1 ENOENT (No such file or directory)
+openat(AT_FDCWD, "/usr/share/locale/en_US.utf8/LC_MESSAGES/findutils.mo",
O_RDONLY) = -1 ENOENT (No such file or directory)
+openat(AT_FDCWD, "/usr/share/locale/en_US/LC_MESSAGES/findutils.mo",
O_RDONLY) = -1 ENOENT (No such file or directory)
+openat(AT_FDCWD, "/usr/share/locale/en.UTF-8/LC_MESSAGES/findutils.mo",
O_RDONLY) = -1 ENOENT (No such file or directory)
+openat(AT_FDCWD, "/usr/share/locale/en.utf8/LC_MESSAGES/findutils.mo",
O_RDONLY) = -1 ENOENT (No such file or directory)
+openat(AT_FDCWD, "/usr/share/locale/en/LC_MESSAGES/findutils.mo", O_RDONLY) =
-1 ENOENT (No such file or directory)
+write(2, "xargs: ", 7)  = 7
+write(2, "error closing file", 18)  = 18
+write(2, "\n", 1)   = 1
 close(1)= 0
 close(2)= 0
-exit_group(0)   = ?
-+++ exited with 0 +++
+exit_group(1)   = ?
 exited with 1 +++

*I removed lines that are the same but with different adresses due to ASLR

(file #54941, file #54942)

___

Additional Item Attachment:

File name: strace-normal.txt  Size:5 KB


File name: strace-usr1.txtSize:6 KB




___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

2023-07-18 Thread anonymous

Follow-up Comment #1, bug #64442 (project findutils):

I got same behaviour after building from findutils-4.9.0.tar.xz and master
branch commit 81bcf2b9b39a107a5417867edeb7d65c731a1720


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64442] xargs closes stdin on receiving SIGUSR1 or SIGUSR2

2023-07-18 Thread anonymous

URL:
  <https://savannah.gnu.org/bugs/?64442>

 Summary: xargs closes stdin on receiving SIGUSR1 or SIGUSR2
   Group: findutils
   Submitter: None
   Submitted: Tue 18 Jul 2023 02:52:32 PM UTC
Category: xargs
Severity: 3 - Normal
  Item Group: Wrong result
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: 
Originator Email: 
 Open/Closed: Open
 Release: 4.9.0
 Discussion Lock: Any
   Fixed Release: None


___

Follow-up Comments:


---
Date: Tue 18 Jul 2023 02:52:32 PM UTC By: Anonymous
1. the version of findutils you are using:

$ xargs --version
xargs (GNU findutils) 4.9.0
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Eric B. Decker, James Youngman, and Kevin Dalley.


2. what you were trying to do:
Move selected image files to a different location.

3. the exact command line that you used:

find . -type f | sort | sxiv -iof | tr '\n' '\0' | xargs -0rP0 mv -t ../dest


4. what you expected to happen:
On receiving SIGUSR1 or SIGUSR2 xargs adjusts its proc_max and keeps waiting
for input.

5. precisely what did happen:
xargs errors with:

xargs: error closing file

exits with 1 and breaks my pipeline as selected items will not be processed
anymore.

Notes:
N1. This can be reproduces by just running

$ xargs

and sending SIGUSR1 or SIGUSR2 from a different terminal

$ pkill -USR1 xargs


N2. I've pinpointed that the error message comes from gnulib/closein.c

N3. This behaviour is reproducible on my Arch Linux x86_64 machine
but isn't on Termux on my armv7l Android phone.

N4. Current workaround is to replace xargs with a while loop but it's less
efficient as I have to run mv on every single item which is just less
efficient.

There is also this workaround

tr '\n' '\0' | find -files0-from - -maxdepth 0 -exec mv -t ../dest +

which works for filenames but not for arbitrary input.

N5. This bug is not very critical as in most cases when I pkill xargs it has
already read in all input so no error happens.
I run some scripts that process large files in parallel so sometimes I adjust
parallelism with pkill -USR1(or -USR2) xargs but one time it 'killed' my xargs
that was waiting on hundreds of items and I had to select them anew.







___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?64442>

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64253] Suggestion - Add support for libmagic and xattr

2023-05-25 Thread anonymous

URL:
  <https://savannah.gnu.org/bugs/?64253>

 Summary: Suggestion - Add support for libmagic and xattr
   Group: findutils
   Submitter: None
   Submitted: Thu 25 May 2023 07:18:47 PM UTC
Category: find
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: Jay
Originator Email: the-m...@github.com
 Open/Closed: Open
 Release: None
 Discussion Lock: Any
   Fixed Release: None


___

Follow-up Comments:


---
Date: Thu 25 May 2023 07:18:47 PM UTC By: Anonymous
I've gone through past patches, bugs and suggestions and I was surprised I
could not find any mention of the obvious idea of adding support for libmagic
(magic | file | etc), so thought that it might be a useful feature to find,
here are some ideas.

Also while I think about this, and with the growing use of extended attributes
by applications, it may also make sense to think about including some sort of
xattr filter too. 
Most filesystems on which find is er..., found, have xattr capability and it
has been present in almost all contemporary operating systems kernels for the
best part of two decades.
[https://man7.org/linux/man-pages/man7/xattr.7.html man xattr]


Homepage here:
[https://www.darwinsys.com/file/ file | magic | libmagic]

Google have convinced ICANN that file extension like TLDs such as '.zip' are a
good idea. This sets a ball rolling, others will folow. This means OSs will
finally have to adapt and accept that deciding what a file is for, just based
on a parts of the given file name is naive and will have to make use of the
actual contents (as IMO as they should have a long time ago).  Very soon
extensions mean little other than a hint to the human.
[https://www.wired.com/story/google-zip-mov-domains-phishing-risks/  WIRED]

Features like these would allow searching of folders for type rather than
extension, without extra levels of scripting.

e.g.
Currently - without find : this is inefficient as we can't add filter without
adding code and we are already spawning thousands of find instances.


for f in ./*; do
if [[ $(file -b $f) == ".*PE32 executable.*" ]]; then
my_command $f; 
fi; 
done



Currently - with find : We need xargs and sed and so have to worry about
whitespace paths and filenames, we are also spawning several sub-commands.


find -type f |
 xargs file |
  sed -n 's/:.*PE32 executable.*/p' |
   xargs my_command 


Conceptual new usage (syntax usage tbd)

# For libmagic
find . -magic ".*ELF.*x86_64.*" -not -path "./bin/*" -exec my_command  {} \;
find . -mime ".*application/x-dosexec.*" -not -path "./bin/*" -mv {}
/Quaranteen/

# For xattr
find . -xattr 1 app.browser.url -xattr-substr 1 "http://download.org; -delete
find . -xattr 1 os.hash.blake2 -not -xattr-re 1 "^ERROR:bad hash.*" -exec hash
whirlpool {} ;\









___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?64253>

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64088] find should support file attribute flags (immutable, append-only, fscrypt, etc.)

2023-04-21 Thread anonymous

URL:
  <https://savannah.gnu.org/bugs/?64088>

 Summary: find should support file attribute flags (immutable,
append-only, fscrypt, etc.)
   Group: findutils
   Submitter: None
   Submitted: Fri 21 Apr 2023 10:55:41 PM UTC
Category: find
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: Andreas Dilger
Originator Email: adilger.gnuf...@dilger.ca
 Open/Closed: Open
 Release: None
 Discussion Lock: Any
   Fixed Release: None


___

Follow-up Comments:


---
Date: Fri 21 Apr 2023 10:55:41 PM UTC By: Anonymous
It should be possible to use find to locate files and directories with or
without specific file attribute flags, such as append-only, immutable, nodump,
fscrypt, verity, dax, projinherit, etc.

Some of these flags are Linux-specific, or filesystem-specific, but some of
them are available on multiple OSes and filesystems (e.g. append-only,
immutable, nodump).   On Linux the file attributes are available via the
"statx(3)" syscall so there is no extra overhead to fetching them, otherwise
if statx(3) is not available they can be accessed on multiple filesystems
(ext2, ext4, XFS, btrfs, etc.) via:

long flags;

ioctl(fd, FS_IOC_GETFLAGS, );

This allows finding e.g. files that meet specific security or administrative
requirements (e.g. should be immutable, encrypted, have project quotas,
etc.).

I would suggest to use "[!] -attr [^]ATTR[,[^]ATTR]" to find files
with/without the named attributes. [^] means files do NOT have the named
attribute, which allows specifying a mix of attributes that are or are not set
on a single file, as opposed to unlisted attributes that are ignored.

It should also be possible to print a comma-separated list of file attribute
names (or hex number for unknown attributes) with "-printf", possibly "%e"
could be used (vs. "%x" for -xattr which is different), since it is unused by
both "find" and "stat(1)".







___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?64088>

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #46305] Doing "find -L . -type d -delete" fails on symlinks to directories.

2023-01-31 Thread anonymous

Follow-up Comment #9, bug #46305 (project findutils):

Oh, and the patch that tries unlink() if rmdir() failes with ENOTDIR.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #46305] Doing "find -L . -type d -delete" fails on symlinks to directories.

2023-01-31 Thread anonymous

Follow-up Comment #8, bug #46305 (project findutils):

You bring up great points.

I'd welcome a new, separate command-line option for a symlink-following
delete, and the documentation change stating that -L is used during traversal
only.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #46305] Doing "find -L . -type d -delete" fails on symlinks to directories.

2023-01-30 Thread anonymous

Follow-up Comment #6, bug #46305 (project findutils):

It looks like the right thing to do is to delete the link and the thing the
link points to, if the `-L` option (follow links) is enabled.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #46305] Doing "find -L . -type d -delete" fails on symlinks to directories.

2022-10-24 Thread anonymous

Follow-up Comment #5, bug #46305 (project findutils):

(Wow, I'd forgotten all about this bug report!)

The interactions between find and symlinks have complicated implications,
that's for sure.

As  said:
> Finally, also rm(1) and rmdir(1) do not have an -L option - probably
> for a good reason.

There's a physical and a logical structure of a filesystem, as exemplified in
the `pwd` command's man page:
> -L, --logical
> use PWD from environment, even if it contains symlinks
> -P, --physical
> avoid all symlinks

Removing (rm -rf) a physical directory tree is straightforward, and it's easy
to reason about, mainly because it's a tree and therefore easy to say what
things are in the set of things to delete.

Removing a logical directory structure (because we're following symlinks, we
can't call it a tree) is straightforward too, at least from the point of view
of the algorithm:  Recursively descend the directories, delete everything you
find.

One problem: those darn symlinks can point to places you didn't really want to
delete: if someone innocently created a symlink to `/` in one of the
subdirectories then you're well on your way to an `rm -rf /` catastrophe.

It seems like the Unix philosophy is "If a tool isn't sharp enough to cut you
badly, then it's not sharp enough to use."  To which some have responded
"Sure, but don't put the sharp edges on the handle!"  

It looks a bit like the risk of `rm -rf /` is a sharp-edges-on-the-handle
problem, as any user can create them, but it could be argued either way.  It's
already in `find` and people have probably already written code that depends
on it, so that train has left the station.

As for the original problem: when a symlinked thing is deleted, I would argue
that the user intended to delete the symlink and the thing, not just the
thing: when they specify `-delete`, they want that directory entry and all it
represents to be gone.  This then prevents the 'directory not empty' and 'not
a directory' problems seen in 's comment.  If there happen to be other
symlinks that were outside the graph of things traversed, then they shall
become broken.

One more complication:

$ date > file1
$ ln -s file1 file2
$ ln -s file2 file3
$ mkdir dir1
$ ln -s dir1 dir2
$ ln -s dir2 dir3
$ ls -l

total 4
drwxrwxr-x. 2 user user 40 Oct 24 13:40 dir1
lrwxrwxrwx. 1 user user  4 Oct 24 13:40 dir2 -> dir1
lrwxrwxrwx. 1 user user  4 Oct 24 13:40 dir3 -> dir2
-rw-rw-r--. 1 user user 29 Oct 24 13:37 file1
lrwxrwxrwx. 1 user user  5 Oct 24 13:37 file2 -> file1
lrwxrwxrwx. 1 user user  5 Oct 24 13:37 file3 -> file2

$ find -L file3 dir3 -delete
find: cannot delete ‘dir3’: Not a directory

$ ls -l
drwxrwxr-x. 2 user user 40 Oct 24 13:40 dir1
lrwxrwxrwx. 1 user user  4 Oct 24 13:40 dir2 -> dir1
lrwxrwxrwx. 1 user user  4 Oct 24 13:40 dir3 -> dir2
-rw-rw-r--. 1 user user 29 Oct 24 13:37 file1
lrwxrwxrwx. 1 user user  5 Oct 24 13:37 file2 -> file1

Currently it deletes only file3, whereas I'd argue it should delete
everything.  To do that, it would need to manually follow symlink chains and
delete the links and the final filesystem object.

Thanks


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #62227] Incorrect warning for -name /

2022-04-15 Thread anonymous

Follow-up Comment #6, bug #62227 (project findutils):

[comment #5 comment #5:]
> Okay, I agree.
> 
> The attached patch changes the behavior (with the first one doing
> a trivial cleanup), and I'd like to improve the documentation further in a
separate patch.
> 
> Please check.
> 
> (file #53051, file #53052)

Thanks, the code seems to do what I expect. However, the test may fail if the
test suite is run when stdin is not a tty, as that suppresses warnings. To
test that, you can run 'make check https://savannah.gnu.org/bugs/?62227>

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #62255] find -iname Word and find -iname word give different results

2022-04-04 Thread anonymous

Follow-up Comment #1, bug #62255 (project findutils):

it seems the wildcard in front and behind of compact turned it into bold


[comment #0 original submission:]
> find (GNU findutils) 4.9.0
> Copyright (C) 2022 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
.
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> 
> I was trying to find a file by name that contains the word: compact not sure
if capitalized or not
> 
> so I used 
> user@computer:~$ find -iname *compact*
> and got one result, not the file I was looking for
> 
> then I tried
> user@computer:~$ find -iname *Compact*
> and got 7 results including the previous one, my file was there
> 
> (originally on 4.8 that comes preinstalled, installed 4.9.0 and got the same
results)
> 


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #62255] find -iname Word and find -iname word give different results

2022-04-04 Thread anonymous

URL:
  

 Summary: find -iname *Word* and find -iname *word* give
different results 
 Project: findutils
Submitted by: None
Submitted on: Mon 04 Apr 2022 10:13:54 PM UTC
Category: find
Severity: 3 - Normal
  Item Group: Wrong result
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: ega
Originator Email: 
 Open/Closed: Open
 Release: 4.9.0
 Discussion Lock: Any
   Fixed Release: None

___

Details:

find (GNU findutils) 4.9.0
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

I was trying to find a file by name that contains the word: compact not sure
if capitalized or not

so I used 
user@computer:~$ find -iname *compact*
and got one result, not the file I was looking for

then I tried
user@computer:~$ find -iname *Compact*
and got 7 results including the previous one, my file was there

(originally on 4.8 that comes preinstalled, installed 4.9.0 and got the same
results)





___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #62227] Incorrect warning for -name /

2022-03-29 Thread anonymous

Follow-up Comment #4, bug #62227 (project findutils):

[comment #3 comment #3:]
> So for my understanding:
> if 'find / -prune -name /' boils down to 'echo /', then what is
> the real use case behind?

In that case it does not do anything useful, sure. To get something useful we
would need to add more. A minimal example to demonstrate the use of -name /
might be


$ find / ! -name / -prune


This prints all entries in the root directory without recursing, in a way that
should work in any POSIX-compatible implementation of find.


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #62227] Incorrect warning for -name /

2022-03-28 Thread anonymous

Follow-up Comment #2, bug #62227 (project findutils):

[comment #1 comment #1:]
> I personally like to get such a warning, as one should try to use
-name/-iname
> with patterns for basenames only, and I think that the use case 'find /
-prune -name /'
> is quite exotic (and I would never have tried it myself TBH), so I'm
wondering if it's
> worth bothering to improve the warning diagnostic as shown above.

I agree that it makes sense to warn for a name that cannot ever be a basename,
but that means no warning should be issued for -name /, as / is a valid
basename.

For the record, -name / and -wholename / do not match in exactly the same
cases, because the basename of the root directory is / regardless of how it is
spelt:


$ find /// -prune -name /
find: warning: ‘-name’ matches against basenames only, but the given
pattern contains a directory separator (‘/’), thus the expression will
evaluate to false all the time.  Did you mean ‘-wholename’?
///

$ find /// -prune -wholename /
find: warning: -wholename / will not match anything because it ends with /.


(That is another incorrect warning, -wholename / certainly can match despite
ending in /, but that is not part of this bug report.)


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #62089] find -size -1024k different from -size -1M

2022-02-20 Thread anonymous

Follow-up Comment #2, bug #62089 (project findutils):

I think I know why, in `man find`, it actually gives an example:

```
   -size n[cwbkMG]

...

The + and - prefixes signify greater than and less than, as usual; i.e., an
exact size of n units does not match.  Bear in mind that the size is rounded
up  to  the
  next unit.  Therefore -size -1M is not equivalent to -size
-1048576c.  The former only matches empty files, the latter matches files from
0 to 1,048,575 bytes.

```

So it "only matches empty files"! this behavior is so confusing!

Can we change to let 1M means 1,048,575 bytes? or at least issue a warning:
saying "this flag only matches empty files"!.



___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #62089] find -size -1024k different from -size -1M

2022-02-20 Thread anonymous

Follow-up Comment #1, bug #62089 (project findutils):

I also asked my question here:

https://stackoverflow.com/questions/71200433/linux-find-by-size-bug


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #61640] find -ls gives no UFT-8 output

2021-12-08 Thread anonymous

URL:
  

 Summary: find -ls gives no UFT-8 output
 Project: findutils
Submitted by: None
Submitted on: Wed 08 Dec 2021 01:44:52 PM UTC
Category: find
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: 
Originator Email: 
 Open/Closed: Open
 Release: 4.8.0
 Discussion Lock: Any
   Fixed Release: None

___

Details:

example:
touch ~/tmp/blöd
find ~/tmp -name "*lö*" -ls
  5115990  0 -rw-r--r--   1 user   user  0 Dez  8 14:41
/home/user/tmp/bl\303\266d





___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #61518] Typo in find --help documentation

2021-11-21 Thread anonymous

URL:
  

 Summary: Typo in find --help documentation
 Project: findutils
Submitted by: None
Submitted on: Sun 21 Nov 2021 10:29:59 AM UTC
Category: documentation
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: Frank
Originator Email: frasob...@web.de
 Open/Closed: Open
 Release: None
 Discussion Lock: Any
   Fixed Release: None

___

Details:

1.find (GNU findutils) 4.8.0
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Eric B. Decker, James Youngman, and Kevin Dalley.
Aktivierte Eigenschaften: D_TYPE O_NOFOLLOW(enabled) LEAF_OPTIMISATION
FTS(FTS_CWDFD) CBO(level=2)

2. and 3. find --help

4. and 5. In the section "Tests":   ... -readable -writalbe -executable ...

I think it should be ... -writable ...

I searched for an already submitted bug.




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #61501] find -execdir wrong root item path

2021-11-17 Thread anonymous

URL:
  

 Summary: find -execdir wrong root item path
 Project: findutils
Submitted by: None
Submitted on: Wed 17 Nov 2021 04:39:21 PM UTC
Category: find
Severity: 3 - Normal
  Item Group: Wrong result
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: Skeleton Zombie
Originator Email: skeletonzombi...@web.de
 Open/Closed: Open
 Release: None
 Discussion Lock: Any
   Fixed Release: 4.8.0

___

Details:

find -execdir gives the wrong path for the root item

$ find . -execdir printf '%s\n' '{}' ';'
./.   # expect "."
./apple
./banana

$ find /foo -execdir printf '%s\n' '{}' ';'
./foo # expect "."
./apple
./banana


for -exec the result is correct

$ find . -exec printf '%s\n' '{}' ';'
.
./apple
./banana

$ find /foo -exec printf '%s\n' '{}' ';'
/foo
/foo/apple
/foo/banana


Thanks and Greetings





___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #61009] xargs need option to immediately stop on command fail

2021-08-10 Thread anonymous

Follow-up Comment #8, bug #61009 (project findutils):

[comment #7 comment #7:]
> The idiom 'find -type f | xargs -IX cp X ...' is per se unsafe:
> `xargs -I` reads the input line by line - but yes, files can
> have a newline in their name!

> Alternatively, use 'find ... -print0 | xargs -0 ...' instead.

Newlines in file names - of course. I forgot about it :-). But we can use
-print0/-0 for this. No problem. -exec find option is good, but it can cause
complex contructs with parentheses and etc. For simple cases -exec is good.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #61009] xargs need option to immediately stop on command fail

2021-08-09 Thread anonymous

Follow-up Comment #6, bug #61009 (project findutils):


[comment #5 comment #5:]
> Sorry, that had an obvious bug, here's a fix:
> 
> find . -type f \( -exec cp -t "${IMGDIR_DST}" {} + -o -quit \)

IMHO, this isn't _less_complex_ :-). There are:
- \( \)
- \+
- -o -quit

This is complex. There are more than one place where i can mistake.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #61009] xargs need option to immediately stop on command fail

2021-08-05 Thread anonymous

Follow-up Comment #3, bug #61009 (project findutils):

> This is my guess because the shown use of find/xargs
> is quite excessive (one cp(1) invocation per file) and unsafe (unusual
filenames
> would break the construct).

About unsafe filenames. If you talk about this:

find . -type f | xargs -IX -n1 sh -c "cp -f X $IMGDIR_DST/X || exit 255"

I understand how unsafe filenames can cause a wrond behaviour. But here(if
-F/-S would be implemented):

find . -type f | xargs -F -IX -n1 cp -f X $IMGDIR_DST/X

I can't find any problem with unsafe filenames. Am i wrong?

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #61009] xargs need option to immediately stop on command fail

2021-08-05 Thread anonymous

Follow-up Comment #2, bug #61009 (project findutils):

[comment #1 comment #1:]
> POSIX [1] specifies the following conditions when xargs shall terminate
processing:
> * child exits with 255,
> * child was killed by a signal, or
> * when reading the 'eofstr' string if the '-E eofstr' option is given, or
> * when regularly reaching EOF when reading from stdin.

POSIX standardize those features that are already implemented by somebody
;-).

> Still, our xargs might implement such an option as a GNU extension.

That's great!

> I would recommend a long-option like --stop-on-error for such an extension.

This would be great if we have short option in addition to long, because this
is a normal(usual) case when we want to early stop on error, i think.

> Why did you propose '-F'?  Is there any precedence in other xargs
implementations?

No. This is my invention just for demonstration :-). I think about it like -F
= --fail-on-error. But -S for --stop-on-error will be good too.

> Regarding the examples - and just to be sure:
> I assume that the reproducer with 'cp' was just a simplification to
demonstrate your actual use case, right?

Yes. You are right.



___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #61009] xargs need option to immediately stop on command fail

2021-08-04 Thread anonymous

URL:
  

 Summary: xargs need option to immediately stop on command
fail
 Project: findutils
Submitted by: None
Submitted on: Wed 04 Aug 2021 08:50:38 AM UTC
Category: xargs
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: 
Originator Email: lego12...@yandex.ru
 Open/Closed: Open
 Release: None
 Discussion Lock: Any
   Fixed Release: None

___

Details:

Hello.

If we want xargs stop on command fail we need to do the next complex construct
with sh:

xargs -IX -n1 sh -c "cp -f X $IMGDIR_DST/X || exit 255"

instead of simply:

xargs -F -IX -n1 cp -f X $IMGDIR_DST/X

(imagine the -F turns on stop on command fail). This is simpler and less error
prone.

Thus, we can do in our scripts:

find . -type f | xargs -F -IX -n1 cp -f X $IMGDIR_DST/X || exit 1

Instead of more complex and error prone:

find . -type f | xargs -IX -n1 sh -c "cp -f X $IMGDIR_DST/X || exit 255" ||
exit 1




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #60822] Missing "@" in worked example

2021-06-25 Thread anonymous

URL:
  

 Summary: Missing "@" in worked example
 Project: findutils
Submitted by: None
Submitted on: Fri 25 Jun 2021 11:20:07 AM UTC
Category: documentation
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: 
Originator Email: 
 Open/Closed: Open
 Release: None
 Discussion Lock: Any
   Fixed Release: None

___

Details:

The "Using -printf and sort to compare timestamps" example has this example
code:

newest=$(find subdir -newer timestamp -printf "%A%p\n" |
   sort -n |
   tail -n1 |
   cut -d: -f2- )
touch -r "${newest:-timestamp}" timestamp

which is missing an "@" character after the "%A".

Definitely missing in version 4.8.0 which I've got installed. Also missing at
https://www.gnu.org/software/findutils/manual/html_node/find_html/Updating-A-Timestamp-File.html#Using-_002dprintf-and-sort-to-compare-timestamps,
so I assume it's not fixed in the most recent release.




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #60823] Missing "@" in worked example

2021-06-25 Thread anonymous

URL:
  

 Summary: Missing "@" in worked example
 Project: findutils
Submitted by: None
Submitted on: Fri 25 Jun 2021 11:20:41 AM UTC
Category: documentation
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: 
Originator Email: rswarbr...@lowrisc.org
 Open/Closed: Open
 Release: None
 Discussion Lock: Any
   Fixed Release: None

___

Details:

The "Using -printf and sort to compare timestamps" example has this example
code:

newest=$(find subdir -newer timestamp -printf "%A%p\n" |
   sort -n |
   tail -n1 |
   cut -d: -f2- )
touch -r "${newest:-timestamp}" timestamp

which is missing an "@" character after the "%A".

Definitely missing in version 4.8.0 which I've got installed. Also missing at
https://www.gnu.org/software/findutils/manual/html_node/find_html/Updating-A-Timestamp-File.html#Using-_002dprintf-and-sort-to-compare-timestamps,
so I assume it's not fixed in the most recent release.




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #59766] printf %i doesn't show same result in all situations

2020-12-27 Thread anonymous

Follow-up Comment #3, bug #59766 (project findutils):

well I've guessed, that this may a performance-problem, if stat() is called
every time, so I would be completely satisfied with a new option, which let me
force stat()-calls in certain situations.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #59766] printf %i doesn't show same result in all situations

2020-12-26 Thread anonymous

Follow-up Comment #1, bug #59766 (project findutils):

addon: 

find -inum ###

also uses the inodes from getdent() for comparison...

this also should be checked against the inodes from stat()


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #59083] enhancement: find -D exec

2020-09-18 Thread anonymous

Follow-up Comment #2, bug #59083 (project findutils):

Thanks, that certainly helps for the original grep example. Interesting to see
the argc count varying across a large run, e.g.

$ ./find -D exec /usr -exec echo {} + |& grep 'DebugExec.*argc=' | cut -c1-41
| head
DebugExec: launching process (argc=4263):
DebugExec: launching process (argc=3119):
DebugExec: launching process (argc=2207):
DebugExec: launching process (argc=1546):
DebugExec: launching process (argc=1733):
DebugExec: launching process (argc=2103):
DebugExec: launching process (argc=1652):
DebugExec: launching process (argc=1774):
DebugExec: launching process (argc=1526):
DebugExec: launching process (argc=1761):


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #59083] enhancement: find -D exec

2020-09-08 Thread anonymous

URL:
  

 Summary: enhancement: find -D exec
 Project: findutils
Submitted by: None
Submitted on: Tue 08 Sep 2020 09:07:23 PM UTC
Category: find
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: Philip Rowlands
Originator Email: phr+findut...@dimebar.com
 Open/Closed: Open
 Release: None
 Discussion Lock: Any
   Fixed Release: None

___

Details:

The snippet which brought this to my attention is


if find -name '*.txt' -exec grep somestring {} +; then echo somestring found;
fi


which is fragile because, depending how many greps are launched, some may find
a match (and exit 0), some may not (and exit 1), and find reasonably takes a
worst-case exit status from the commands exec'd.

What made this harder to debug was the lack of useful output from find -D
exec; the only output controlled by DebugExec is from
show_outstanding_execdirs().

It seems launch() is the right place to add more debug output, perhaps before
fflush() / after waitpid().

For example "launching 'grep' with 4000 pathnames" and "process 'grep' exited
with status 1" messages in the debug output would make it much clearer.

If there's support for this, I can try to craft a patch.




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #59012] find examples wrong in man page

2020-08-25 Thread anonymous

URL:
  

 Summary: find examples wrong in man page
 Project: findutils
Submitted by: None
Submitted on: Tue 25 Aug 2020 09:33:26 PM UTC
Category: documentation
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: Nils
Originator Email: bugs2...@snailsen.de
 Open/Closed: Open
 Release: 4.6.0
 Discussion Lock: Any
   Fixed Release: None

___

Details:

> find repo/ \( -exec test -d '{}'/.svn \; -or \
> -exec test -d {}/.git \; -or -exec test -d {}/CVS \; \) \
> -print -prune
>
>Given  the  following  directory of projects and their associated SCM
administrative directories, perform an efficient search for the projects'
roots:
>
> repo/project1/CVS
> repo/gnu/project2/.svn
> repo/gnu/project3/.svn
> repo/gnu/project3/src/.svn
> repo/project4/.git
>
>In this example, -prune prevents unnecessary descent into directories that
have already been discovered (for  example  we do not  search project3/src
because we already found >project3/.svn), but ensures sibling directories
(project2 and >project3) are found.


The above example from the find man page (from find (GNU findutils)
4.6.0.225-235f) is not producing the listed output. 
As the matching is performed on the directory name plus an extention using
-exec test '{}'/.svn the matching directory would be e.g. repo/project2 which
is giving a positive test on execution of test repo/project2/.svn. Therefore
find is printing only "repo/project2" (and not "repo/project2/.svn")

As -prune is used project3 is matching and therefore no descending into it
will be done. Based on this the sub folder src inside project3 can never be
found even though it also conatins a .svn folder.

The example is inconsitent in using quotations for the -exec action. in the
first exec action '{}' is used while in the second and third just {} is used.


Giving the folloing driectory tree:
./gnu
./gnu/project2
./gnu/project2/.svn
./gnu/project2/.svn/foobar
./gnu/project2/.svn/pristine
./gnu/project2/.svn/wc.db
./gnu/project3
./gnu/project3/src
./gnu/project3/src/debug_out
./gnu/project3/src/.svn
./gnu/project3/src/.svn/pristine
./gnu/project3/src/.svn/wc.db
./gnu/project3/.svn
./gnu/project3/.svn/barfoo
./gnu/project3/.svn/wc.db
./project1
./project1/CVS
./project1/CVS/foo
./project1/CVS/fooabr
./project4
./project4/foobar
./project4/.git
./project4/.git/bakcup
./project4/.git/wb.git
./project4/test

The output of the example find produces the follwoing (expected) output which
is different from the documented example:

user@host:~/repo$ find ./ \( -exec test -d '{}'/.svn \; -or -exec test -d
'{}'/.git \; -or -exec test -d '{}'/CVS \; \) -print -prune
./project4
./project1
./gnu/project3
./gnu/project2






___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #59012] find examples wrong in man page

2020-08-25 Thread anonymous

Follow-up Comment #1, bug #59012 (project findutils):

Well, after reading it a second time, the result is not that wrong as
expected. Maybe its a little bit confusing that the result is not printed
instad just one sentence explains what happens. To make the example more clear
maybe the exact output should be written.

Nevertheless a consitent quoting of {} should be used.



___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #58149] Whitespace parsing differs with and without -i

2020-04-10 Thread anonymous

Follow-up Comment #2, bug #58149 (project findutils):

[comment #1 comment #1:]
> That is documented behavior.

I see that in `man`, but not with `--help` which doesn't hint to that critical
second part:


  -I R same as --replace=R
  -i, --replace[=R]replace R in INITIAL-ARGS with names read
 from standard input; if R is unspecified,
 assume {}


Can that be added on to the `--help` output? Something like "Also changes
delimiter from any whitespace to only newline character".

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #58149] Whitespace parsing differs with and without -i

2020-04-09 Thread anonymous

URL:
  

 Summary: Whitespace parsing differs with and without -i
 Project: findutils
Submitted by: None
Submitted on: Thu 09 Apr 2020 05:55:59 PM UTC
Category: xargs
Severity: 3 - Normal
  Item Group: Wrong result
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: Ryan Moore
Originator Email: rmo...@aurora.tech
 Open/Closed: Open
 Release: 4.7.0
 Discussion Lock: Any
   Fixed Release: None

___

Details:

I would expect this to use -n1 to separate the whitespace-delimited parameters
"a" and "b" and "c" to print 3 separate lines:


root@rmoore:~# echo "a b c" | xargs -n1 -i{} echo foo {}
foo a b c


If I manually specify a space as the delimiter, it works as expected (and
gives an extra CR with the last line, since it's now "c\n"):


root@rmoore:~# echo "a b c" | xargs -d\  -n1 -i{} echo foo {}
foo a
foo b
foo c




If I run without -I{} as a substitution, it works as expected (and prints {}
explicitly):

root@rmoore:~# echo "a b c" | xargs -n1 echo foo {}
foo {} a
foo {} b
foo {} c



Version info, from Ubuntu 16.04 (also confirmed on 18.04):

root@rmoore:~# xargs --version
xargs (GNU findutils) 4.7.0-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Eric B. Decker, James Youngman, and Kevin Dalley.






___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #57839] Remove/fix getdtablesize tests

2020-02-17 Thread anonymous

URL:
  

 Summary: Remove/fix getdtablesize tests
 Project: findutils
Submitted by: None
Submitted on: Mon 17 Feb 2020 05:47:01 PM UTC
Category: None
Severity: 3 - Normal
  Item Group: Test suite failure
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: Truls Asheim
Originator Email: tr...@asheim.dk
 Open/Closed: Open
 Release: None
 Discussion Lock: Any
   Fixed Release: None

___

Details:

Hi,

I recently experienced a test failure when compiling findutils 4.7.0 using nix
on an older Centos 6 (kernel 2.6.32) system. Since nix requires tests to be
successful, the compilation failed following the failure of the gnulib tests
which relies on the getdtablesize function: test-getdtablesize and test-dup2
[1].

The opinion of the nix maintainer is that these tests are irrelevant for the
features provided by findutils and that they therefore should be removed. See
[2] for more details.

If you agree with this assessment, is it possible for you to remove/fix the
aforementioned tests?

[1] https://github.com/NixOS/nixpkgs/issues/80352
[2] https://github.com/NixOS/nixpkgs/pull/46669




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #57775] Typo in find manpage

2020-02-08 Thread anonymous

URL:
  

 Summary: Typo in find manpage
 Project: findutils
Submitted by: None
Submitted on: Sun 09 Feb 2020 07:54:01 AM UTC
Category: find
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: Hugo Gabriel Eyherabide
Originator Email: hugogabriel.eyherab...@gmail.com
 Open/Closed: Open
 Release: 4.7.0
 Discussion Lock: Any
   Fixed Release: None

___

Details:

FIND VERSION: find (GNU findutils) 4.7.0-git
COMMAND USED: man find

The man page says 

  "-P ... information a file ..." 

instead of 

  "-P ... information about a files ..." 

or as in the -L option

  "-P ... information about files ...".






___

File Attachments:


---
Date: Sun 09 Feb 2020 07:54:01 AM UTC  Name: find.1.patch  Size: 436B   By:
None



___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #57461] Configure leaves directory trees that cannot be removed on PowerPC Mac OS X 10.5.8, Leopard

2019-12-22 Thread anonymous

URL:
  

 Summary: Configure leaves directory trees that cannot be
removed on PowerPC Mac OS X 10.5.8, Leopard
 Project: findutils
Submitted by: None
Submitted on: Sun 22 Dec 2019 12:37:32 PM UTC
Category: None
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: Peter Dyballa
Originator Email: peter_dyba...@freenet.de
 Open/Closed: Open
 Discussion Lock: Any
 Release: 4.7.0
   Fixed Release: None

___

Details:

Hello!

These two directories are created:

  -rwxr-xr-x  1 macports admin   94603 22. Dez 13:22 config.status
  drwx--  3 macports admin 102 22. Dez 13:20 confdir-14B---
  drwx--  3 macports admin 102 22. Dez 13:20 confdir3

Configure then fails to remove them:

config.status: creating po/POTFILES
config.status: creating po/Makefile
rm:
confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3:
No space left on device
rm:
confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3:
Directory not empty
rm:
confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3:
Directory not empty
rm:
confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3:
Directory not empty
rm:

[bug #57025] find -mtime will ignore large files

2019-10-11 Thread anonymous

Follow-up Comment #4, bug #57025 (project findutils):

Ok, I believed it's my fault...

Quote from man page:
*-atime n*
  File  was  last  accessed  n*24  hours  ago.   When find figures
out how many 24-hour periods ago the file was last
  accessed, any fractional part is ignored, so to match -atime +1,
a file has to have been accessed at least two days
  ago.

*-mtime n*
  File's data was last modified n*24 hours ago.  See the comments
for -atime to understand how rounding  affects  the
  interpretation of file modification times.

So is that means:
*"+n" >> n* n*24 hours beyond (not include n*24)
*"n" == n* n*24 hours equal
*"-n" << n* n*24 hours within (not include n*24)

I believe the man page doc could be more enriched.
Thanks a lot!

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #57025] find -mtime will ignore large files

2019-10-10 Thread anonymous

Follow-up Comment #2, bug #57025 (project findutils):

find *.part -mtime 4 -type f -ls
 18483504 128096 -rw-rw-r--   1 threewaters threewaters 201725004 Oct  6 15:12
007.part
 18486530  56768 -rw-rw-r--   1 threewaters threewaters 559563054 Oct  6 10:17
1051.part
 18487093  29816 -rw-rw-r--   1 threewaters threewaters 200162867 Oct  6 15:32
1052.part
 18487245  27636 -rw-rw-r--   1 threewaters threewaters 127759980 Oct  7 00:54
1099.part
 18486787  29656 -rw-rw-r--   1 threewaters threewaters 559432108 Oct  7 00:41
1137.part
 18487095   8388 -rw-rw-r--   1 threewaters threewaters 302045139 Oct  7 07:29
1174.part
 18487625   6032 -rw-rw-r--   1 threewaters threewaters 488273477 Oct  7 05:28
1191.part
 18487386860 -rw-rw-r--   1 threewaters threewaters 4524400640 Oct  7
05:38 1267.part
 18487838   9536 -rw-rw-r--   1 threewaters threewaters  744177664 Oct  6
22:17 1309.part
 18487952   2840 -rw-rw-r--   1 threewaters threewaters2908160 Oct  7
06:30 1316.part
 18487587   1524 -rw-rw-r--   1 threewaters threewaters 2151446460 Oct  6
23:48 1336.part
 18488018  35644 -rw-rw-r--   1 threewaters threewaters  466064767 Oct  6
20:51 1373.part
 18488067 114044 -rw-rw-r--   1 threewaters threewaters  379431454 Oct  6
20:51 1470.part
 18488297  44584 -rw-rw-r--   1 threewaters threewaters  713529344 Oct  6
12:23 1479.part
 18488810268 -rw-rw-r--   1 threewaters threewaters   97550787 Oct  7
05:29 1584.part
 18488862   4532 -rw-rw-r--   1 threewaters threewaters4640543 Oct  6
23:29 1621.part
 18488879  44252 -rw-rw-r--   1 threewaters threewaters  476672000 Oct  6
18:22 1678.part
 18488860 415732 -rw-rw-r--   1 threewaters threewaters  470289854 Oct  6
20:44 1709.part
 18488269  47228 -rw-rw-r--   1 threewaters threewaters  236464361 Oct  7
01:09 1711.part
 18484294   4884 -rw-rw-r--   1 threewaters threewaters4998254 Oct  6
11:08 191.part
 18489933   9840 -rw-rw-r--   1 threewaters threewaters   39258399 Oct  7
00:03 2127.part
 18491758 115952 -rw-rw-r--   1 threewaters threewaters  517317062 Oct  7
01:00 2576.part
 18491534 105516 -rw-rw-r--   1 threewaters threewaters  516995268 Oct  7
01:35 2771.part
 18484299  39436 -rw-rw-r--   1 threewaters threewaters  138872317 Oct  6
16:21 278.part
 18492401  18884 -rw-rw-r--   1 threewaters threewaters  306184192 Oct  6
13:39 2914.part
 18492817 105288 -rw-rw-r--   1 threewaters threewaters 2055536640 Oct  6
15:14 3181.part
 18492852 164076 -rw-rw-r--   1 threewaters threewaters  305135616 Oct  6
14:42 3192.part
 18483824 431212 -rw-rw-r--   1 threewaters threewaters  548852712 Oct  6
23:28 334.part
 18484469  57228 -rw-rw-r--   1 threewaters threewaters  362603384 Oct  7
07:30 343.part
 18494318  54004 -rw-rw-r--   1 threewaters threewaters 4652828672 Oct  6
14:08 3524.part
 18494898   5720 -rw-rw-r--   1 threewaters threewaters   35041280 Oct  7
03:05 3720.part
 18495057  10572 -rw-rw-r--   1 threewaters threewaters  949069824 Oct  6
21:52 3771.part
 18484464 171660 -rw-rw-r--   1 threewaters threewaters  424285823 Oct  7
03:49 395.part
 18495784  26552 -rw-rw-r--   1 threewaters threewaters  105987752 Oct  7
01:35 4004.part
 18484394  93628 -rw-rw-r--   1 threewaters threewaters 1026482143 Oct  6
22:18 501.part
 18485348  81056 -rw-rw-r--   1 threewaters threewaters  276438890 Oct  7
00:16 520.part
 18484467  34392 -rw-rw-r--   1 threewaters threewaters  233813092 Oct  7
01:40 522.part
 18484593 638436 -rw-rw-r--   1 threewaters threewaters  876685778 Oct  7
08:16 564.part
 18485540 165796 -rw-rw-r--   1 threewaters threewaters  329283492 Oct  7
02:06 584.part
 18485061 421608 -rw-rw-r--   1 threewaters threewaters 1810177956 Oct  7
08:36 709.part
 18486160   3044 -rw-rw-r--   1 threewaters threewaters   31101560 Oct  6
22:00 782.part

$ ls -t -l|tail -41
-rw-rw-r-- 1 threewaters threewaters  29 Oct  6 23:49
334.part.met.seeds
-rw-rw-r-- 1 threewaters threewaters  29 Oct  6 23:49
4004.part.met.seeds
-rw-rw-r-- 1 threewaters threewaters  2151446460 Oct  6 23:48 1336.part
-rw-rw-r-- 1 threewaters threewaters 4640543 Oct  6 23:29 1621.part
-rw-rw-r-- 1 threewaters threewaters   548852712 Oct  6 23:28 334.part
-rw-rw-r-- 1 threewaters threewaters  1026482143 Oct  6 22:18 501.part
-rw-rw-r-- 1 threewaters threewaters   744177664 Oct  6 22:17 1309.part
-rw-rw-r-- 1 threewaters threewaters31101560 Oct  6 22:00 782.part
-rw-rw-r-- 1 threewaters threewaters   949069824 Oct  6 21:52 3771.part
-rw-rw-r-- 1 threewaters threewaters   466064767 Oct  6 20:51 1373.part
-rw-rw-r-- 1 threewaters threewaters   379431454 Oct  6 20:51 1470.part
-rw-rw-r-- 1 threewaters threewaters   470289854 Oct  6 20:44 1709.part
-rw-rw-r-- 1 threewaters threewaters  52 Oct  6 20:38
1709.part.met.seeds
-rw-rw-r-- 1 threewaters threewaters  29 Oct  6 20:38
1136.part.met.seeds
-rw-rw-r-- 1 threewaters threewaters  29 Oct  6 20:38
2462.part.met.seeds
-rw-rw-r-- 1 threewaters threewaters  52 Oct  6 19:34
1470.part.met.seeds
-rw-rw-r--

[bug #57025] find -mtime will ignore large files

2019-10-09 Thread anonymous

URL:
  

 Summary: find -mtime will ignore large files
 Project: findutils
Submitted by: None
Submitted on: Wed 09 Oct 2019 12:14:44 PM UTC
Category: find
Severity: 3 - Normal
  Item Group: Wrong result
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: Threewaters
Originator Email: olivelatteb...@riseup.net
 Open/Closed: Open
 Discussion Lock: Any
 Release: 4.6.0
   Fixed Release: 4.6.0

___

Details:

As I tested -mtime function, it ignore any -mtime meet files larger than
3.9GiB (the smallest one I saw).
System: Ubuntu Server 18.04.3 LTS




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #45930] -ignore_readdir_race ineffective in find 4.5.11 and 4.5.14

2019-06-06 Thread anonymous

Follow-up Comment #3, bug #45930 (project findutils):

Hello,

I can confirm "-ignore_readdir_race" not working:
- On CentOS-7 with find v4.5.11
- On OpenSuse with find v4.5.12

EXAMPLE:
root|dev-opensuse-server01|10:57|0|~: find /proc -ignore_readdir_race
-maxdepth 3 -path "/proc/[0-9]*/fd/*" -type l \( -lname '/dev/shm/*' -prune -o
-lname '*(deleted)' -printf '"%p (absent) (%Y)"\n' -o -printf '"%p (present)
(%Y)"\n' \) > /dev/null; echo -e "RETVALUE: ${?}"
find: ‘/proc/4063’: No such file or directory
find: ‘/proc/4064’: No such file or directory
find: ‘/proc/4069’: No such file or directory
find: ‘/proc/4072’: No such file or directory
RETVALUE: 1

EXPECTED RESULT:
- No error about missing directories/files
- Return value of zero (0)

Either it is broken or I misunderstood the purpose of this feature...

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #56198] Typo in xargs.1: 'ouptut'

2019-04-23 Thread anonymous

URL:
  

 Summary: Typo in xargs.1: 'ouptut'
 Project: findutils
Submitted by: None
Submitted on: Tue 23 Apr 2019 01:17:20 PM UTC
Category: xargs
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: Andy
Originator Email: a...@adpx.net
 Open/Closed: Open
 Discussion Lock: Any
 Release: None
   Fixed Release: None

___

Details:

Context is the "Please note" section in the discussion of the -P option:

"For example, if more than one of them tries to print to stdout, the ouptut
will be produced in an indeterminate order (and very likely mixed up) unless
the processes collaborate in some way to prevent this."

Thanks.




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #55190] xargs documentation is confusing about the usage of -i and -I (capital i), and doesn't have any examples on this options

2018-12-09 Thread anonymous

URL:
  

 Summary: xargs documentation is confusing about the usage of
-i and -I (capital i), and doesn't have any examples on this options
 Project: findutils
Submitted by: None
Submitted on: Mon 10 Dec 2018 03:47:22 AM UTC
Category: xargs
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: lockywolf
Originator Email: lockyw...@gmail.com
 Open/Closed: Open
 Discussion Lock: Any
 Release: 4.6.0
   Fixed Release: None

___

Details:

These are actually two different questions, but I find them often found
together.

1)-I option is called 'replace-str', which to me is particularly confusing,
because by 'replace' I usually mean some sort of post-processing of my data.
The wording convenient to me (and I suspect, to many other people) would be
'substitute'.

Initially, I understood this option as if it replaces the input to xargs with
itself. That is, for the command:

AAA.txt:
line

BBB.txt:
line2

cat AAA.txt |  xargs -I {} echo `cat BBB.txt' 

I expected the final commannd to be

echo {}2

But the actual command is:

echo line2 line

2)There are no examples in the info xargs which could debunk my
misunderstanding.






___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #46815] problem when testing file size

2018-09-06 Thread anonymous

Follow-up Comment #7, bug #46815 (project findutils):

I'm a decades-long professional programmer, and even I just found the present
behavior of rounding up very surprising, which is why I'm here posting.  If I
can get confused, an ordinary user has no chance, and may well miss the fact
that the data they thought they might see is simply missing from the output. 
If the semantics of "-size -1M" are to be preserved as-is, I believe it's
definitely worthwhile having a non-surprising alternative.  Nobody wants to
type "-size -1048576c" instead of "-size -1M".

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #54591] gnulib components in findutils do not compile with glibc 2.28

2018-08-29 Thread anonymous

Follow-up Comment #4, bug #54591 (project findutils):

Thanks for the pointers to specific commits!

Perhaps it would make sense to make a new release soon?

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #54591] gnulib components in findutils do not compile with glibc 2.28

2018-08-29 Thread anonymous

URL:
  

 Summary: gnulib components in findutils do not compile with
glibc 2.28
 Project: findutils
Submitted by: None
Submitted on: Wed 29 Aug 2018 12:33:36 PM UTC
Category: None
Severity: 3 - Normal
  Item Group: Compilation Failure
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: 
Originator Email: bneume...@gmail.com
 Open/Closed: Open
 Discussion Lock: Any
 Release: 4.6.0
   Fixed Release: None

___

Details:

Glibc 2.28 removes some obsolete functions that are used by gnulib components
included in the findutils source. This causes build failures:

freadahead.c: In function 'freadahead':
freadahead.c:92:3: error: #error "Please port gnulib freadahead.c to your
platform! Look at the definition of fflush, fread, ungetc on your system, then
report this to bug-gnulib."
  #error "Please port gnulib freadahead.c to your platform! Look at the
definition of fflush, fread, ungetc on your system, then report this to
bug-gnulib."

Copying the current gnulib version of freadahead.{c,h} to gl/lib corrects that
build failure.




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #54509] `-execdir command ;` returns 0 when it should not

2018-08-13 Thread anonymous

URL:
  

 Summary: `-execdir command ;` returns 0 when it should not
 Project: findutils
Submitted by: None
Submitted on: Mon 13 Aug 2018 08:23:38 PM UTC
Category: find
Severity: 3 - Normal
  Item Group: Wrong result
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: segfault
Originator Email: segfa...@riseup.net
 Open/Closed: Open
 Discussion Lock: Any
 Release: None
   Fixed Release: None

___

Details:

This affects find 4.7.0-git on Debian Sid (unstable), but I couldn't select
that version in the bug submit form, because it only lists releases up to
4.6.0.

The man page says the following about `-execdir command ;`:

"If any invocation returns a non-zero value as exit status, then find returns
a non-zero exitstatus."

This doesn't seem to be correct, for example the following returns 0:


mkdir foo; find foo -execdir false \;





___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #52890] `find --name` ignores files with non-printable character in the filename

2018-01-14 Thread anonymous

Follow-up Comment #2, bug #52890 (project findutils):

I give up :-(

asterisk ERR asterisk

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[bug #52890] `find --name` ignores files with non-printable character in the filename

2018-01-14 Thread anonymous

Follow-up Comment #1, bug #52890 (project findutils):

Sorry markup has rotten the report  - it shoud be:
`find -name '*ERR*' '

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[bug #52890] `find --name` ignores files with non-printable character in the filename

2018-01-14 Thread anonymous

URL:
  

 Summary:  `find --name` ignores files with non-printable
character in the filename
 Project: findutils
Submitted by: None
Submitted on: Sun 14 Jan 2018 11:35:30 PM UTC
Category: find
Severity: 3 - Normal
  Item Group: Wrong result
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: H.-Dirk Schmitt
Originator Email: d...@computer42.org
 Open/Closed: Open
 Discussion Lock: Any
 Release: 4.6.0
   Fixed Release: None

___

Details:

See also https://bugs.launchpad.net/ubuntu/+source/findutils/+bug/1742011

Affected:  4.6.0 in xenial, artful, bionic
bionic version is 4.6.0+git+20170828


Simple test case:
-
```
touch $(echo -e ERR'\0303'OR )
touch NON_ERROR
find . -name "*ERR*"
```

Result is that only the file NON_ERROR is shown and the file with the
non-printable character ERR?OR is missing.

`find .` (without -name) show both files.




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[bug #52592] Documentation for 'find' unclear on default regex type

2017-12-05 Thread anonymous

URL:
  

 Summary: Documentation for 'find' unclear on default regex
type
 Project: findutils
Submitted by: None
Submitted on: Tue 05 Dec 2017 08:26:27 PM UTC
Category: documentation
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: 
Originator Email: itvi...@iki.fi
 Open/Closed: Open
 Discussion Lock: Any
 Release: None
   Fixed Release: None

___

Details:

Section 2.1.2 Full Name Patterns [1] states under '-regex' that the default
regex dialect is "POSIX basic regular expressions", and just below, under
'-regextype' it's stated that the default is "Regular expressions compatible
with GNU Emacs".  (They differ in at least the support for '\{n,m\}' and '?')

The web documentation [2] still refers to  'posix-basic' regexes as synonym
for the undocumented 'ed', but that seems to be fixed in git.


[1]
https://www.gnu.org/software/findutils/manual/html_node/find_html/Full-Name-Patterns.html

[2]
https://www.gnu.org/software/findutils/manual/html_node/find_html/Regular-Expressions.html#Regular-Expressions





___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[bug #52409] `find -print0 -name ...` ignores `-name ...`

2017-11-14 Thread anonymous

Follow-up Comment #2, bug #52409 (project findutils):

Ah makes sense!  Thanks for the thorough explanation -- didn't realize `print`
was considered a predicate and thought it just controlled the final output.

This can be closed -- apparently I can't do that since I posted anonymously.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[bug #52220] 'find -D' segfaults

2017-10-12 Thread anonymous

URL:
  

 Summary: 'find -D' segfaults
 Project: findutils
Submitted by: None
Submitted on: Thu 12 Oct 2017 08:30:12 PM UTC
Category: find
Severity: 3 - Normal
  Item Group: Wrong result
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: Felix
Originator Email: fl...@bu.edu
 Open/Closed: Open
 Discussion Lock: Any
 Release: 4.6.0
   Fixed Release: 4.6.0

___

Details:

Hello,

1. the version of findutils you are using 
version 4.6.0

3. the exact command line that you used 
find -D

4. what you expected to happen 
I expected to get "find: '-D' must take an argument" or the help version of
-D.

5. precisely what did happen. 
segfault

Thank you for your time.




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[bug #52129] find lacks "-older" option symmetric to "-newer"

2017-09-27 Thread anonymous

URL:
  

 Summary: find lacks "-older" option symmetric to "-newer"
 Project: findutils
Submitted by: None
Submitted on: Wed 27 Sep 2017 10:57:39 PM UTC
Category: None
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: 
Originator Email: vo...@volth.com
 Open/Closed: Open
 Discussion Lock: Any
 Release: None
   Fixed Release: None

___

Details:

find lacks "-older" option symmetric to "-newer"

It is not the same as "-not -older", especially on the OSes without
microsecond file times (such as Darwin) where equal file times are not
seldom.

See the discussion here: https://github.com/NixOS/nixpkgs/pull/29825




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[bug #51711] non-helping error output with find

2017-09-14 Thread anonymous

Follow-up Comment #10, bug #51711 (project findutils):

thank you berny.
and for the other point: 
is it so obvious, that '-name' only takes one argument? Because, as I pointed
out several times it is not pointed out either in the "info"-file nor in the
"man"-file.
Instead, I found an plural 's' in the 'info find'-document, node 'Primary
Index'.
greetings,
kalle

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[bug #51711] non-helping error output with find

2017-08-29 Thread anonymous

Follow-up Comment #8, bug #51711 (project findutils):



>> -the number of acceptable -name arguments
>
> I tried to find a place both in find's manpage and the Texinfo
> manual (in latest Git), but didn't find an ambiguous place where
> I could read that -name would accept more than 1 argument.
> Would you please point to the relevant place?

As I pointed out in comment#5:
"I didn't find the place, where it does. What I found in man find was
'-name pattern' instead of 'patterns', but this is not a clear statement
imo. But also: in 'info find', node 'Primary Index' I fond '-name Base
name patterns' with s! "

I argued, that it is not written, that it accepts only one argument,
while you argue, that it is not written, that it accepts more than 1
argument. Is this a standard (that normally there is only one argument,
if not specified else) or why do you assume so? Then I would be sorry
for having taking your time because of this.

> -the insufficient non-bug explananation in man find [...]
> __^
> sorry, I don't understand what you mean by this.
> Would you please point to a place there you think is not
> sufficient (and suggest a better wording, ideally as a Git
> patch)?

I meant, that in "man find" the part "non-bug" assumes, that "of course"
the there given example will not work. No more explanation why. This is
not enough.

have a nice day,
kalle



___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[bug #51711] non-helping error output with find

2017-08-28 Thread anonymous

Follow-up Comment #6, bug #51711 (project findutils):

I think the discussion missed a bit what I pointed on:
-the non-helping error message
-the number of acceptable -name arguments
-the insufficient non-bug explananation in man find, in relationship to the
number of -name arguments

-shell-globbing and good quoting wasn't the point. I also pointed this out by
quoting the man find -non-bug.

kalle

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[bug #51711] non-helping error output with find

2017-08-28 Thread anonymous

Follow-up Comment #5, bug #51711 (project findutils):

Dale wrote :
As far as I can tell, the error message means, Syntactically, this is a
situation where a predicate must occur, but this argument is not a predicate.
It looks like what would happen if you tried to specify a directory, but
didn't put it in front.

I don't understand what you want to say. I'm not totally sure about the term
predicate: is -name a predicate? Where must a predicate occur,
where it doesn't in my example? For the second and third search pattern?

Dale wrote:
You write, How could one know, that options like -name can
only have one name? Well, the documentation says that -name can have
only one argument. 

I didn't find the place, where it does. What I found in man find was '-name
pattern' instead of 'patterns', but this is not a clear statement imo. But
also: in 'info find', node 'Primary Index' I fond '-name  Base name patterns'
with s!

Dale wrote:
The problem is amplified by the fact that what you wrote (.c) isn't what find
saw ... but that is actually a central feature of all Unx-style shells -- the
expansion of non-escaped wildcards (but only when they match at least one
existing file). Like smoking a cigar in a fireworks store, it works fine as
long as you're constantly aware of it. 

I am aware of the problem of shell globbing but don't understand,what you
write. For example, that what you wrote (.c) isn't what find saw
was posted but not written by me, since I copied it from `man find'.

Dale wrote:
It would probably be better if the message didn't assume you were trying to
specify a directory but rather explained the problem literally. Something like
Argument 4 is 'fax2.c', following 'find . -name fax1.c', but it is not
used as an argument by the preceding predicate and directories to be searched
must appear before all predicates.

I had some problems understanding your sentence, but now I think I understand
it and agree with you.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[bug #51711] non-helping error output with find

2017-08-09 Thread anonymous

URL:
  

 Summary: non-helping error output with find
 Project: findutils
Submitted by: None
Submitted on: Wed 09 Aug 2017 11:12:29 PM UTC
Category: find
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: kalle
Originator Email: ka...@projektwerkstatt.de
 Open/Closed: Open
 Discussion Lock: Any
 Release: 4.4.2
   Fixed Release: None

___

Details:

akraum@akraumGI ~/Downloads $ ls
2017-07-29_Entwurf-Berichtsteil-Lebensstile.pdf
Ant Videos
blockadesw.jpg
blockbunt.jpg
DSC1316.jpg
faustklein.JPG
fax.pdf
notanugget.jpg
todktter1.jpg
todktter2.jpg
Widerstand-gegen-Wiesenhof-Part-1.pdf

akraum@akraumGI ~/Downloads $ LANG=C find . -name fax* bloc*
find: paths must precede expression: blockadesw.jpg
Usage: find [-H] [-L] [-P] [-Olevel] [-D help|tree|search|stat|rates|opt|exec]
[path...] [expression]

This was, what I got by typing two patterns into find-command. The answer
"paths must precede expression" didn't help me any further in understanding
the problem, since my path "." was preceding the expression "-name fax*
bloc*". 
How could one know, that options like "-name" can only have one name? 
Invoking "man find", it says at the bottom of the page:

"NON-BUGS
   $ find . -name *.c -print
   find: paths must precede expression
   Usage: find [-H] [-L] [-P] [-Olevel] [-D
help|tree|search|stat|rates|opt|exec] [path...] [expression]

   This happens because *.c has been expanded by the shell resulting in
find actually receiving a command line like this:

   find . -name bigram.c code.c frcode.c locate.c -print

   That command is of course not going to work.  Instead of doing things
this way, you should enclose the pattern in quotes or escape the wildcard:
   $ find . -name \*.c -print"

Here it assumes, that "of course" this will not work. No more explanation.
This is not enough.

Furthermore I don't understand why it gave out to me the file
"blockadesw.jpg". Obviously, it is the first file, to match a pattern.

My version is findutils 4.4.2

thanks,
kalle




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[bug #51345] find shows different results despite using same command

2017-06-30 Thread anonymous

URL:
  

 Summary: find shows different results despite using same
command
 Project: findutils
Submitted by: None
Submitted on: Fri 30 Jun 2017 07:45:45 AM UTC
Category: find
Severity: 3 - Normal
  Item Group: Wrong result
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: CyrusSh
Originator Email: sirus.shah...@gmail.com
 Open/Closed: Open
 Discussion Lock: Any
 Release: 4.4.2
   Fixed Release: None

___

Details:

During working on terminal I came to see a very strange behavior from find
command. This is the command I run along with its output:

root@localhost:/# find . -name "*systemd-resolved*"
./usr/share/man/man8/systemd-resolved.service.8.gz
./usr/share/man/man8/systemd-resolved.8.gz

The command returns 0 or two results like above. But if I run the command the
second time I get:

root@localhost:/# find . -name "*systemd-resolved*"
./usr/share/man/man8/systemd-resolved.service.8.gz
./usr/share/man/man8/systemd-resolved.8.gz
./lib/systemd/systemd-resolved
./lib/systemd/system/systemd-resolved.service.d
./lib/systemd/system/systemd-resolved.service

This means the first time, "find" does not actually find everything. Also this
only happens one time. Running the command next times shows correct output. I
checked this on some other systems with Debian OS installed. On those with
Kernel 4.9+ this exact problem always occurs but on systems with kernel 3.16
it doesn't happen.




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[bug #51069] find changes access time on directories

2017-05-19 Thread anonymous

URL:
  

 Summary: find changes access time on directories
 Project: findutils
Submitted by: None
Submitted on: Fri 19 May 2017 03:44:12 PM UTC
Category: find
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: Adesh
Originator Email: ade...@hotmail.com
 Open/Closed: Open
 Discussion Lock: Any
 Release: 4.6.0
   Fixed Release: None

___

Details:

Command line:
$ find . -xdev -mmin -5

Running the above command modifies the access time of all subdirectories under
current directory to current timestamp.
This looks like a bug to me since I do not expect 'find' to modify filesystem
as it is a utility to, you know, find files.

If this is not a bug please explain this behaviour, may be put an explanation
on the site or manual page.




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[bug #50758] Incorrect example in find.info docs for '-perm'

2017-04-08 Thread anonymous

URL:
  

 Summary: Incorrect example in find.info docs for '-perm'
 Project: findutils
Submitted by: None
Submitted on: Sat 08 Apr 2017 10:04:59 AM UTC
Category: documentation
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: Jacob Nevins
Originator Email: 0jacobnk@chiark.greenend.org.uk
 Open/Closed: Open
 Discussion Lock: Any
 Release: None
   Fixed Release: None

___

Details:

An example in find.info says


'-perm /022'
 Match files that are writable by either their owner or their
 group.  The files don't have to be writable by both the owner
 and group to be matched; either will do.


I think this is wrong; to match the text, I think the option would have to be
'-perm /220'. Other examples nearby are similar. Patch attached.



___

File Attachments:


---
Date: Sat 08 Apr 2017 10:04:59 AM UTC  Name: perm-example.patch  Size: 717B  
By: None
Patch against git 11a050cdb


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[bug #49466] xargs with 2>&1 returns error code in macOS 10.12

2017-02-06 Thread anonymous

Follow-up Comment #4, bug #49466 (project findutils):

This only appears on MaxOS 10.12.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[bug #48683] possible regression: "no such file or directory" error when directory is removed during execution

2016-08-02 Thread anonymous

URL:
  

 Summary: possible regression: "no such file or directory"
error when directory is removed during execution
 Project: findutils
Submitted by: None
Submitted on: Tue 02 Aug 2016 10:07:42 PM UTC
Category: find
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: 
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: 4.6.0
   Fixed Release: None

___

Details:

I am running versions from the Debian sid repositories.

$ apt show findutils
Package: findutils
Version: 4.6.0+git+20160703-2

$ find --version
find (GNU findutils) 4.7.0-git

I was attempting to clean multiple project directories with the same command,
effectively `rm -r` triggered by the presence of a certain file.

The `find` command will print a "no such file or directory" error when a
directory is removed while the command is running. Repro:

$ ls
$ mkdir -p a/b/c
$ touch a/b/test
$ ls -R
.:
a

./a:
b

./a/b:
c  test

./a/b/c:

$ find . -type f -name test -execdir rm -r c \;
find: ‘./a/b/c’: No such file or directory

$ echo $?
1

$ ls -R
.:
a

./a:
b

./a/b:
test

Expected behavior is identical results but no error, like in GNU find 4.4.2 on
Ubuntu.

Moreover, this error persists even in the presence of `-prune`, which strikes
me as unintuitive.

$ find . -type d -name c -prune -o -type f -name test -execdir rm -r c \;
find: ‘./a/b/c’: No such file or directory




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[bug #48169] find makes unnecessary syscalls

2016-06-07 Thread anonymous

URL:
  

 Summary: find makes unnecessary syscalls
 Project: findutils
Submitted by: None
Submitted on: Wed 08 Jun 2016 01:10:23 AM UTC
Category: find
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: Tavian Barnes
Originator Email: taviana...@tavianator.com
 Open/Closed: Open
 Discussion Lock: Any
 Release: 4.6.0
   Fixed Release: None

___

Details:

$ mkdir -p foo/bar/baz
$ strace find foo >/dev/null
...
newfstatat(5, "bar", {st_mode=S_IFDIR|0755, st_size=6, ...},
AT_SYMLINK_NOFOLLOW) = 0
fcntl(5, F_DUPFD_CLOEXEC, 0)= 4
openat(5, "bar", O_RDONLY|O_NOCTTY|O_NONBLOCK|O_DIRECTORY|O_NOFOLLOW) = 6
fcntl(6, F_GETFD)   = 0
fcntl(6, F_SETFD, FD_CLOEXEC)   = 0
fstat(6, {st_mode=S_IFDIR|0755, st_size=6, ...}) = 0
fcntl(6, F_GETFL)   = 0x38800 (flags
O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_NOFOLLOW)
fcntl(6, F_SETFD, FD_CLOEXEC)   = 0
newfstatat(5, "bar", {st_mode=S_IFDIR|0755, st_size=6, ...},
AT_SYMLINK_NOFOLLOW) = 0
fcntl(6, F_DUPFD, 3)= 7
fcntl(7, F_GETFD)   = 0
fcntl(7, F_SETFD, FD_CLOEXEC)   = 0
getdents(6, /* 3 entries */, 32768) = 72
getdents(6, /* 0 entries */, 32768) = 0
close(6)= 0
newfstatat(7, "baz", {st_mode=S_IFDIR|0755, st_size=0, ...},
AT_SYMLINK_NOFOLLOW) = 0
close(4)= 0
...

In particular:

- fd 4 is unused
- fcntl(6, F_SETFD, FD_CLOEXEC) happens twice, but could be totally avoided
with O_CLOEXEC (I suspect the second one is from within fdopendir() though)
- newfstatat(5, "bar", AT_SYMLINK_NOFOLLOW) happens twice
- fcntl(7, F_SETFD, FD_CLOEXEC) could be avoided if fcntl(6, F_DUPFD_CLOEXEC)
were used

This seems new with 4.6, at least 4.4 didn't do this.




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[bug #48030] -exec + does not pass all arguments for ceratin specific filename lengths

2016-05-26 Thread anonymous

URL:
  

 Summary: -exec + does not pass all arguments for ceratin
specific filename lengths
 Project: findutils
Submitted by: None
Submitted on: Thu 26 May 2016 04:07:06 PM UTC
Category: find
Severity: 3 - Normal
  Item Group: Wrong result
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: Joe Philip Ninan
Originator Email: india...@gmail.com
 Open/Closed: Open
 Discussion Lock: Any
 Release: 4.4.2
   Fixed Release: None

___

Details:

# 1. the version of findutils you are using 

We could reproduce this bug over many machines. All of them had find (GNU
findutils) 4.4.2

# 2. what you were trying to do

We were trying to execute a command using find's -exec comand + 

# 3. the exact command line that you used

find RashuBug -type f -exec md5sum {} + | wc -l

# 4. what you expected to happen

This directory RashuBug has 3719 files in it. So we expected 3719 lines of
output

# 5. precisely what did happen. 

The last file was not passed to md5sum command, and we got only 3718 lines as
output.

# 6. How to reproduce this bug

I am attaching RashuBug.tar.gz file.
Extract this tar.gz file to obtain a directory RashuBug/ containing 3719 empty
files. 

give the following command,
$ find RashuBug -type f -exec md5sum {} + | wc -l

You will get output 3718  (Because last file missing!)

$ cp  -r RashuBug RashuBugs
$ find RashuBugs -type f -exec md5sum {} + | wc -l

You will get all 3719 output this time.


# 7. Interesting Observations which might provide some clues.

As metione above, this bug disappears if the length of the directory name is
not exactly 8. For example if you rename this Directory as RashuBugs, it will
give all 3719 output.

This bug also disappears if the command, in this case md5sum is not exactly 6
characters.

For example, the following command works perfectly
$ find RashuBug -type f -exec echo {} + | tr ' ' '\n' | wc -l

But if you create a new command 6 characters long

$ ln -s /usr/bin/echo /usr/bin/echooo
$ find RashuBug -type f -exec echooo {} + | tr ' ' '\n' | wc -l

Then the bug re-appears, and it is missing the last file.

Hence the issue is not with md5sum command. For this very specific length of
filenames, directory name and command name, find command is dropping the last
file it finds while passing as arguments to the -exec command.

If you delete any one file from the the RashuBug directory, also this bug
disappears.
But if you add a new file by 
$ touch RashuBug/new.fits

Then the bug appears when the command it is excuting is 4 characters long.
So this bug is appearing for this specif length of filenames.

We discovered this bug, by accident, while dealing with large collection of
telescope observatory data.

The contents of the files are not important to reproduce this bug. Hence the
attached RashuBug.tar.gz contains empty files with exact filenames of our data
created using touch command!






___

File Attachments:


---
Date: Thu 26 May 2016 04:07:06 PM UTC  Name: RashuBug.tar.gz  Size: 44kB   By:
None
Filenames which can reproduce this bug


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[bug #47261] find produces two different results for the same command

2016-02-25 Thread anonymous

URL:
  

 Summary: find produces two different results for the same
command
 Project: findutils
Submitted by: None
Submitted on: Thu 25 Feb 2016 07:24:54 PM UTC
Category: find
Severity: 3 - Normal
  Item Group: Wrong result
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: Len Schulwitz
Originator Email: schulw...@gmail.com
 Open/Closed: Open
 Discussion Lock: Any
 Release: 4.4.2
   Fixed Release: None

___

Details:

On a Raspberry Pi B+ running Raspbian jessie, I run this command: "sudo find /
-iname 'firefox_binary.py'" to find a file I know exists.  The first time I
run it, find exits without any errors, and 0 results.  The second time I run
it, only seconds later, find locates the file.  Here is a video documenting
the behavior: youtube.com/watch?v=qDB_50RwWa8  In addition, I opened this up
as a question at
http://unix.stackexchange.com/questions/265571/how-is-it-that-the-same-find-command-can-give-two-different-results?noredirect=1#comment459672_265571
and it seems to have stumped all the unix gurus on there, who recommended that
I submit a bug report.  Here's the strace of the first run (fails):
http://lenschulwitz.com/find1.txt and the strace of the second run (succeeds):
http://lenschulwitz.com/find2.txt




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[bug #46815] problem when testing file size

2016-01-07 Thread anonymous

Follow-up Comment #2, bug #46815 (project findutils):

Hi James,

Thanks for your quick response!

Before I decided to submit this report I checked out the current version of
GNU findutils as recommended on the project's website. The code for comparing
file sizes, which I've quoted in the report, is nearly 16 years old. Hence I
wasn't sure which version to choose from the drop-down list because the oldest
selectable one (4.1.7) has been released one year after the commit and so
*all* versions are affected.

Sorry that I didn't read the description you've quoted from the manpage. The
file has been changed only 5 days before my bug report - I didn't noticed the
change.

I still wonder about the way GNU find compares file sizes. Rounding up an one
byte sized file to one gigabyte, for example, doesn't seem to be the way an
average user expects. I discussed this topic with various persons before I
opened the ticket. Everyone was very surprised that GNU find rounds up the
size to the specified unit. I also tested the find implementations of FreeBSD
and Busybox. As you can see both commands don't round up:

*
https://svnweb.freebsd.org/base/head/usr.bin/find/function.c?view=markup#l1457
* https://git.busybox.net/busybox/tree/findutils/find.c#n1326

I would be glad if someone could state a reasonable use-case where rounding up
makes sense, because I can't find one.


Kind regards & many thanks in advance,

Sebastian


___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Savannah
  http://savannah.gnu.org/

[bug #46815] problem when testing file size

2016-01-04 Thread anonymous

URL:
  

 Summary: problem when testing file size
 Project: findutils
Submitted by: None
Submitted on: Di 05 Jan 2016 06:08:51 UTC
Category: find
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: 
Originator Email: sebastian.fed...@gmail.com
 Open/Closed: Open
 Discussion Lock: Any
 Release: None
   Fixed Release: None

___

Details:

Hi,

I noticed a strange behaviour in GNU find when testing the file
size. Let me explain the found problem with a small example:

$ dd if=/dev/zero of=foo.1k bs=1024 count=1
$ dd if=/dev/zero of=foo.24k bs=1024 count=24
$ dd if=/dev/zero of=foo.1M bs=1024 count=1024

$ # this should only find foo.1M:
$ find . -size 1M
.
./foo.24k
./foo.1k
./foo.1M

$ # this one works correctly:
$ find . -size 24k
./foo.24k

$ # all files less than 1M should be found but result is empty:
$ find . -size -1M

$ # all files are found:
$ find . -size -2M
.
./foo.24k
./foo.1k
./foo.1M

$ # a different unit also solves the issue:
$ find . -size -1024k
.
./foo.24k
./foo.1k

The problem is how pred_size() calculates the file size. When
searching for a file with a size of 1M and processing the test
files we created previously f_val is always 1:

f_val = ((1024 / 1048576)  + (1024 % 1048576 != 0))  = 1
f_val = ((24576 / 1048576) + (24576 % 1048576 != 0)) = 1
f_val = ((24576 / 1048576) + (24576 % 1048576 != 0)) = 1

I fixed the problem on my system by applying this patch:

diff --git a/find/pred.c b/find/pred.c
index d633ab9..73abbec 100644
--- a/find/pred.c
+++ b/find/pred.c
@@ -956,12 +956,12 @@ bool
 pred_size (const char *pathname, struct stat *stat_buf, struct predicate
*pred_ptr)
 {
   uintmax_t f_val;

   (void) pathname;
-  f_val = ((stat_buf->st_size / pred_ptr->args.size.blocksize)
-  + (stat_buf->st_size % pred_ptr->args.size.blocksize != 0));
+  f_val = stat_buf->st_size / pred_ptr->args.size.blocksize;
+
   switch (pred_ptr->args.size.kind)
 {
 case COMP_GT:
   if (f_val > pred_ptr->args.size.size)
return (true);


Kind regards,

Sebastian




___

Reply to this item at:

  

___
  Nachricht gesendet von/durch Savannah
  http://savannah.gnu.org/

[bug #46670] Find terminates after searching an auto mounted nfs directory

2015-12-18 Thread anonymous

Follow-up Comment #3, bug #46670 (project findutils):

This does appear to be the same bug as reported in Gentoo, and it does appear
to be fixed by 4.5.15.

I'm not 100% sure because some things have changed in my system since I first
reported the bug.  Today, I've only been able trigger it sometimes with 4.4.2.
 But I never triggered it with 4.5.15.

I think you should just mark it closed as being fixed 4.5.x.

Reed Cartwright

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[bug #46670] Find terminates after searching an auto mounted nfs directory

2015-12-11 Thread anonymous

URL:
  

 Summary: Find terminates after searching an auto mounted nfs
directory
 Project: findutils
Submitted by: None
Submitted on: Sat 12 Dec 2015 02:46:51 AM UTC
Category: find
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: 
Originator Email: cartwri...@asu.edu
 Open/Closed: Open
 Discussion Lock: Any
 Release: None
   Fixed Release: None

___

Details:

On my system /storage is an autofs-mounted nfs directory.  If I don't exclude
that directory, find will stop after it finishes searching /storage and will
not search the rest of the hierarchary.

For instance the following command will not return anything after /storage

sudo find / -uid 1000 -print

However, if I exclude storage based on the following command, I do get more
results.

sudo find / -path /storage -prune -o -user 1000 -print

My mount layouts are attached.



___

File Attachments:


---
Date: Sat 12 Dec 2015 02:46:51 AM UTC  Name: mounts.txt  Size: 10kB   By: None



___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[bug #45930] -ignore_readdir_race ineffective in find 4.5.11 and 4.5.14

2015-09-11 Thread anonymous

URL:
  

 Summary: -ignore_readdir_race ineffective in find 4.5.11 and
4.5.14
 Project: findutils
Submitted by: None
Submitted on: Fri 11 Sep 2015 01:05:25 PM UTC
Category: find
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: Rainer Canavan
Originator Email: rainer+findut...@7val.com
 Open/Closed: Open
 Discussion Lock: Any
 Release: 4.5.14
   Fixed Release: None

___

Details:

We have a cron job that is used to clean cache directories. There's a log
going on in that directory, especially files getting moved from temporary
names to their final names after they have been written completely. We have
noticed that the find that is supplied with Centos7 (version 4.5.11) as well
as a find 4.5.14 built from unmodified source frequently prints "No such file
or directory" errors for the initial filenames of the temporary files, despite
the fact that we have specified -ignore_readdir_race, e.g.:

/usr/bin/find: ‘./engine/projects/portal/istmp1NYV9b’: No such file or
directory

This does not happen with a find 4.4.2 compiled from source. A trivial find in
the "busy" directory is sufficient to triffer the error message almost 100% of
the time:

find . -ignore_readdir_race > /dev/null






___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

1 2 3 >

1 - 100 of 260 matches

Mail list logo