maindavfs2 - Support: sr #108566, Folders are empty when mounted...

 
 

sr #108566: Folders are empty when mounted Sharepoint folder has one or more letters of wrong case

Submitter:  Alex Jodidio <ajodidio>
Submitted:  Fri 09 May 2014 03:44:42 PM UTC
   
 
Category:  None Priority:  5 - Normal
Severity:  3 - Normal Status:  Done
Privacy:  Public Assigned to:  _71007
Open/Closed:  Closed Operating System:  GNU/Linux
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sat 24 May 2014 05:44:17 PM UTC, comment #11: 

Patch applied in CVS repository branch MAIN and branch rel-1-4-6.

Werner

- <_71007>
Fri 23 May 2014 06:45:20 PM UTC, comment #10: 

Thanks for the information.

I think I will include this patch in the next bugfix release. But maybe someday I will drop this test entirely.

Cheers
Werner

- <_71007>
Thu 22 May 2014 07:56:35 PM UTC, comment #9: 

Yes, the changes worked!

Here is where I used strcasestr() and strcasecmp() for davfs2 1.5.0, around line 1868 in webdav.c, in function prop_result():

    if (strcasestr(result->path, ctx->path) != result->path) {
        dav_delete_props(result);
        return;
    }

    if (strcasecmp(result->path, ctx->path) == 0) {
        result->name = ne_strdup("");

(Thank you)**2

Alex Jodidio <ajodidio>
Thu 22 May 2014 06:33:19 PM UTC, comment #8: 

Yes, using the case independent comparision functions should do the trick.
As there is only one instance of strstr and on instance strcmp to replace I will not need a patch. But please report whether it works as expected.

But there are other reasons why I want to drop this test (a more efficient and more clean processing and storing of pathes). I'm not yet sure what I'm going to do.

Cheers
Werner

- <_71007>
Wed 21 May 2014 09:40:52 PM UTC, comment #7: 

My vote would be NOT to drop the test but change the code slightly in string search and/or string comparison for a PROPFIND-response.

Instead of strstr(), it should be strcasestr(), and instead of strcmp(), it should be strcasecmp().

Since one is looking for a match starting from the beginning of a returned string, it should be a safe assumption that a difference in case is due to the (odd?) behavior of the server in treating URL subpaths.

We may consider modifying davfs2 source to handle this and if so will send you our code changes.

Thank you for help again.

Alex Jodidio <ajodidio>
Wed 21 May 2014 06:40:23 PM UTC, comment #6: 

Thanks for the information which explains what's going wrong so I won't need the PCAP-files.

davfs2 indeed checks the href-elements from the PROPFIND-response against the path from the request and drops entries when they do not match.

For different reasons I'm already considering to drop this test. But I'm not yet competely sure about this and I can't do it in the near future anyway. So you still have to work around by using the correct cases in the URL.

Of course SharePoint should not fool around with file names this way but always send canonical file names with the correct case. Seems that Microsoft is not yet clear about whether to use case sensitive or case insensitive file names, but runs some mixed mode with sometimes unespected results.

Cheers
Werner

- <_71007>
Tue 20 May 2014 09:49:12 PM UTC, comment #5: 

I need to clarify my previous comment.

The first response from Sharepoint to the PROPFIND from mount.davfs contains URL subpaths as specified in the mount command. However, subsequent responses contain the proper case for all letters in the URL subpath.

This probably explains why mount.davfs can see everything in the mounted folder but cannot see anything in its subfolders.

Alex Jodidio <ajodidio>
Tue 20 May 2014 09:31:01 PM UTC, comment #4: 

I think I identified the problem based on comparison of Wireshark captured packets for davfs2 and libneon.

Sharepoint seems to send back directory contents to mount.davfs in response to PROPFIND correctly but it uses the proper cases for all letters in the the URL path. That seems to trip mount.davfs because, I'm guessing, it must be looking for an exact match to the starting path as specified in mount.davfs command. Differences in case do not affect libneon.

I'm attaching the PCAP file where I observed the issue.

I used the following mount command:
mount -t davfs "http://sp2010-2:19571/Sites/alexJSite1/Subsite1" -o rw /Sharepoint1

while the proper spelling with correct case for all letters in the URL should be
"http://sp2010-2:19571/sites/AlexJSite1/subsite1"

If you would still like me to send you a similar PCAP file for our libneon tool, the source code for the tool, or mount.davfs log output I could send those too.

Thank you so much.

  -- Alex

(file #31408)

Alex Jodidio <ajodidio>
Mon 19 May 2014 08:02:55 PM UTC, comment #3: 

You say that the URL is the problem. But please note myFirstSite, sites and probably sp2010 are part of the path component of the URL. If you wand to access /mnt/A then the path is /sp2010/sites/myFirstSite/A. From the point of view of the HTTP-protocol there is no difference between 'A' and 'sites', they are both path components.

At the moment it looks like one of the strange things that SharePoint is well known for.

To see what is going on the best thing to do is this:

  • set options 'debug most' and 'debug http_body' (we need the body to see what file names SharePoint sends in its PROPFIND responses).
  • mount the file system.
  • issue 'ls' for one of the subdirectories (e.g. /mnt/A), Don't do more than this - the log files will be big enough.
  • unmount the file system.
  • send the entries that mount.davfs writes in your log files. You may send it to my private email address if you have any privacy concerns or the file is to big.



"BTW, libneon (http://www.webdav.org/neon) is not case-sensitive and succeeds in retrieval of files when letters are of wrong case in the URL path."
davfs2 uses Neon. And Neon is case sensitive, or to be more pricise: Neon does not change the case in the path-component of the URL. Case sensitivity or not is definitely decided by the server.

Neon is a library. Could you give an example of how you use Neon to access these files? And also an example of how you use Neon to get a listing of the files in a directory?

Another question:
Do the file and directory names contain spaces? If yes, this is a known SharePoint bug and there is a patch for Neon from another user that works araound the problem. You may look at
https://savannah.nongnu.org/support/?107114

Cheers
Werner


- <_71007>
Mon 19 May 2014 03:08:48 PM UTC, comment #2: 

Werner wrote (in comment #1):

> If your share point server uses case sensitive file names, which is the most common way servers behave, just use this file names and not something else. What's the problem with this?


The problem is NOT with file names but with the mounted URL. davfs2 succeeds in mounting when one or more letters are of the wrong case, e.g., sp2010/sites/myFirstSite instead of .../MyFirstSite. Thus initially it looks to the user as if everything is fine. In fact, all the files in the mounted directory can be accessed (e.g., if the mounted directory is /mnt, all files in /mnt can be accessed). It's only when one tries to access files in sub-directories that one discovers that all sub-directories are empty (e.g., if /mnt has sub-directories A, B, C, /mnt/A, /mnt/B, and /mnt/C are found to be empty even if in reality they contain files and/or sub-folders).

I take it it's not possible to add an option to davfs2 that would fail the mount when one of the letters in the URL has a wrong case, is that right?

BTW, libneon (www.webdav.org/neon) is not case-sensitive and succeeds in retrieval of files when letters are of wrong case in the URL path. (I don't know what it does internally, maybe it somehow figures out the proper case for all letters.)

Alex Jodidio <ajodidio>
Sun 18 May 2014 08:38:36 AM UTC, comment #1: 

No, there is no way, at least none that davfs2 would go. And I can't see the limitation.

File names on Unix-like systems have always been case sensitive.

Whether path names in HTTP are case sensitve depends on the interpretation by the server. There is nothing in HTTP that would demand them to be not case sensitive. Most servers will tread them as case sensitive. If share point does the same it's a good step away from old MS-DOS-nonsense.

davfs2 does not manipulate file names. It takes file names just as it gets them from the server.

If your share point server uses case sensitive file names, which is the most common way servers behave, just use this file names und not something else. What's the problem with this?

Werner

- <_71007>
Fri 09 May 2014 03:44:42 PM UTC, original submission:  

When we use davfs to mount Sharepoint 2010 sites, we noticed that all letters in the URL must have the correct case. If one or more of the letters have incorrect case, mount succeeds and one can access files in the mounted folder. However, all subdirectories under the mounted folder/site are empty.

Example: sp2010/sites/MyFirstSite will work fine but
sp2010/sites/myFirstSite will exhibit the problem.

Is there a way around this limitation?

This problem has been noticed by others, e.g., see
http://stackoverflow.com/questions/20970618/mounting-sharepoint-shares-using-davfs2-yelds-empty-folder

Alex Jodidio <ajodidio>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #31408:  davfs2.pcap added by ajodidio (40KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by _71007 (Posted a comment)
  • -email is unavailable- added by ajodidio (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-04-15 _71007 Open/ClosedOpen Closed
    2014-05-24 _71007 StatusPostponed Done
    2014-05-21 _71007 StatusIn Progress Postponed
    2014-05-20 ajodidio Attached File- Added davfs2.pcap, #31408
    2014-05-18 _71007 StatusNone In Progress
        Assigned toNone _71007

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code