Bug 1301525

Summary: ll fails to list a symbolic link pointing to a non-existing file
Product: Red Hat Enterprise Linux 6 Reporter: Xianghua Chen <xchen>
Component: libguestfsAssignee: Richard W.M. Jones <rjones>
Status: CLOSED WONTFIX QA Contact: Virtualization Bugs <virt-bugs>
Severity: medium Docs Contact:
Priority: medium    
Version: 6.8CC: leiwang, linl, ptoscano, wshi
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-11-08 16:55:27 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1301844    
Attachments:
Description Flags
file_dir.tgz none

Description Xianghua Chen 2016-01-25 09:45:02 UTC
Description of problem:
ll fails to list a symbolic link pointing to a non-existing file, it also fails to list the complete link info of a symbolic link pointing to a regular file.

Version-Release number of selected component (if applicable):
libguestfs-1.20.11-17.el6.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Download the attachement: file_dir.tgz to /tmp

2. Create a image by:
qemu-img create -f raw /tmp/file_dir.ext2.raw 2G

3. guestfish -a /tmp/file_dir.ext2.raw
><fs> run
><fs> part_disk "/dev/sda" mbr
><fs> mkfs "ext2" "/dev/sda1"
><fs> mount-options noatime /dev/sda1 /
><fs> tgz-in /tmp/file_dir.tgz /
><fs> ll /file_ops/
total 12912
......
-rw-r--r--  1 root root     653 Apr 16  2010 file_ascii
lrwxrwxrwx  1 root root      11 Jan 25 02:46 file_ascii_badlink -> nothis_file
lrwxrwxrwx  1 root root      10 Jan 25 02:46 file_ascii_softlink -> file_ascii
......

><fs> trace 1
><fs> verbose 1

4.
><fs> ll /file_ops/file_ascii_badlink
libguestfs: trace: ll "/file_ops/file_ascii_badlink"
libguestfs: send_to_daemon: 76 bytes: 00 00 00 48 | 20 00 f5 f5 | 00 00 00 04 | 00 00 00 05 | 00 00 00 00 | ...
guestfsd: error: /file_ops/file_ascii_badlink: No such file or directory
libguestfs: recv_from_daemon: 112 bytes: 20 00 f5 f5 | 00 00 00 04 | 00 00 00 05 | 00 00 00 01 | 00 12 34 13 | ...
libguestfs: trace: ll = NULL (error)
libguestfs: error: ll: /file_ops/file_ascii_badlink: No such file or directory

5.
><fs> ll /file_ops/file_ascii_softlink
libguestfs: trace: ll "/file_ops/file_ascii_softlink"
libguestfs: send_to_daemon: 80 bytes: 00 00 00 4c | 20 00 f5 f5 | 00 00 00 04 | 00 00 00 05 | 00 00 00 00 | ...
libguestfs: recv_from_daemon: 116 bytes: 20 00 f5 f5 | 00 00 00 04 | 00 00 00 05 | 00 00 00 01 | 00 12 34 15 | ...
libguestfs: trace: ll = "-rw-r--r-- 1 root root 653 Apr 16  2010 /sysroot/file_ops/file_ascii\n"
-rw-r--r-- 1 root root 653 Apr 16  2010 /sysroot/file_ops/file_ascii


The one line command instead the steps above is:
guestfish -a /tmp/file_dir.ext2.raw run : part_disk "/dev/sda" mbr : mkfs "ext2" "/dev/sda1"  : mount-options noatime /dev/sda1 / : tgz-in /tmp/file_dir.tgz / : ll /file_ops/file_ascii_softlink : ll /file_ops/file_ascii_badlink



Actual results:
In step 4, it prompt error: "libguestfs: error: ll: /file_ops/file_ascii_badlink: No such file or directory"
In step 5, it return: "-rw-r--r-- 1 root root 653 Apr 16  2010 /sysroot/file_ops/file_ascii"

