bug#21084: rm appears to no longer be POSIX compliant (as of 2013 edition) re: deleting empty dirs and files under path/.

2015-07-18 Thread Andreas Schwab
Linda Walsh coreut...@tlinx.org writes:

 But step 4 on that page says that rm should remove empty directories
 without requiring other special switches.

Please read step 2a.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
And now for something completely different.





bug#21084: rm appears to no longer be POSIX compliant (as of 2013 edition) re: deleting empty dirs and files under path/.

2015-07-18 Thread Linda Walsh

In looking at the 2013 specification for rm
(http://pubs.opengroup.org/onlinepubs/9699919799/utilities/rm.html),

it no longer says to stop processing if the path basename equals
. or ... 


It says that the entries . and .. shall not be removed.  It
also says rm empty dir shall behave like rmdir -- i.e. it will
delete empty directories.

But in the case of foo/. it would be expected to process child inodes
before processing the directory itself.

But step 4 on that page says that rm should remove empty directories
without requiring other special switches.








bug#21084: rm appears to no longer be POSIX compliant (as of 2013 edition) re: deleting empty dirs and files under path/.

2015-07-18 Thread Andreas Schwab
Linda Walsh coreut...@tlinx.org writes:

 In looking at the 2013 specification for rm
 (http://pubs.opengroup.org/onlinepubs/9699919799/utilities/rm.html),

 it no longer says to stop processing if the path basename equals
 . or ... 

If either of the files dot or dot-dot are specified as the basename
portion of an operand (that is, the final pathname component) or if an
operand resolves to the root directory, rm shall write a diagnostic
message to standard error and do nothing more with such operands.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
And now for something completely different.





bug#21061: coreutils-8.24 - Partially reproducible failures of tests/misc/timeout-parameters.sh

2015-07-18 Thread Pádraig Brady
On 18/07/15 04:09, Peter Bray wrote:
 On 17/07/15 06:56 PM, Pádraig Brady wrote:
 while true; do time gtimeout 0.1 sleep inf; test $? != 124  break; done
 
 Run this code on S10U8/32 for almost 12 hours without it stopping 
 itself. An almost 10 hours on S10U11/32 with the same result (not 
 stopping itself).

Cool. That suggests it's a kernel issue with large timeout values.

 
 Made the requested change to src/timeout.c
 
 Backup  : src/timeout.c.orig
 Editted : src/timeout.c
 
 Command : gdiff
 
 139c139
if (timer_create (CLOCK_REALTIME, NULL, timerid) == 0)
 ---
 if (timer_create (CLOCK_MONOTONIC, NULL, timerid) == 0)
 
 Run as an unprivileged user, gives the following error summary:
 
 % egrep '(FAIL|ERROR) ' tests/test-suite.log | sed -e 's/FAIL /FAIL  /'
 FAIL  tests/misc/tee.sh (exit status: 1)
 FAIL  tests/misc/timeout-blocked.pl (exit status: 1)
 FAIL  tests/tail-2/wait.sh (exit status: 1)
 FAIL  tests/tail-2/retry.sh (exit status: 1)
 FAIL  tests/tail-2/symlink.sh (exit status: 1)
 FAIL  tests/ls/infloop.sh (exit status: 1)
 FAIL  tests/tail-2/follow-name.sh (exit status: 1)
 FAIL  tests/tail-2/follow-stdin.sh (exit status: 1)

That's a strange restriction.
Linux doesn't have that at least.

 
 On Solaris 10 Update 8 with Solaris 10 Update 11 and Solaris 11.2 have 
 the additional tmpfs build problems mentioned in BUG-21062
 
 With the following executive summary:
 
 % grep timer_create: Not owner ./tests/test-suite.log | sort | uniq -c
 1 + timeout: warning: timer_create: Not owner
 7 +timeout: warning: timer_create: Not owner
29 timeout: warning: timer_create: Not owner
 
 When run as root on Solaris 10 Update 8, the attached 
 test-suite.log-monotonic-root shows that two tests FAIL:
 
 % egrep '(FAIL|ERROR) ' test-suite.log-*-root | sed -e 's/FAIL /FAIL  /'
 FAIL  tests/misc/tee.sh (exit status: 1)
 FAIL  tests/misc/timeout-parameters.sh (exit status: 1)
 
 With the following section of the attached log, showing a sequence of 
 failures (exit status = 124) on the root execution of the checks:
 
 +++ date +%s
 ++ expr 2147483647 - 1437184440 + 100
 + KERNEL_OVERFLOW_LIMIT=710299307
 + timeout 710299307 sleep 0
 + test 0 '!=' 124
 + timeout 4294967296 sleep 0
 + test 124 = 0
 + fail=1
 ++ expr 4294967295 / 86400 + 1
 + timeout 49711d sleep 0
 + test 124 = 0
 + fail=1
 + timeout d 
 sleep 0
 + test 124 = 0
 + fail=1
 + timeout 2.34e+5d sleep 0
 + test 124 = 0
 + fail=1
 + timeout 2.34 sleep 0
 + test 0 = 0
 + timeout .9 sleep 0
 + timeout --signal=invalid 1 sleep 0
 timeout: invalid: invalid signal
 Try 'timeout --help' for more information.
 
 On Solaris 10 Update 11 as root, attached as 
 test-suite.log-monotonic-root-s10u11 shows a more promising result but 
 still failure:
 
 +++ date +%s
 ++ expr 2147483647 - 1437187249 + 100
 + KERNEL_OVERFLOW_LIMIT=710296498

Note we already check for similar 32 bit Linux/HPPA kernel issues
in this test. If we found a maximal value that was problematic
for solaris and ran the gating test in a loop 10 times say.
The non determinism of this is awkward though.

 The requirement for root privileges to use MONOTONIC is a non-starter 
 in my books as the utility can not lower privileges for the command it 
 runs - I hope you would agree. It seems that the tests fail even with 
 the CLOCK_MONOTONIC option.

+!

 I hope I am provided the requested / required information this time :-)

Yes thanks for the extensive testing.

Pádraig.






bug#21084: rm appears to no longer be POSIX compliant (as of 2013 edition) re: deleting empty dirs and files under path/.

2015-07-18 Thread Linda Walsh

reopen 21084
thanks

Andreas Schwab wrote:

Linda Walsh coreut...@tlinx.org writes:


In looking at the 2013 specification for rm
(http://pubs.opengroup.org/onlinepubs/9699919799/utilities/rm.html),

it no longer says to stop processing if the path basename equals
. or ... 


If either of the files dot or dot-dot are specified as the basename
portion of an operand (that is, the final pathname component) or if an
operand resolves to the root directory, rm shall write a diagnostic
message to standard error and do nothing more with such operands.


I'll grant it also says you can't remove /,

So a special flag --use_depth_first_inspection that says not to look 
at
a basename until it's children have been processed wouldn't be any more 
out of place than special flags to handle / processing, right?


The fact that they put the ., .. and / together, outside of
the 1-4 processing leads one to the idea that they should be treated similarly,
no?