Hi, all

I've an example where I make recursively use of symlinks.

Here's some data about my setup:
NTFS system is mounted at /mnt/windows with no special configuration.

Here's the folder-structure how it looks under windows:


If I look what Linux shows me using ls I get the following result for testfolder:


Is this a known limitation?
My version is ntfs-3g 2012.1.15 external FUSE 29

Hi,


You are apparently using Windows-type symlinks, whose semantics are different from the Linux ones.

ntfs-3g has inserted "/.NTFS-3G/C:/" because the path "/webspace/testfolder/foo/subfolder1" was not found on the volume mounted as /mnt/windows (so "/mnt/windows/webspace/testfolder/foo/subfolder1" does not exist) . The "C:" is part of how the symlink was declared in Windows.

You have to keep in mind that Windows defines symlinks by using physical designations (such as C:) which are unknown to Linux. If you need a symlink designating a target on the same volume, you can define a relative target, which will have roughly the same semantics on Windows and Linux, but if you need to designate another volume, you have to define the linux path to the target volume (its mount point) as a Linux symlink in the hidden folder .NTFS-3G of the source volume.

See details at http://www.tuxera.com/community/ntfs-3g ... lic-links/

Regards

Jean-Pierre

Hi, Jean-Pierre

Both symlinks are created by Windows7 using mklink.
The difficult part I see is, that the symlink bar points to a folder that's first available when the symlink for foo is initialized. So .. the target is present, but just after the symlink foo has been set up.

On Windows7 I haven't found a possibility to create a relative symlink ... Every time I create a symlink the full path is shown in the output of dir.

Hi,



Within http://pagesperso-orange.fr/b.andre/tools.zip there is a small Linux program "winsln.c" to create relative Windows-type symlinks. The first argument is the target and the second one is the source (same order as ln, but opposite from mklink). The target must exist and the source must be a void file (if the target is a file) or a void directory (if the target is a directory).

*edit* Wrong : the source must not exist.

Regards

Jean-Pierre

Hi, Jean-Pierre

I now have (in my eyes) a workaround running, that is described on the link you sent me
I just think it's better described in the code itself

http://svn.dd-wrt.com:8000/browser/src/ ... 17263#L560
So my workaround is to create a folder .NTFS-3G in /mnt/windows (the base of my mounted partition) and execute the following command in there:



But what I think by reading the code ... should this not be checked automatically? The linked folder is on the same device ... but just not available before the symlink foo has been resolved.

Hi again,


Should be ok.

Well, yes. You are in a situation where the target path contains another symlink which defeats the full check. However the path check could be stopped where the symlink is found, as the remaining part will be checked later, when the vfs tries to resolve the path again, after the first symlink is resolved. I have to put it on my todo list (not straightforward)....

Apparently, winsln has a similar limitation, and this one should be easier to lift.

Regards

Jean-Pierre

Hi again,


Fixed now (download tools.zip again).


These relative symlinks within a volume are fully compatible Windows and Linux.

Regards

Jean-Pierre

Hi again,

The attached patch is supposed to care for the situation in which a junction or absolute symlink designates a path which contains another junction or symlink. Only Windows-type symlinks are allowed, and all paths must be designate the same volume.

Can you try it ?

Regards

Jean-Pierre

Hi,

Can you please provide a 1-2-3 manual?
The only thing I've done until now is installed pre-configured packages from a repository for my Linux distribution (Arch)

Bye
Simon

Hi,



If you are uneasy with the basic rebuild procedure (./configure; make; make install), or you do not have the rebuilding tools, then you can wait for your distributor to do it. This is however likely to take months.

Regards

Jean-Pierre