on NTFS junction points

I have a strong feeling that the way junctions are being treated in NTFS
needs to be revised. The issue I see is that, once I have created a junction
from, say C:\FolderTarget pointing to D:\FolderSource, if I check permissions
on C:\FolderTarget, I will see the permissions of that folder, NOT the ones
of D:\FolderSource. Worse, if I change permission for C:\FolderTarget, none
of these changes will be propagated to subfolders/files in D:\FolderSource.

So, let's say I decide that I want to move my Public folders in Vista to a
separate partition. No problem, I move the files over, and create a junction
in C:\Users\Public pointing to the new location. HOWEVER, now Public Folder
Sharing will not work anymore (not from the Network and Sharing Center,
anyway): If I turn Public Folder Sharing on, then Vista will change
permissions for C:\Users\Public accordingly, but since this has no effect on
the permissions of the files at my new location, network users will not be
granted access to any of the files. The only way to give users access to
these files is to change file and sharing permissions of the source folder
manually.

I think what should be done is this: When I create a junction, the system
should check if the source and target folders have identicakl permissions. If
not, it should offer me to change permissions on either the source or the
target folder so that they are identical. Then, if I change permissions on
the target folder, permissions on the source folder should be changed in
lockstep.

Anybody with me on this one? Anybody care? ;-)

----------------
This post is a suggestion for Microsoft, and Microsoft responds to the
suggestions with the most votes. To vote for this suggestion, click the "I
Agree" button in the message pane. If you do not see the button, follow this
link to open the suggestion in the Microsoft Web-based Newsreader and then
click "I Agree" in the message pane.

http://windowshelp.microsoft.com/com...unts_passwords

John, those are interesting suggestions. Keep in mind that junction points
are a pretty advanced feature of Windows, and people who use them probably
aren't using the Network and Sharing Center to set up their network...
(except you ).

Keeping the permissions of FolderTarget and FolderSource in sync is actually
a hard problem. What happens if the pointer is offline (e.g., disk isn't
mounted) when the target's permissions are changed? When does the pointer's
permissions get updated? What if there are (say) 300 pointers to one target,
and you want to keep them all in sync -- where is the list of pointers
stored? (If the answer is "at the destination", then the destination can't
be read-only).

UNIX and friends solve this problem by simply ignoring the permissions on
the pointer -- all permission-checking is done at the destination. I don't
know enough about NTFS to say why junction points are implemented with
separate ACLs for the pointer and destination.



"John Myers" wrote:

> I have a strong feeling that the way junctions are being treated in NTFS
> needs to be revised. The issue I see is that, once I have created a junction
> from, say C:\FolderTarget pointing to D:\FolderSource, if I check permissions
> on C:\FolderTarget, I will see the permissions of that folder, NOT the ones
> of D:\FolderSource. Worse, if I change permission for C:\FolderTarget, none
> of these changes will be propagated to subfolders/files in D:\FolderSource.
>
> So, let's say I decide that I want to move my Public folders in Vista to a
> separate partition. No problem, I move the files over, and create a junction
> in C:\Users\Public pointing to the new location. HOWEVER, now Public Folder
> Sharing will not work anymore (not from the Network and Sharing Center,
> anyway): If I turn Public Folder Sharing on, then Vista will change
> permissions for C:\Users\Public accordingly, but since this has no effect on
> the permissions of the files at my new location, network users will not be
> granted access to any of the files. The only way to give users access to
> these files is to change file and sharing permissions of the source folder
> manually.
>
> I think what should be done is this: When I create a junction, the system
> should check if the source and target folders have identicakl permissions. If
> not, it should offer me to change permissions on either the source or the
> target folder so that they are identical. Then, if I change permissions on
> the target folder, permissions on the source folder should be changed in
> lockstep.
>
> Anybody with me on this one? Anybody care? ;-)
>
> ----------------
> This post is a suggestion for Microsoft, and Microsoft responds to the
> suggestions with the most votes. To vote for this suggestion, click the "I
> Agree" button in the message pane. If you do not see the button, follow this
> link to open the suggestion in the Microsoft Web-based Newsreader and then
> click "I Agree" in the message pane.
>
> http://windowshelp.microsoft.com/com...unts_passwords

> John, those are interesting suggestions. Keep in mind that junction points
> are a pretty advanced feature of Windows, and people who use them probably
> aren't using the Network and Sharing Center to set up their network...
> (except you ).

Heheh, I'm not really using it either. I am somewhat paranoid about security
(I have worked in that field for quite a while), so I don't, hmm, always
agree with the canned choices that something like Network and Sharing Center
gives me...

> Keeping the permissions of FolderTarget and FolderSource in sync is actually
> a hard problem. What happens if the pointer is offline (e.g., disk isn't
> mounted) when the target's permissions are changed?

That we should be able to handle: The logic would be the same as when the
junction is first created: Ask the user what he wants to do on reconnect, and
propagate the changes at that time, if so desired. Like you say, not too many
people will use junctions anyway, and those that do should be able to figure
out how to respond to such a prompt.

> When does the pointer's
> permissions get updated? What if there are (say) 300 pointers to one target,
> and you want to keep them all in sync -- where is the list of pointers
> stored? (If the answer is "at the destination", then the destination can't
> be read-only).

But, yes, these are good points...

> UNIX and friends solve this problem by simply ignoring the permissions on
> the pointer -- all permission-checking is done at the destination. I don't
> know enough about NTFS to say why junction points are implemented with
> separate ACLs for the pointer and destination.

Intuitively I do feel that the Unix choice is the right one, but otherwise I
am in the same boat as you with respect to why things are done the way they
are done in NTFS.

Nevertheless, I think this is a topic that somebody needs to think about at
Microsoft at some point, now that Vista actually does use these advanced file
system constructs (that have existed in NTFS for many years, of course). One
of the reasons I have stumbled over this is that on my own machines, I have
set up the OS using separate partitions for C:\Users & C:\ProgramData,
C:\Users\Public, and C:\Program Files, all implemented via junctions. That
setup makes a lot of sense for a number of reasons, but it does cause issues
because of Vista's incomplete awareness of junctions and other filesystem
constructs. For example, certain Windows updates create hardlinks between
files in subfolders of C:\Windows\WinSxS and files in C:\Program Files.
Needless to say, that doesn't go over well on my system, forcing me to
manually check the Pending.xml file for each update, and make appropriate
changes if necessary. SP1 is going to be interesting...

Anyway, thanks for your feedback! If you have any way to pass this on to the
people in charge of NTFS development, that would be great, too!

> One
> of the reasons I have stumbled over this is that on my own machines, I have
> set up the OS using separate partitions for C:\Users & C:\ProgramData,
> C:\Users\Public, and C:\Program Files, all implemented via junctions. That
> setup makes a lot of sense for a number of reasons, but it does cause issues
> because of Vista's incomplete awareness of junctions and other filesystem
> constructs. For example, certain Windows updates create hardlinks between
> files in subfolders of C:\Windows\WinSxS and files in C:\Program Files.

You're just begging for me to wave the "Not a supported configuration" flag,
aren't you?


>
> Anyway, thanks for your feedback! If you have any way to pass this on to the
> people in charge of NTFS development, that would be great, too!

Clicking on the vote button on this newsgroup has more say in these matters
than I do... I don't know anyone working on NTFS.