Hide Forgot
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.
Created attachment 1117893 [details] file_dir.tgz
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.
(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.
(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.
(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?
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.