Davfs 2.1 / 2.2 Filenames not showing correct

  • kevinm

    kevinm - 2007-07-17


    I had this problem in the previous version, have recently installed the new version, and am picking up the same problem.
    When I do a ls on the mounted directory, random filenames will show up incorrectly. If I clear the cache, then they show up correctly again. The filename in the cache is correct. And it has done it several times on the same project with random files.

    The debug output with debug = most, does not give any helpfull information at all.

    The config I have is as follows:
    davfs.conf file:
    dav_user        nobody
    dav_group       nobody

    ignore_home     1                 # system wide config file only
    kernel_fs       fuse
    buf_size        128                 # KiByte

    # WebDAV Related Options
    # ----------------------
    ask_auth        0
    use_locks       0
    gui_optimize    0
    use_displayname 0

    read_timeout    5                # seconds
    retry           5                # seconds

    # Cache Related Options
    # ---------------------

    backup_dir      lost+found
    cache_size      50000             # MiByte
    table_size      2048              # 1024
    idle_time       30                # seconds
    dir_refresh     60                # seconds
    file_refresh    1                 # second
    debug           most


    The mounted directory Listing:
    Mounted Directory:
    [root@devaccess ~]# ls /home/davfs/automount/websitedevelopment.com/sites/all/modules/weather/
    CHANGELOG.txt  INSTALL.txt  places.php  weather.info     weather_parser.inc
    helper.js      LICENSE.txt  po          weather.install
    images         odes.inc     README.txt  weather.module

    *** the above file "odes.inc" should actually be: "icao_codes.inc", there is no "odes.inc" file
    *** And if I edit the above file("odes.inc"), it actually updates the webdav "icao_codes.inc" file correctly.
    *** And the revisions are updated correctly as well.

    The specific Cache directory listing:
    collapse.js-CcTmkN                      dir-jstools-b4oAaV             icao_codes.inc-mSJ2zj                     README.txt-l4Ps4X                       collapsiblock.info-MQhqiD      dir-legacy-p65Wfa             
    icons.css-wm8Cjs                        README.txt-NdcC4y

    *** as we can see here, the file is displayed correctly, "icao_codes.inc-mSJ2zj"
    *** The last piece I am assuming is part of the caching naming.

    The webdav Directory listing:
    Revision 1339: /sites/all/modules/weather
        * ..
        * CHANGELOG.txt
        * INSTALL.txt
        * LICENSE.txt
        * README.txt
        * helper.js
        * icao_codes.inc
        * images/
        * places.php
        * po/
        * weather.info
        * weather.install
        * weather.module
        * weather_parser.inc
    Powered by Subversion version 1.4.2 (r22196)

    *** and on the subversion listing, the actual file "icao_codes.inc"

    If there is any more information needed, let me know please.
    thank you in advance.

    • Werner Baumann

      Werner Baumann - 2007-07-17

      Thanks for the report.

      To track down the bug, I would ask you to do some further tests:

      1. In every cache directory there is a file called "index". You might look for an entry for the "icao_codes.inc" or "odes.inc" file and check whether the path, name and cache_path elements are ok.

      Probably they are ok. So test

      2. While mount.davfs is running, it creates temporary files with directory listings. They start with dir-. These files are in binary format, but it should be save to read them with less and you can check wether filenames are ok. If the names are ok, there might be an error in the binary data. You would have to send the file, so I can check the binary data.

      If index and directory file seem to be ok, there might be some misunderstanding between mount.davfs and the kernel interface:

      3. Try "kernel_fs coda". Is there the same problem?

      4. Try "debug kernel" (with "kernel_fs" fuse again). This will create a log entry for each upcall from the kernel. The "FUSE_GETATTR" upcalls will show the file name, as it is known by the fuse kernel modul.

      I just created a file "icao_codes.inc" on a local apache server and mounted with davfs2. The  bug does not show.
      Maybe there is some problem with character encoding. What is the local character encoding on your system? Do you know of any character set preferences/translations done on the server? If tests 1 to 4 all look ok, you might use wireshark to fetch the response on a PROPFIND and inspect the href-property. It should be plain ascii (the encoding for "icao_codes.inc" is the same in ascii and utf-8).


    • kevinm

      kevinm - 2007-07-19

      incorrect displayed file-name: hp

      index file:
                  <d:path>/adserver/lib/max/other/lib- acl.inc.php</d:path>

      and the following file as well:

      filename: lib-acl.inc.php
      shows as: hp
      index file entry:


      The dir file is as follows (dir-other-Tciz7B):
      H<E0>b  ^@^@^@^@ ^@^@^@^@^@^@^@^A^@^@^@^D^@^@^@.^@^@^@^@^@^@^@<B8><D9>b ^@^@^@^@@^@^@^@^@^@^@^@^B^@^@^@^D^@^@^@..^@^@^@^@^@^@^X<B7>g    ^@^@^@
      ^@`^@^@^@^@^@^@^@^G^@^@^@^D^@^@^@capping^@<F8><91>g       ^@^@^@^@<88>^@^@^@^@^@^@^@      ^@^@^@^H^@^@^@stats.php^@^@^@^@^@^@^@<A8><E9>b  ^@^@
      ^@^@<B0>^@^@^@^@^@^@^@^N^@^@^@^H^@^@^@ lib-db.inc.php ^@^@`<E8>b      ^@^@^@^@<D8>^@^@^@^@^@^@^@^N^@^@^@^H^@^@^@lib-io.inc.php^@^@^@<E7>b     ^@
      ^@^@^@^H^A^@^@^@^@^@^@^T^@^@^@^H^@^@^@lib-warnings.inc.php^@^@^@^@<C0><E5>b   ^@^@^@^@(^A^@^@^@^@^@^@^B^@^@^@^H^@^@^@hp^@^@^@^@^@^@x<E4>b   
      ^@^@^@^@P^A^@^@^@^@^@^@^O^@^@^@^H^@^@^@lib-geo.inc.php^@P<E3>b  ^@^@^@^@p^A^@^@^@^@^@^@^H^@^@^@^H^@^@^@html.php^@<E2>b  ^@^@^@^@<A0>^A^@^@^@^@
      ^@^@^S^@^@^@^H^@^@^@lib-userlog.inc.php^@^@^@^@^@<A8><E0>b        ^@^@^@^@<C8>^A^@^@^@^@^@^@
      dir-other-Tciz7B (END)

      I can not seem to find the entry for the file in that lot.

      I have tried it with the coda setting as well, with no difference, I have enabled the debug kernel option, but for some reason I am not seeing any debug messages anywhere, maybe I missed something.

      And the encoding of the mount machine and the repository server are the same, as they are the same machine.
      which as far as I can tell is set to UT

    • Werner Baumann

      Werner Baumann - 2007-07-19

      The information you sent shows, that mount.davfs *consistently* names the file 'hp'.
      So the problem arises when it reads and interprets the data from the server response. You usually get this, when the server sends the WebDAV-property 'displayname'.

      As you set 'use_displayname 0' in the configuration file, this seems impossible, or a davfs2 bug. But did you use the correct configuration file?

      There is a systemwide config file /etc/davfs2/davfs2.conf or /usr/local/etc/davfs2/davfs2.conf.

      And for every user, that mounts davfs2 file systems, there is a file ~/.davfs2/davfs2.conf.

      But note:
      When you mount as *root*, only the system wide configuration file is used. The configuration files in a users home directory are only used, when this is the *mounting* user, i.e. when this user invokes the mount program.

      The cache directory shows that you probably mounted as root, so only options in the system wide configuration file are recognized. Options in /home/davfs2/.davfs2/davfs2.conf have no effect, as davfs2 is not the mounting user. That's probably the reason, why 'use_displayname 0' and 'debug most' are ignored.


      • kevinm

        kevinm - 2007-07-20

        Hi There,

        Thank you for your response.

        I am only using the system wide configuration. Due to permission problems with sharing of the mounted files through samba and http, the only way I found to work was to mount as root, but force the user davfs, and I made the user davfs part of the group nobody, as the http, and samba both are running as nobody. I then have the files mounted in the /home/davfs/automount/[projectname], then create links to them from the relevant shared directories. "debug most" does work, and I do get pages, and pages of messages, though as far as I can see none of it relating to the kernel. It is the option "debug kernel" that does not seem to work, if I understood it correctly from previous text, there is an option "debug kernel"?.

        And the naming is not consistant. If I clear the cache, that same file that previously was showing up incorrectly, shows up correctly again. As I was trying to convey, it randomly displays a file name incorrectly, meaning that it will not necessarily be the same file again. Thus far, I have not had the same file incorrectly named again after clearing the cache. After clearing the cache that file name does display correctly, however it will have another random file not showing.

        I am currently in the process of upgrading the drives on that machine, and switching over to a different file system, namely xfs, just to rule out any possibility of it been a file system error. Even though It does not seem to be a file system error, as the physical file is there, and edits to the file are updated correctly to the webdav. It updates the correct webdav file, even though the displayed file name is incorrect. Therefore, it does not seem likely to be interpreting the file incorrectly from the webdav, if I am not mistaken, if it did interpret the file incorrectly from the webdav, it would be trying to update the wrong file on the webdav.


    • Werner Baumann

      Werner Baumann - 2007-07-20

      In the example you have given, the file is always named 'hp'.
      As you may have noticed in the index file, mount.davfs stores the path (on the servers) and the name separately.
        <d:path>/adserver/lib/max/other/lib- acl.inc.php</d:path>
      So whatever the 'name', to contact the server it will use the 'path'. WebDAV is designed to allow for displaying another name than the path from the server. The displayname-property is just for this.

      The name is taken from the servers response to a PROPFIND request
      - either from the last segment of path (href-property)
      - or from the displayname-property.

      So to track down the problem, we have to look at the servers response to PROPFIND and what mount.davfs makes of this.
      There is one extra space in the path in this example. It may result from copying, but it may also indicate a serious problem with the response from the server.

      The only way I see, is to closely look at the response and how mount.davfs interprets it. Please use options
        debug most
        debug httpbody
      and run 'ls' on a directory that contains wrong file names. The debug output will be really huge.
      Please also note, that the debug output starts with the commandline and lists all the options, recognized by mount.davfs. This information is essential too.


    • Werner Baumann

      Werner Baumann - 2007-07-20

      There is another curiosity:

      <d:path>/adserver/lib/max/other/lib- acl.inc.php</d:path>



      Different hostname, different mount point, different cache, but the same file name, almost the same path (except that extra space), the same etag and the same *random* string *BFuBaa*? The probability for this is about 1 : 100 000 000 000.


    • Werner Baumann

      Werner Baumann - 2007-07-21

      Due to a bug in the log_writer function the debug output of the HTTP-body is garbeled. The bug is fixed in CVS.
      But to see exactly (octet by octet) what the server is sending, before davfs2 or neon process it, it would be better to use tcpdump or wireshark anyway.



Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks