When I create NTFS junction points via ntfs-3g then remount the volume in Windows 7, windows does not recognize the junction point and shows it as a directory.

If I tickle my junction point via "fsutil hardlink list <junction>" it will tickle ntfs in such a way that it (presumably) changes something in the $MFT or $Extend\$Reparse and from that point forward the junction point is correctly shown as a junction point (provided the volume is writable, or you do not reboot). I really need the junction points to be recognized correctly immediately, without any cajoling.

My process to produce this is:
- mount a NTFS volume via ntfs-3g where win7 is installed
- create a directory say "c:\users\default\newjunction"
- copy the junction point information out of "c:\users\default\Recent"
- apply it to "newjunction"... c:\users\default\newjunction should now be a junction point connected to c:\users\default\appdata\roaming\microsoft\windows\recent
- umount, etc
- mount the volume under Win7
- open an cmd window with admin privs, navigate to c:\users\default, do a "dir" and see "newjunction" listed as a directory.
- run "fsutil hadlink list newjunction"
- do a dir and see newjunction listed as a junction point

As far as I can tell, this is not merely a cosmetic issue. My application has problems with these directories until they are "fixed." If you do a similar experiment where the ntfs volume is read-only under windows, you can "fix" the junction point in the same way, but the change does not persist through reboots.

Hi,



We cannot guarantee such a procedure to be effective, because Windows uses physical addresses which Linux cannot guess (for pluggable devices, it depends on the socket you use to plug it).

And if you cannot make the Windows fix permanent, I guess you cannot display its parameters either.... and I cannot check anything.

If you created the junction point by Windows, I could check the differences and check whether the copy can be improved... but I am not sure this is even possible.

Regards

Jean-Pierre

Hi,


Sorry, I misread this paragraph, and thought your fix was never permanent. If it is permanent over read+write mounts, it would be useful if you posted the original reparse data and the fixed one :

Please also indicate whether the original junction point, the target and the copy were on a fixed disk or pluggable ones, and in the latter situation whether they are used on the same computer. Also, which ntfs-3g version you are using.

Regards

Jean-Pierre

Yes I can make the "fix" permanent. Unfortunately, the original and "fixed" reparse points are the same.



Output from ntfsinfo for both the broken and fixed versions also looks the same.

I've verified the behavior I describe still happens with 2010.1.16AR. Everything I'm doing is on virtual machines in vmware, I believe the disks count as fixed. To produce the behavior, I'm just passing VMDKs back and forth between the linux machine with ntfs-3g and a windows machine.

Hi,

[what's going on with the forum ?]

I have tried to reproduce the behavior you reported, with limited success.
I do not have Win7, I used Vista

First I cloned the reparse data of /vista/Users/Default/Recent
to a directory on another device (a USB key).

On Vista this is recognized as a junction point, but I cannot "follow the link"
(hope the French output is understandable...)



So I created on Vista another junction point targetting the same directory :
The result is not similar, and I can "follow the link".



Back on Linux, I create another directory Recent.lnx and clone the reparse point

Again on Vista I check the result.
The junction point is ok and I can follow the link.



This shows a junction point to another volume is different from a junction
point to the same volume, and a junction point can be cloned provided
the clone remains on the same volume as the original.

Also did you really used "fsutil hardlink list <junction>" ?
this command is about hardlinks, not junctions, and on Vista the
command list is not implemented for hardlinks.
I could use "fsutil reparsepoint" which has only two options
(query and delete), and none to create a junction point.



Now, what is different in your situation ?

Regards

Jean-Pierre

Hi again,

I think I have understood why your procedure was successful



The "fsutil hardlink" has created "newjunction" as a *hard link* to the original junction point,
it has probably deleted the directory you had created and its cloned junction point.
This is possible because both junction points are on the same volume, but
on Linux you could not have used a plain "ln" because hard links are not
allowed on directories.

You can check this by displaying the inode numbers of original junction point
and hard link (eg by "ls -li")

Regards

Jean-Pierre

I've gone through the process you gave and still managed to reproduce the issue. The only differences I can concieve of are Win7 vs Vista, possibly we "clone" the junction points differently. I make a directory with the name I want, then use the commands at http://www.tuxera.com/community/ntfs-3g ... ttributes/ to get and set the reparse information. My second filename also doesn't meet 8.3 standards.

Here's what I did:

I used junction to make a new junction under win7



I powered down the machine, moved the vmdk to linux, mounted it with the latest ntfs-3g and cloned the junction. (made a new directory, then set reparse attribute).



Linux is happy with the new junction:


I unmount the vmdk from linux, move it back to the win7 machine, boot it up and see my same issue.


I don't think your theory about the hardlink list command is correct. According to the help output it just enumerates existing hardlinks (I would think it just parses the MFT entry for all the FILE_NAME attributes).
This is the help output for the hardlink list command. I do not think it does anything to make a hardlink.



If I poke the junction with this command, Windows "fixes" it and is happy again.



I think this addresses everything from your last two posts. I'm going to go back to look at the MFT between "fixed" and "unfixed" to see if I can spot a difference in the entries.

I don't have to use the fsutil to fix the junction point, I can just navigate through it, and on the next directory listing, its fine. That fix is permanent as well.

Comparing the MFT entry for that junction point before and after windows "fixes it," every single byte is the same. That is frustrating. What I did notice though, is that because I am making the new directory in linux, then copying the reparse data into it, it ends up with the old NTFS 1.2 style STANDARD_INFORMATION attribute. Since junction points didn't exist for NTFS 1.2, I wonder if some part in win7 gets a little confused and briefly ignores the reparse information because of the small old style STANDARD_INFORMATION.

If I make a directory in windows 7, then attach the disk to linux and copy reparse data into it, I can bring the volume back to windows and now the junction point displays correctly the first time.

Hi,

That is because you did not enable file permissions. You might copy the ACL the way you copied the reparse data to get an ACL stored in a global file and referenced in STANDARD_INFORMATION.

Interesting. So the reparse data cloning is not at stake. This also eliminates the situation in which Windows would need to have some related data in its registry.

The suspicion about name spaces (cf not 8.3 pattern) or ACL location are hardly credible as you do not find a difference in the MFT after the fix is made permanent.

I have no other idea for now.

Regards

Jean-Pierre

Hi,

I have found a difference which can be significant between the original junction point and the clone : the reparse tag is present in the index entry of the parent directory of the original, and it is not in the clone.



Can you check whether your fixing procedure adds this information to the index in the parent directory of the cloned reparse point ?

I will fix that ASAP and propose a patch.

Regards

Jean-Pierre

Hi,

Can you try the attached patch ? (it can be applied to ntfs-3g-2010.1.16AR.1 or ntfs-3g-2010.2.6-RC which are the same)

The patch updates the copy of the reparse tag to the parent directories of a junction point.

After examining the results of my previous tests again, I see that Vista had silently updated the parent directories. So this should definitely be made, and I hope this was the root cause of the behavior you reported.

Regards

Jean-Pierre

Yes, my "fix" sets the Reparse Point tag in the index entry.

I applied the patch, and now when I clone reparse points they show up correctly.

Hooray! Thanks so much for the help!

Hi,




Good news !

Thank you for your report and your help locating the bug and improving ntfs-3g.

Regards

Jean-Pierre