Expected results:
In step 4, it should return like "lrwxrwxrwx 1 root root 11 Aug 15  2011 /sysroot/file_ops/file_ascii_badlink -> nothis_file"
In step 5, it should return like "lrwxrwxrwx 1 root root 10 Aug 15  2011 /sysroot/file_ops/file_ascii_softlink -> file_ascii"

Additional info:
I have tried in:
RHEL6.8 + libguestfs-1.20.11-14.el6.x86_64
RHEL7.2 + libguestfs-1.32.1-1.el7.x86_64

They are all ok.

Comment 1 Xianghua Chen 2016-01-25 09:48:21 UTC
Created attachment 1117893 [details]
file_dir.tgz

Comment 2 Pino Toscano 2016-01-25 10:11:41 UTC
ll is actually documented to work on directories only, so it works "by chance" on files. It is also a command mostly meant for debugging (since the output is not parseable).

So I'm not convinced it is a bug that needs to be fixed.

Comment 3 Xianghua Chen 2016-01-26 04:30:23 UTC
(In reply to Pino Toscano from comment #2)
> ll is actually documented to work on directories only, so it works "by
> chance" on files. It is also a command mostly meant for debugging (since the
> output is not parseable).
> 
> So I'm not convinced it is a bug that needs to be fixed.

Thank you for your reply. 
But I have tried in the previous version(RHEL6.8 + libguestfs-1.20.11-14.el6.x86_64)  many times ,it's always ok. May be some new patches lead to this problem. I think it might be necessary to check why only this version has this problem. It's also ok in RHEL7.2 version.

Comment 4 Pino Toscano 2016-01-26 09:38:05 UTC
(In reply to Xianghua Chen from comment #3)
> But I have tried in the previous version(RHEL6.8 +
> libguestfs-1.20.11-14.el6.x86_64)  many times ,it's always ok.

As I said, the fact that it worked on files was "luck". You should not have relied on it working on files, as only directories are documented to work with it.

  ><fs> help ll
  NAME
      ll - list the files in a directory (long format)

  SYNOPSIS
       ll directory

  DESCRIPTION
      List the files in directory (relative to the root directory, there is no
      cwd) in the format of 'ls -la'.

      This command is mostly useful for interactive sessions. It is *not*
      intended that you try to parse the output string.

> May be some
> new patches lead to this problem. I think it might be necessary to check why
> only this version has this problem.

I know well why the new changes in libguestfs-1.20.11-17 caused this issue, but I'm not going to fix a behaviour which was never the intended nor documented one.

> It's also ok in RHEL7.2 version.

It may change in 7.3 as well.

Comment 5 Xianghua Chen 2016-01-29 10:04:27 UTC
(In reply to Pino Toscano from comment #4)
> (In reply to Xianghua Chen from comment #3)
> > But I have tried in the previous version(RHEL6.8 +
> > libguestfs-1.20.11-14.el6.x86_64)  many times ,it's always ok.
> 
> As I said, the fact that it worked on files was "luck". You should not have
> relied on it working on files, as only directories are documented to work
> with it.
> 
>   ><fs> help ll
>   NAME
>       ll - list the files in a directory (long format)
> 
>   SYNOPSIS
>        ll directory
> 
>   DESCRIPTION
>       List the files in directory (relative to the root directory, there is
> no
>       cwd) in the format of 'ls -la'.
> 
>       This command is mostly useful for interactive sessions. It is *not*
>       intended that you try to parse the output string.
> 
> > May be some
> > new patches lead to this problem. I think it might be necessary to check why
> > only this version has this problem.
> 
> I know well why the new changes in libguestfs-1.20.11-17 caused this issue,
> but I'm not going to fix a behaviour which was never the intended nor
> documented one.
> 
> > It's also ok in RHEL7.2 version.
> 
> It may change in 7.3 as well.

Ok, got it. Thank you for your explanation. 
I'll change our cases then. 
Would you help to close it when you confirm that you won't fix it?

Comment 6 Pino Toscano 2016-11-08 16:55:27 UTC
As explained in comment #2 and comment #4, ll is mostly a debugging API for directories, so what happens with files is "undefined behaviour".

Because of that, the behaviour (already changed to fix the real use case of it) will not be changed.