Bug 693064 - Symbolic links on ntfs-3g are not followed correctly by some commands
Symbolic links on ntfs-3g are not followed correctly by some commands
Status: NEW
Product: Virtualization Tools
Classification: Community
Component: libguestfs (Show other bugs)
unspecified
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Richard W.M. Jones
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-04-02 05:58 EDT by Richard W.M. Jones
Modified: 2011-10-25 05:34 EDT (History)
2 users (show)

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


Attachments (Terms of Use)

  None (edit)
Description Richard W.M. Jones 2011-04-02 05:58:17 EDT
Description of problem:

[This really a bug or shortcoming in ntfs-3g, and is caused by the
stupid way that symlinks are implemented in NTFS itself.  For some
background on this see
http://libguestfs.org/guestfs.3.html#symlinks_on_ntfs_3g_filesystems ]

Paths that contain elements that are symbolic links are not
followed correctly by some commands.  It depends on whether
the command happens to be implemented using a chroot or not.

For a full example see "Steps to reproduce" below.

If /foo is a symbolic link to (say) C:\baz then ntfs-3g rewrites
/foo as a symbolic link to /sysroot//baz (actually incorporating
the mount point in the path itself).  This works fine as long
as we don't chroot:

 /sysroot/foo/bar -> /sysroot//baz/bar

but if a command does a chroot then it fails:

 /foo/bar -> /sysroot//baz/bar  ** fail: /sysroot not found **

Version-Release number of selected component (if applicable):

libguestfs 1.9.16

How reproducible:

100% on NTFS filesystems, for paths that contain symbolic links.

Steps to Reproduce:

You need a Windows 7 guest to follow these steps, because
on Windows 7, "/Documents and Settings/" is no longer a real
directory, but a symbolic link to /Users/

1. Open the Windows 7 guest image using guestfish:

# guestfish --ro -i -d Win7Guest
><fs> ll "/Documents and Settings"
lrwxrwxrwx 2 root root 60 Jul 14  2009 /sysroot/Documents and Settings -> /sysroot//Users

2. Run 'file' on "/Documents and Settings/Default/NTUSER.DAT".  Note
I'm using win:... rewriting in guestfish (see:
http://libguestfs.org/guestfish.1.html#windows_paths )

><fs> file "win:/Documents and Settings/Default/NTUSER.DAT"
MS Windows registry file, NT/2000 or above

3. Try to download the same file:

><fs> download "win:/Documents and Settings/Default/NTUSER.DAT" /tmp/NTUSER.DAT
libguestfs: error: download: /Documents and Settings/Default/NTUSER.DAT: No such file or directory
  
Actual results:

Error message.

Expected results:

All commands should work consistently on NTFS-3g filesystems,
including on paths that contain symbolic links.

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