For testing, I have an alias called /C that points to "C:\Documents and Settings\". I keep my profile directory on a separate disk that is mounted under "C:\Documents and Settings\Sam". However, the Sam\ folder does not appear in Apache's directory listing. Additionally, while the directory listing is being generated, this appears in the error.log: [Fri Apr 12 14:33:05 2002] [error] [client 127.0.0.1] symlink doesn't point to a file or directory: C:/Documents and Settings/Sam Asking for anything under "http://localhost/C/Documents and Settings/Sam" manually throws a 403 back to the client, with the same error in the event log. If I remove the "FollowSymLinks" option for the directory then the error message is instead: [Fri Apr 12 14:41:29 2002] [error] [client 127.0.0.1] Symbolic link not allowed: C:/Documents and Settings/Sam and a 403 is still returned to the browser.
Please don't submit to the bug database and post to the newsgroup at the same time. You may reopen this report if you don't get a response within a few days on the newsgroup.
Reopening, with more information: Snippet from httpd.conf: Alias /C "C:/" <Directory "C:/"> Options Indexes FollowSymLinks MultiViews AllowOverride None Order allow,deny Allow from all </Directory> Requesting http://localhost/C/Documents%20and%20Settings/ returns a listing of the directory, but with the expected "Sam/" entry (C:\Documents and Settings\Sam\ is actually a mount point) omitted. Instead, "[error] [client 127.0.0.1] symlink doesn't point to a file or directory: C:/Documents and Settings/Sam" appears in the error log. Requesting http://localhost/C/Documents%20and%20Settings/Sam/, or anything inside of it, returns a 403 error and likewise adds "[error] [client 127.0.0.1] symlink doesn't point to a file or directory: C:/Documents and Settings/Sam" to the error log. Requesting http://localhost/C/Documents%20and%20Settings/All%20Users/ or any of the other links from the directory listing works as it should. After doing some reading, it appears that what Apache calls symlinks on Windows are actually NTFS Junctions; most junctions have a target of a regular pathname (such as "C:\Target\"), but the mount point junctions Windows uses have a target in the form of "\\?\Volume{90b9a960-b928-11d5-bbf2-806d6172696f}\" (the classid is the volume's unique identifier). The error message suggests that Apache is checking the junction target to see if it is a valid path (which the mount point junction target is not) and throwing the error. So it seems the problem lies within the code that Apache uses to check the symlink/juntion target.
This is fixed in the current 2.0.36-dev tree, and will be part of the next 2.0.36 release we expect to roll out within a week or so. Thanks for your report, your detailed examples, and for adopting Apache 2.0!
The precise behavior noted in the original bug still occurs in 2.0.44 on UNC (remote share) paths under Win2K Server or Win2K3RC2: Alias /nas/junction/dir1/dir2/ "//192.168.0.10/nas/junction/dir1/dir2/" <Directory "//192.168.0.10/nas/junction/dir1/dir2"> Options Indexes FollowSymLinks AllowOverride None Order allow,deny Allow from all </Directory> [Thu Mar 27 22:24:03 2003] [error] [client 67.67.67.117] Forbidden: //192.168.0.10/nas/junction doesn't point to a file or directory If FollowSymLinks is turned off, then: [Thu Mar 27 23:24:07 2003] [error] [client 67.67.67.117] Symbolic link not allowed: //192.168.0.10/nas/junction Either way, with indexing turned on and using the following mapping, Apache browses the directory fine, and generates an index, but does not see ANY of the junctions: Alias /nas/ "//192.168.0.10/nas/" <Directory "//192.168.0.10/nas"> Options Indexes FollowSymLinks AllowOverride None Order allow,deny Allow from all </Directory> It sees regular folders and files just fine. NFTS can create at least two common types of junctions. One is the MountVol target format shown in Sam's bug report, and the other is a path reference as created with "linkd.exe" from Win2K Resource Kit. The above behavior is observed with BOTH types. I have rated this as MAJOR because without fixing this, Apache cannot be used to serve content from servers in a web farm that all work from a NAS server that mounts many RAID arrays using the "MountVol" or "LinkD" method. While the LinkD method is uncommon, the MountVol method is offered in default Windows GUI Drive Management on volume creation, and is a common way to add new volumes into an existing path structure.
I'm not 100% this fixes the issue mentioned at http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8014 though I tried to reproduce the issue as I understood it. If one of the bug submitters could test it that would be great. Bill, if you could verify that this change is reasonable I would appreciate it, the 'wanted' thing is a little vague to me. --- filestat.c.orig Fri Mar 7 14:21:29 2003 +++ filestat.c Fri Mar 28 07:16:02 2003 @@ -363,7 +363,8 @@ finfo->size = 0x7fffffff; #endif - if (wininfo->dwFileAttributes & FILE_ATTRIBUTE_REPARSE_POINT) { + if (wanted & APR_FINFO_LINK && + wininfo->dwFileAttributes & FILE_ATTRIBUTE_REPARSE_POINT) { finfo->filetype = APR_LNK; } else if (wininfo->dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY) { /kristofer
Reopen to get this on the radar. Bill? your turn ;-)
This was fixed in 2.0.45. Please upgrade, and if the problem persists, please reopen the bug with the new error log entries and observations.
I stand corrected; that patch wasn't committed. Now committed as of apr/file_io/win32/filestat.c revision 1.79, and I expect you will see this in the forthcoming Apache 2.0.46.