Bug 1301525 - ll fails to list a symbolic link pointing to a non-existing file
ll fails to list a symbolic link pointing to a non-existing file
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libguestfs (Show other bugs)
6.8
Unspecified Unspecified
medium Severity medium
: rc
: ---
Assigned To: Richard W.M. Jones
Virtualization Bugs
:
Depends On:
Blocks: 1301844
  Show dependency treegraph
 
Reported: 2016-01-25 04:45 EST by Xianghua Chen
Modified: 2016-11-08 11:55 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-11-08 11:55:27 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
file_dir.tgz (3.62 MB, application/x-gzip)
2016-01-25 04:48 EST, Xianghua Chen
no flags Details

  None (edit)
Description Xianghua Chen 2016-01-25 04:45:02 EST
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 04:48 EST
Created attachment 1117893 [details]
file_dir.tgz
Comment 2 Pino Toscano 2016-01-25 05:11:41 EST
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-25 23:30:23 EST
(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 04:38:05 EST
(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 05:04:27 EST
(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 11:55:27 EST
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.

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