Bug 525402 - ls -L option Can not detects infinite loops
Summary: ls -L option Can not detects infinite loops
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: coreutils
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Ondrej Vasik
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-09-24 09:10 UTC by Yang Ren
Modified: 2009-10-12 11:26 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-10-12 11:26:56 UTC


Attachments (Terms of Use)
shell script (229 bytes, text/plain)
2009-09-24 12:52 UTC, Yang Ren
no flags Details
strace log with LC_ALL=C (18.27 KB, text/plain)
2009-09-24 12:57 UTC, Yang Ren
no flags Details

Description Yang Ren 2009-09-24 09:10:49 UTC
Description of problem:
ls should exit with 1 when detects infinite loops.

This problem should be the same as -L option problem
After using -L option the link should show as the linked file/folder.
So it will be a infinite loop

Version-Release number of selected component (if applicable):
coreutils-7.6-5.fc12.x86_64

How reproducible:
Always

Steps to Reproduce:
mkdir $PWD/ls_73_dir
mkdir $PWD/ls_73_dir/ls_73_dir2
ln -s $PWD/ls_73_dir $PWD/ls_73_dir/ls_73_dir2/ls_73_link
ls -RL ls_73_dir
  
Actual results:
$? = 0

Expected results:
$? = 1
and print some error message

Additional info:
This is a part of POSIX shell test from opengroup

Comment 1 Ondrej Vasik 2009-09-24 09:57:05 UTC
Sorry, but almost works for me ... (version is the same)
$ls -RL ls_73_dir
ls_73_dir:
ls_73_dir2

ls_73_dir/ls_73_dir2:
ls_73_link
ls: ls_73_dir/ls_73_dir2/ls_73_link: not listing already-listed directory

$? = 0, but this maybe considered as exit success - as all files were listed successfully and infinite loop was correctly detected. Will check if it does conform with POSIX...
What's the output on your side? Could you provide strace log (please, with C locales)? TIA.

Comment 2 Yang Ren 2009-09-24 12:50:30 UTC
My output is same with you.
The problem is test suite expect this it exit fail.
I'm not sure which behavior is right? If POSIX did not defined this situation I think our behavior(consider as exit success) should be ok.

If so I'll submit a problem to test suite.

And I'll attach my script and strace here later.

(In reply to comment #1)
> Sorry, but almost works for me ... (version is the same)
> $ls -RL ls_73_dir
> ls_73_dir:
> ls_73_dir2
> 
> ls_73_dir/ls_73_dir2:
> ls_73_link
> ls: ls_73_dir/ls_73_dir2/ls_73_link: not listing already-listed directory
> 
> $? = 0, but this maybe considered as exit success - as all files were listed
> successfully and infinite loop was correctly detected. Will check if it does
> conform with POSIX...
> What's the output on your side? Could you provide strace log (please, with C
> locales)? TIA.

Comment 3 Yang Ren 2009-09-24 12:52:28 UTC
Created attachment 362487 [details]
shell script

Comment 4 Yang Ren 2009-09-24 12:57:02 UTC
Created attachment 362489 [details]
strace log with LC_ALL=C

Comment 5 Ondrej Vasik 2009-09-24 13:11:18 UTC
I meant strace log of the ls command, not the shell scripts (it doesn't trace child processes), but it doesn't matter if the output is the same... 

Yes, I think POSIX is not specific what to do in the case of infinite loop. Upstream decided to just exit 0 with information message. Please discuss the issue with authors of testsuite - and if they feel there is something in POSIX what requires nonzero exit status in that case, feel free to report it upstream at bug-coreutils@gnu.org - as this behaviour is not Fedora specific (and IMHO is correct - so closing NOTABUG this bugzilla). Mention this bugzilla in that case.

Anyway, thanks for report(s).

Comment 6 Ulrich Drepper 2009-09-28 13:31:38 UTC
I think POSIX is quite clear.  If an error is reported the exit code is > 0.  The text requiring the detection of inifinite loops says a diagnostic is written but this term implies that there is a problem (aka error).  Hence I think ls has to be changed.

Comment 7 Jim Meyering 2009-09-28 16:35:02 UTC
Thanks for the report!  I've just posted a patch:
http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/18316

Comment 8 Ondrej Vasik 2009-10-12 11:26:56 UTC
coreutils 8.0 which contains that fix is now in rawhide, closing.


Note You need to log in before you can comment on or make changes to this bug.