apr-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 47630] NTFS directory junctions ("mounted folders") should be treated like n*x mount points (APR_DIR, not APR_LNK)
Date Tue, 04 Aug 2009 17:03:06 GMT

--- Comment #2 from Dan <dan_j_thompson@hotmail.com> 2009-08-04 10:03:03 PDT ---
(In reply to comment #1)
> Symbolic links on Unix are polymorphic, just as you described for Junctions.
> This behavior is by design.

No, I think reparse points are polymorphic. A junction is a specific type/usage
of a reparse point. Reparse points are used to implement a lot of things; see

> Unlike a unix mount point, a Junction is not a directory.  Unlike a unix
> mount point, rm is not used to remove the intersection of the file systems.

As far as I can tell, junctions are almost /exactly/ the same as unix mount
points, perhaps minus the restrictions on reparse points (like you can have
only 31 reparse points in a given path). Another term for a junction is a
"mounted folder". The MSDN documentation states that "Because mounted folders
are directories, you can rename, remove, move, and otherwise manipulate them,
as you would other directories."

> And like Unix symlinks, a Junction may refer to a nonexistent or invalid
> object.

The only case that I am aware of where a junction can refer to a nonexistent or
invalid target is if the volume that the junction refers to fails. I'm not sure
how unix could do anything different. This is what the documentation says (from
same page referenced earlier):

"If a volume fails, any volumes that have been assigned to mounted folders on
that volume can no longer be accessed through those mounted folders. For
example, suppose you have two volumes, C: and D:, and that D: is associated
with the mounted folder C:\MountD\. If volume C: fails, volume D: can no longer
be accessed through the path C:\MountD\."

Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

To unsubscribe, e-mail: bugs-unsubscribe@apr.apache.org
For additional commands, e-mail: bugs-help@apr.apache.org

View raw message