Bug 49114 - NTFS junction directories missing from directory listing
Summary: NTFS junction directories missing from directory listing
Status: RESOLVED LATER
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_dav (show other bugs)
Version: 2.2.13
Hardware: PC Windows Vista
: P2 major (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords: MassUpdate
Depends on:
Blocks:
 
Reported: 2010-04-13 20:45 UTC by ng
Modified: 2018-11-07 21:09 UTC (History)
1 user (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description ng 2010-04-13 20:45:49 UTC
If a directory made available through Apache WEB DAV module, contains folders / directories made / linked with NTFS junction, these folders are not shown in a directory listing.

I have really tried to figure out why, and as far I can tell it is because the function building the directory tree don't accept NTFS junctions as directories or any other kind of file for that matter.

Looking in the source code I found this some code in repos.c that might be responsible for building the directory tree.

else if (fsctx->info1.finfo.filetype == APR_DIR) {
            apr_size_t save_path_len = fsctx->path1.cur_len;
            apr_size_t save_uri_len = fsctx->uri_buf.cur_len;
            apr_size_t save_path2_len = fsctx->path2.cur_len;
...

== APR_DIR tells me that somewhere in the code APR_DIR is valid for normal folders but not for NTFS junctions... can that be changed or will it be possible to say something like this.

else if (fsctx->info1.finfo.filetype == APR_DIR || APR_NTFS_JUNCTION)..

Oh when activating the INDEXES option in a site config, the function generating the HTML to show the folder / file structure is able to show the directories made with NTFS junction. But I couldn't find that code, to see how it recognized directories made with NTFS junctions.
Comment 1 William A. Rowe Jr. 2010-04-13 20:51:11 UTC
Presuming there is no flaw, NTFS junctions are handled exactly as unix symlinks.
Of course a symlink may be to a file or directory, while NTFS junctions may
only resolve to a directory.

So if the information is gathered from an apr_file_stat, it should show as the
target of the junction, and if its gathered as an lstat, it would be a symlink.
Comment 2 ng 2010-04-15 02:04:37 UTC
(In reply to comment #1)
> Presuming there is no flaw, NTFS junctions are handled exactly as unix
> symlinks.
> Of course a symlink may be to a file or directory, while NTFS junctions may
> only resolve to a directory.
> 
> So if the information is gathered from an apr_file_stat, it should show as the
> target of the junction, and if its gathered as an lstat, it would be a symlink.

That comment riddle me a bit, if I have understood it correctly you are saying, that as the code is now, it should be able to return a NTFS junction as a directory. It is more a matter of me setting up Apache or NTFS junction correctly.

I have only read some of the source code for mod_dav, I haven't set up a prober build environment as I lack the skills to do so. I'll wish I could test and see how the code handles the NTFS junctions directories, when making a directory listing but having no previous experience in building Apache or writing C code I find that a bit hard. 

What I can tell you is that even though mod_dav doesn't accept my NTFS junction as directory when making a listing of the directory where the junction folder is. (long sentence sorry), I'm able to browse/copy/upload the contents of the junction folder, when writing the complete path in my web_dav client.
Comment 3 ng 2010-04-21 05:04:18 UTC
Are there any suggestion on how I can solve this problem??

If it is a change in Apcache config or the way I make NTFS junctions, are there anyone who would like to come with suggestions on how I go about that???
Comment 4 William A. Rowe Jr. 2018-11-07 21:09:22 UTC
Please help us to refine our list of open and current defects; this is a mass update of old and inactive Bugzilla reports which reflect user error, already resolved defects, and still-existing defects in httpd.

As repeatedly announced, the Apache HTTP Server Project has discontinued all development and patch review of the 2.2.x series of releases. The final release 2.2.34 was published in July 2017, and no further evaluation of bug reports or security risks will be considered or published for 2.2.x releases. All reports older than 2.4.x have been updated to status RESOLVED/LATER; no further action is expected unless the report still applies to a current version of httpd.

If your report represented a question or confusion about how to use an httpd feature, an unexpected server behavior, problems building or installing httpd, or working with an external component (a third party module, browser etc.) we ask you to start by bringing your question to the User Support and Discussion mailing list, see [https://httpd.apache.org/lists.html#http-users] for details. Include a link to this Bugzilla report for completeness with your question.

If your report was clearly a defect in httpd or a feature request, we ask that you retest using a modern httpd release (2.4.33 or later) released in the past year. If it can be reproduced, please reopen this bug and change the Version field above to the httpd version you have reconfirmed with.

Your help in identifying defects or enhancements still applicable to the current httpd server software release is greatly appreciated.