RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1301525 - ll fails to list a symbolic link pointing to a non-existing file
Summary: ll fails to list a symbolic link pointing to a non-existing file
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libguestfs
Version: 6.8
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Richard W.M. Jones
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks: 1301844
TreeView+ depends on / blocked
 
Reported: 2016-01-25 09:45 UTC by Xianghua Chen
Modified: 2016-11-08 16:55 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-11-08 16:55:27 UTC
Target Upstream Version:
Embargoed:

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

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.
Note You need to log in before you can comment on or make changes to this bug.