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 Wed, 05 Aug 2009 04:33:21 GMT

--- Comment #4 from Dan <dan_j_thompson@hotmail.com> 2009-08-04 21:33:16 PDT ---
(In reply to comment #3)
> Understand that a unix mount point *is a directory*.

But... for all intents and purposes, a junction is just as much of a directory:
The MSDN documentation states that "Because mounted folders
are directories, you can rename, remove, move, and otherwise manipulate them,
as you would other directories."

> That's what the filesystem sees. The driver handles those mounts,
> not the filesystem.

NTFS is not a driver? Anyway, I don't think the implementation matters (it does
not matter where in the driver stack it is implemented, nor does it matter
whether a mount point is recorded in fstab or filesystem metadata); I think
that windows junctions are the moral equivalent of unix mount points. For the
purposes of creating a portable runtime, they should be treated the same.

> Unix also allows symlinks to point to other directories.

Windows also allows symlinks (distinct from junctions) to point to other
directories. Windows junctions and windows symlinks-to-directories are two
different things. Just like unix mount points and unix symlinks are different

> Similarly, Windows allows any driver to register a mount without the existence
> of a Junction.

I don't know how that is accomplished; if you happen to know how, I would be
interested in that.

> The Junction is a filesystem entity, not a driver entity.
> Junctions allow the user to point any directory at another.
> junction.exe dir1 alias1
> is completely valid.  rd dir1 and you will find alias1 is broken.  There is no
> distinction in the filesystem driver between a junction to another directory 
> on the same volume, or a junction to another volume.

As of Linux 2.4.0 (I don't know about other unices), it is possible to remount
part of the file heirarchy somewhere else ("mount --bind olddir newdir"). I
don't know where in the driver stack that is implemented, but again, for the
purposes of creating a portable runtime, I don't think that matters.

> You did not answer my question of whether you are seeing these entities as
> directories when APR_FINFO_LINK is omitted from the apr_file_info_get flags.

Sorry, I have not had time to test that. But I don't think it is relevant to
this bug; the point of this bug is that NTFS junctions are the moral equivalent
of unix mount points and should be treated as such by the APR.

For instance, if you go into the Disk Management tool (right-click Computer,
choose "manage", then drill into Storage-->Disk Management in the navigation
heirarchy), and you choose to mount a partition somewhere (this is the windows
GUI version of "mount"), it will create a junction. (Not a directory symlink,
and not some sort of special non-junction mount point that you refer to above.)

If I do find a problem with APR_FINFO_LINK and apr_file_info_get in the future,
I will be sure to open a separate bug for that issue.

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