I changed permissions on my webdav servers folder with chmod and chown. Now all files returned have the wrong creationdate. I use the webdav server in a windows app for my clients to backup and restore files. Now the clients shows the wrong date for all backups because I show the creationdate this is what is returned <lp1:creationdate>2020-11-12T07:02:01Z</lp1:creationdate> but that's not the expected result (see output below) A possible reason could be that stat does not show the birth date. https://askubuntu.com/questions/918300/when-is-birth-date-for-a-file-actually-used https://unix.stackexchange.com/questions/50177/birth-is-empty-on-ext4/131347 ### output of stat stat ./backup.zip File: ./backup.zip Size: 20234077 Blocks: 39520 IO Block: 4096 regular file Device: 6620b6e1h/1713420001d Inode: 61214357 Links: 1 Access: (0770/-rwxrwx---) Uid: (10001/user) Gid: ( 1008/group) Access: 2020-11-11 23:46:05.827618160 +0100 Modify: 2020-10-12 07:50:52.910941633 +0200 Change: 2020-11-12 08:02:01.492212852 +0100 Birth: - ### output of debugfs for inode 61214357 debugfs -R 'stat <61214357>' /dev/ploop26158p1 Inode: 61214357 Type: regular Mode: 0770 Flags: 0x80000 Generation: 585915609 Version: 0x00000000:00000001 User: 10001 Group: 1008 Size: 20234077 File ACL: 0 Links: 1 Blockcount: 39520 Fragment: Address: 0 Number: 0 Size: 0 ctime: 0x5facdde9:755a49d0 -- Thu Nov 12 08:02:01 2020 atime: 0x5fac69ad:c551cdc0 -- Wed Nov 11 23:46:05 2020 mtime: 0x5f83eebc:d92f7704 -- Mon Oct 12 07:50:52 2020 crtime: 0x5f83eeab:bd410660 -- Mon Oct 12 07:50:35 2020 Size of extra inode fields: 28 EXTENTS: (0-511):287372288-287372799, (512-1023):287354880-287355391, (1024-4095):287360000-287363071, (4096-4939):287350784-287351627 ### curl command to test the propfind result curl -u user:pass -i -X PROPFIND https://domain.tld/ --upload-file - -H "Depth: 1" <<end <?xml version="1.0" encoding="utf-8" ?><propfind xmlns="DAV:"><allprop/></propfind> end ### propfind result HTTP/1.1 100 Continue HTTP/1.1 207 Multi-Status Date: Thu, 12 Nov 2020 07:23:27 GMT Server: Apache X-Powered-By: PleskLin Content-Length: 1641 Content-Type: text/xml; charset="utf-8" <?xml version="1.0" encoding="utf-8"?> <D:multistatus xmlns:D="DAV:" xmlns:ns0="DAV:"> <D:response xmlns:lp2="http://apache.org/dav/props/" xmlns:lp1="DAV:"> <D:href>/</D:href> <D:propstat> <D:prop> <lp1:resourcetype><D:collection/></lp1:resourcetype> <lp1:creationdate>2020-11-12T07:02:01Z</lp1:creationdate> <lp1:getlastmodified>Mon, 12 Oct 2020 05:50:52 GMT</lp1:getlastmodified> <lp1:getetag>"1000-5b172e19a0d5d"</lp1:getetag> <D:supportedlock> <D:lockentry> <D:lockscope><D:exclusive/></D:lockscope> <D:locktype><D:write/></D:locktype> </D:lockentry> <D:lockentry> <D:lockscope><D:shared/></D:lockscope> <D:locktype><D:write/></D:locktype> </D:lockentry> </D:supportedlock> <D:lockdiscovery/> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> <D:response xmlns:lp2="http://apache.org/dav/props/" xmlns:lp1="DAV:"> <D:href>/backup.zip</D:href> <D:propstat> <D:prop> <lp1:resourcetype/> <lp1:creationdate>2020-11-12T07:02:01Z</lp1:creationdate> <lp1:getcontentlength>20234077</lp1:getcontentlength> <lp1:getlastmodified>Mon, 12 Oct 2020 05:50:52 GMT</lp1:getlastmodified> <lp1:getetag>"134bf5d-5b172e19a0d5d"</lp1:getetag> <lp2:executable>T</lp2:executable> <D:supportedlock> <D:lockentry> <D:lockscope><D:exclusive/></D:lockscope> <D:locktype><D:write/></D:locktype> </D:lockentry> <D:lockentry> <D:lockscope><D:shared/></D:lockscope> <D:locktype><D:write/></D:locktype> </D:lockentry> </D:supportedlock> <D:lockdiscovery/> <D:getcontenttype>application/zip</D:getcontenttype> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> </D:multistatus>
OS: Ubuntu 18.04.5 LTS apache2: 2.4.29-1ubuntu4.14
Hi, not sure we can get a real solution here. mod_dav has: > case DAV_PROPID_creationdate: > /* > ** Closest thing to a creation date. since we don't actually > ** perform the operations that would modify ctime (after we > ** create the file), then we should be pretty safe here. > */ > dav_format_time(DAV_STYLE_ISO8601, > resource->info->finfo.ctime, > buf, sizeof(buf)); > value = buf; > break; As you can see, we take ctime, which is "the closest thing to a creation date" In your case, the chown and chmod have changed this ctime. Maybe we could have an "even closer" date by taking the min of ctime and mtime?