Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
I've been using davfs with a custom WebDAV server. When I try to access the modified time of a file while it's being read, I always get 0. The modified time reverts to its normal value after the read completes.
To reproduce, cat a large file:
% cat test18928.data
and ls -l from another terminal window:
% ls -l test18928.data
-rw-rw-r-- 1 ac davfs2 73144656 1969-12-31 19:00 test18928.data
The last modified time shows up as 12:00 AM 1/1/1970 (+/- your local GMT offset).
Is anyone else seeing this?
- what version of davfs2 do you use?
- what did "ls -l test18928.data" show, before you tried to read or write for the first time?
davfs2 gets the modified time from the server. Are you sure, the "custom WebDAV server" sends the correct information in standard comforming format?
You may set options "debug http" and "debug httpbody" in davfs2.conf, to see what is sent by the server. Responses to PROPFIND are of special interest.
Thanks for your quick response. I'm using davfs2 version 1.3.0 with neon version 0.26.4, both built from sources. When the file test18928.data isn't being read, ls -l shows "-rw-rw-r-- 1 ac davfs2 73144656 2008-04-24 16:28 test18928.data", which is what I'd expect.
I ran a second set of tests with "debug http" and "debug httpbody" enabled. The date string returned by the WebDAV server is the same before the cat command starts and during its execution. Here's a sample from the messages file (the test file this time is called data.dat.0):
Apr 27 13:00:30 cyclegrid4 mount.davfs: ops/"/><D:getetag/></D:prop><D:status>HTTP/1.1 404 Not Found</D:status></D:propstat></D:response><D:response><D:href>http://127.0.0.1:8000/tfstest1/data.dat.0</D:href><D:propstat><D:prop><D:displayname>data.dat.0</D:displayname><D:resourcetype/><D:getlastmodified>Fri, 25 Apr 2008 20:53:45 GMT</D:getlastmodified><D:getcontentlength>26214400</D:getcontentlength></D:prop><D:status>HTTP/1.1 200 OK</D:status></D:propstat><D:propstat><D:prop><D:creationdate/><executable xmlns="http://apache.org/dav/props/"/><D:
I could also send you to whole file if it helps.
the whole file would be very big, as it includes the content of a 26 MByte file. Please set 'debug most' (no debug httpbody) and redo the test. I would then need the whole file, including all upcalls from the kernel and all HTTP-requests, not only the PROPFIND-request. There should be e.g. a GET-request too.
I just sent you the log file at your users.sourceforge.net address. Please let me know if you need additional info.
your server does not send the Last-Modified-Header in response to a GET-request. davfs2 needs this header to calculate mtime, and sets mtime 0 if it gets no information from the server.
> Sending request headers:#012GET /test/file.dat HTTP/1.1#015#012
User-Agent: davfs2/1.3.0 neon/0.26.4#015#012
> Sending request-line and headers:
> Request sent; retry is 1.
> [status-line] < HTTP/1.1 200 OK#015
> [hdr] Pragma: no-cache#015
> Header Name: [pragma], Value: [no-cache]
> [hdr] Cache-Control: no-cache#015
> Header Name: [cache-control], Value: [no-cache]
> [hdr] Transfer-Encoding: chunked#015
> Header Name: [transfer-encoding], Value: [chunked]
> [hdr] Server: Jetty(6.1.x)#015
> Header Name: [server], Value: [Jetty(6.1.x)]
> [hdr] #015
> End of headers.
You might argue, the server send Last-Modified in response to the PROPFIND. But it might have changed in between. It is important to get the Last-Modified-Date together with the file, as it might be used for cache validation. In case of your server, which does not support Etag, it is the only information available for cache validation.
As HTTP-Header "Last-Modified" and WebDAV-property "getlastmodified" are the same bit of information, it is inconsequent and confusing, to send one and omitt the other.
BTW: Are you sure about "Pragma: no-cache" and "Cache-Control: no-cache"? davfs2 will ignore this headers and cache the file anyway.
BTW again: Your server does not even send the "Date"-Header. This header is a MUST in HTTP.
Thanks a lot for taking the time to read through the log file. Your diagnostic was spot on! I changed the server to set the Last-Modified header in the GET response, and was happy to find that the issue went away. While I was at it, I also added the Date header in all responses, and removed the no-cache headers. I had inserted them to try to work around some issues with Microsoft's mini-redirector client, but ended up concluding that it was hopelessly broken no matter what. Thanks again for your help!