Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

Davfs1,2.1 incorrectly displaying characters

TGS
2007-04-27
2013-04-16
  • TGS
    TGS
    2007-04-27

    After successfully mounting to my webDAV server everything seems to work fine but some directories have their entries messed up:

    drwxr-xr-x  2 root root 176 Apr  3 15:40 .
    drwxr-xr-x  5 root root 192 Apr  5 16:27 ..
    -rw-r--r--  1 root root  28 Apr  3 15:30 New Text Document.txt
    -rw-r--r--  1 root root  28 Apr  3 15:41 敎⁷敔瑸䐠捯浵湥㉴琮瑸

    The real directory listing looks like this:

    New Text Document.txt     4/3/07 3:30:35 PM EDT     28
    New Text Document2.txt     4/3/07 3:41:17 PM EDT     28

    As you can see it's not a character-set issue since there are no funny characters being passed. This error did not seem to occur with any earlier version release of davfs.

     
    • Werner Baumann
      Werner Baumann
      2007-04-27

      Hello,

      the garbage looks like:
      the ascii-string 'New Text Document2.txt' has been treated as UTF-16 and converted into UTF-8. This might happen if

      - the server sends the WebDAV displayname-property, containing this file name in ascii (or utf-8)
      - mount.davfs (i.e neon) thought the XML-body is encoded in UTF-16
      - your local character encoding is UTF-8

      To see what is really happening, please try:

      - set option 'use_displayname 0' in your davfs2.conf. This will force mount.davfs to get the filenames from the URL, not the displayname.
      - do not set any 'server_charset'-option in davfs2.conf

      Now the filenames should be displayed correct. If not please tell me.

      If the filenames are now correct:

      - set option displayname 1
      You now should get the old garbage again. If this is the case, you might capture the HTTP-traffic. I need the response to a PROPFIND request for this directory. Please do not edit it in any way. The exact octet stream from the http-traffic must be preserved.

      If you get garbage without displayname too, the same log of the http-traffic would be useful. It would also be useful to know whether you use the binary package (there might be a library mismatch) or compiled on your system.

      Cheers
      Werner

       
    • TGS
      TGS
      2007-04-30

      Changing the "displayname" setting didn't seem to work. Here's the trace:

      PROPFIND /users/alextara/new%20directory/ HTTP/1.1
      Content-Length: 324
      Content-Type: application/xml

      <?xml version="1.0" encoding="utf-8"?>
      <propfind xmlns="DAV:"><prop>
      <displayname xmlns="DAV:"/>
      <getetag xmlns="DAV:"/>
      <getcontentlength xmlns="DAV:"/>
      <creationdate xmlns="DAV:"/>
      <getlastmodified xmlns="DAV:"/>
      <resourcetype xmlns="DAV:"/>
      <executable xmlns="http://apache.org/dav/props/"/>
      </prop></propfind>

      HTTP/1.1 207 Multi-Status
      Content-Type: text/xml;charset=UTF-8
      Content-Length: 2351

      <?xml version="1.0" encoding="utf-8" ?>
      <D:multistatus xmlns:D="DAV:" xmlns:XS="http://www.w3.org/2001/XMLSchema" xmlns:XSI="http://www.w3.org/2001/XMLSchema-instance" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns-138="http://apache.org/dav/props/">
      <D:response>
      <D:href>http://pilotsgdxythosip.concordia.ca:8080/users/alextara/new%20directory/New%20Text%20Document.txt</D:href>
           <D:propstat>
              <D:prop>
      <D:displayname><![CDATA[New Text Document.txt]]></D:displayname>
      <D:getetag><![CDATA["1105-1107"]]></D:getetag>
      <D:getcontentlength>28</D:getcontentlength>
      <D:creationdate>2007-04-03T19:30:35Z</D:creationdate>
      <D:
      getlastmodified>Tue, 03 Apr 2007 19:30:35 GMT</D:getlastmodified>
      <D:resourcetype></D:resourcetype>
            </D:prop>
             <D:status>HTTP/1.1 200 OK</D:status>
           </D:propstat>
           <D:propstat>
              <D:prop>
      <ns-138:executable/>
            </D:prop>
             <D:status>HTTP/1.1 404 Not Found</D:status>
           </D:propstat>
      </D:response>
      <D:response>
      <D:href>http://pilotsgdxythosip.concordia.ca:8080/users/alextara/new%20direc
      tory/New%20Text%20Document2.txt</D:href>
           <D:propstat>
              <D:prop>
      <D:displayname><![CDATA[New Text Document2.txt]]></D:displayname>
      <D:getetag><![CDATA["1104-1107"]]></D:getetag>
      <D:getcontentlength>28</D:getcontentlength>
      <D:creationdate>2007-04-03T19:26:06Z</D:creationdate>
      <D:getlastmodified>Tue, 03 Apr 2007 19:41:17 GMT</D:getlastmodified>
      <D:resourcetype></D:resourcetype>
            </D:prop>
             <D:status>HTTP/1.1 200 OK</D:status>
           </D:propstat>
           <D:propstat>
              <D:prop>
      <ns-138:executable/>
            </D:prop>
             <D:status>HTTP/1.1 404 Not Found</D:status>
           </D:propstat>
      </D:response>
      <D:response>
      <D:href>http://pilotsgdxythosip.concordia.ca:8080/users/alextara/new%20directory/</D:href>
           <D:propstat>
              <D:prop>
      <D:displayname><![CDATA[new directory]]></D:displayname>
      <D:creationdate>2007-04-03T19:25:18Z</D:creationdate>
      <D:getlastmodified>Tue, 03 Apr 2007 19:40:48 GMT</D:getlastmodified>
      <D:resourcetype><D:collection/></D:resourcetype>
            </D:prop>
             <D:statu
      s>HTTP/1.1 200 OK</D:status>
           </D:propstat>
           <D:propstat>
              <D:prop>
      <D:getetag/><D:getcontentlength/><ns-138:executable/>
            </D:prop>
             <D:status>HTTP/1.1 404 Not Found</D:status>
           </D:propstat>
      </D:response>
      </D:multistatus>

       
    • Werner Baumann
      Werner Baumann
      2007-04-30

      Hello,

      the HTTP-traffic looks fine. Pathnames in the href-property are plain ascii and there is no essential difference between the two file names. So it's really curious.

      I suggest this steps:

      1. If you are using version 1.2.0, please update to version 1.2.1. There are bugs in 1.2.0 that might explain this behaviour, but only if either displayname is used or a server_charset is set. And I have no explanation why the two filenames are treatet different.

      2. Review configuration files:
      In my last post I mixed up 'use_displayname' and 'displayname'.
      To switch of the displayname-property, the correct configuration option is
      'use_displayname 0'
      Also be sure that you have no server_charset option set. If mounting as non-root user there is an additional davfs2.conf in the users home directory ~/.davfs2/davfs2.conf.

      3. Delete the cache:
      Allthough information from the server should overwrite cached information, just to be sure, cached information should be deleted. There is a cache-directory for every mount. The directory names are built from url, mountpoint and username. The cache may be in /var/cache/davfs2 or ~/.davfs2/cache. You can just delete the cache directory for this mount, or even the comple davfs2-cache (it will be rebuilt).

      If the filenames are still garbage, there is propably some more bug in davfs2. Debug messages would be helpful then:
      Please configure the package with option --enable-debug, then do 'make' and 'make install'. 'make install' will replace the system wide configuration file, but make a backup of the old one.
      There should be a lot of messages from mount.davfs in one of your log files (syslog on Debian, but its different on different systems).

      In case in works now:
      The displayname property just contains the last component of the path (many servers do this). So it is useless and you should turn it off anyway.

      Cheers
      Werner

       
    • TGS
      TGS
      2007-05-01

      1. I am using 1.2.0. I'll try with the newer version and report back.
      2. I figured that's what you meant. The option I was changing was the correct one.
      3. Will do.

       
    • TGS
      TGS
      2007-05-01

      The new version seems to have fixed the issue entirely. Thank you.