Bug 525402

Summary: ls -L option Can not detects infinite loops
Product: [Fedora] Fedora Reporter: Yang Ren <ryang>
Component: coreutilsAssignee: Ondrej Vasik <ovasik>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: drepper.fsp, kdudka, llim, meyering, ovasik, twaugh
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-10-12 07:26:56 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Attachments:
Description Flags
shell script
none
strace log with LC_ALL=C none

Description Yang Ren 2009-09-24 05:10:49 EDT
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 05:57:05 EDT
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 08:50:30 EDT
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 08:52:28 EDT
Created attachment 362487 [details]
shell script
Comment 4 Yang Ren 2009-09-24 08:57:02 EDT
Created attachment 362489 [details]
strace log with LC_ALL=C
Comment 5 Ondrej Vasik 2009-09-24 09:11:18 EDT
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 09:31:38 EDT
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 12:35:02 EDT
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 07:26:56 EDT
coreutils 8.0 which contains that fix is now in rawhide, closing.