fix: try to correct mtime on upsyncs - #8095
Conversation
261c7fa to
89487f4
Compare
| fileInfo = remoteRootFileInfo.create(fileName, onePartBody.size(), onePartBody.at(0).toLatin1()); | ||
| } | ||
| fileInfo->lastModified = OCC::Utility::qDateTimeFromTime_t(request.rawHeader("x-oc-mtime").toLongLong()); | ||
| fileInfo->lastModified = OCC::Utility::qDateTimeFromTime_t(modtime); |
There was a problem hiding this comment.
that would differ from server behavior
modification time of the server side file should be what is in the header x-oc-mtime
There was a problem hiding this comment.
not really -- request.rawHeader only contains the headers of the HTTP request itself, not the multipart-part that's being uploaded (and modtime is set to the value from the multipart headers)
while cross-checking this I just saw that the header used for the modtime variable uses the x-file-mtime multipart header, which has a TODO set on the server side to be replaced with x-oc-mtime... https://github.com/nextcloud/server/blob/c029616ec05f363b28467bbdccd5ce806fd43212/apps/dav/lib/BulkUpload/BulkUploadPlugin.php#L61-L68
89487f4 to
a769926
Compare
|
|
||
| // the server only considers an mtime of 0-86400 (1d) as invalid, so this is fine | ||
| // see also: apps/dav/lib/Connector/Sabre/MtimeSanitizer.php | ||
| QCOMPARE(lastModified(barFileAaaSubFolder), INVALID_MTIME2); |
There was a problem hiding this comment.
of course Windows doesn't like that change
lastModified(barFileAaaSubFolder) is -1, which is weird considering I'm running this on a 64-bit system (and Windows has been using a signed 64-bit time value internally since basically forever -- however it's 100ns intervals since Jan 1st 1601). time_t seems to be 64-bit on 64-bit Windows as well; my guess is that we need to update https://github.com/nextcloud/desktop/blob/master/src/csync/std/c_time.cpp#L45 to convert from a 64-bit time_t to a FILETIME type ...
There was a problem hiding this comment.
oh my, it's even worse than that
struct timeval, used within FileSystem::setModTime, is defined in the winsock.h header of all places and uses two longs for tv_sec and tv_usec -- and longs are 32-bit wide on Windows, even on x64 systems...
on x64 Linux a long is 64-bit wide, same as time_t and all other fields in a struct timeval
a769926 to
e329208
Compare
Files with a modification time of less than 0 do usually not make sense (and afaik the server doesn't accept them either). --> attempt to update the modification time to _Time.now_ while propagating side note: I ran into this because KArchive/Ark(?) didn't consider the extra time attributes on entries for a certain zip file, so it instead used the standard time value of each zip entry which was set to <= 1980 for files and < 1970 for directories... Signed-off-by: Jyrki Gadinger <nilsding@nilsding.org>
also removes some unused Utility methods Signed-off-by: Jyrki Gadinger <nilsding@nilsding.org>
e329208 to
8cd1bee
Compare
|
Artifact containing the AppImage: nextcloud-appimage-pr-8095.zip SHA256 checksum: To test this change/fix you can download the above artifact file, unzip it, and run it. Please make sure to quit your existing Nextcloud app and backup your data. |
|
|
/backport to stable-3.16 |
|
Hello there, We hope that the review process is going smooth and is helpful for you. We want to ensure your pull request is reviewed to your satisfaction. If you have a moment, our community management team would very much appreciate your feedback on your experience with this PR review process. Your feedback is valuable to us as we continuously strive to improve our community developer experience. Please take a moment to complete our short survey by clicking on the following link: https://cloud.nextcloud.com/apps/forms/s/i9Ago4EQRZ7TWxjfmeEpPkf6 Thank you for contributing to Nextcloud and we hope to hear from you soon! (If you believe you should not receive this message, you can add yourself to the blocklist.) |
2 participants
Files with a modification time of less than 0 do usually not make sense (and afaik the server doesn't accept them either).
--> attempt to update the modification time to Time.now while propagating
side note: I ran into this because KArchive/Ark(?) didn't consider the extra time attributes on entries for a certain zip file, so it instead used the standard time value of each zip entry which was set to <= 1980 for files and < 1970 for directories...