File modification time no longer preserved on downloading files via Wifi/WebDav plugin

[Szpak]

Hi. I've been using Total Commander for Android with the "Send via Wifi" WebDav plugin to fast copy files from my Android (12) phone (Pixel 3a). However, "recently" I've noticed that the file modification time is no longer preserved on download (phone → computer). In hindsight, It started happening in December 2023 (I don't know if I upgraded the plugin in the meantime, I might have before slightly updated plugin version).

To be clear, I don't know where the problem is (on the phone/server side or on the client). However, I've checked a few clients it all of them doesn't preserve the dates. I wasn't able to find any major/related system update (on the PC side) between the time it worked and it didn't. So, I decided to ask here.

Q. Is it possible that there were any other changes in 3.60 that could broke it? It maybe Android changed anything back then?

Btw, I see the dates correctly when listening the directory, but not on downloading particular files. Files in the ZIP archive are properly "dated".

TC 3.50, TotalCmd-Wifi Transfer 4.3.

[ghisler(Author)]

Thanks for your report. What program are you using on the PC side to access the files provided by TotalCmd-Wifi Transfer on the Android side?
A Web browser? Which one?
Total Commander for Windows with WebDAV plugin?
Mounted the WebDAV server as a drive on Windows?

[Szpak]

Thanks for your reply.

Originally, I was using Double Commander (DC) on Fedora Linux which, I believe, might internally use Gnome GVfs 1.54. Once spotted a regression, I've also tried using GVfs directly with Nautilus (Gnome file manager), with the same effect (no timestamp preserved on copying - listing shows the timestamps correctly).

Initially, I was suspecting DC, but then, I was using quite old version from early 2023 (with regression starting in December 2023). Later, I switched to GVfs, as there are similar reports (namely this and that), but there are much older, I from the files history, I see that up until December 2023, it worked fine (with Double Commander). I wasn't also able to find any particular GVfs update done in the time span between the "it works" and "it doesn't" stated.

As a non-GVfs check, I used cadaver, but I don't know, if it is able to preserve timestamps at all.

Today, I've checked also davfs2 which is a regular Linux kernel driver and everything works fine, as the tools such as DC threat is as regular files, not webdav mounted files. However, it could suggest that TC and TotalCmd-Wifi works as expected :-/.

On the Android side, I use Total Command with "send to".

Just to emphasis, I don't state there is any regression in TotalCmd-Wifi, but I just try to find a reason why it stopped working in my case. I will probably focus on checking the commits in GVfs, especially, if there were no related changes in the TC and/or TotalCmd-Wifi around that period.

[ghisler(Author)]

All TotalCmd-Wifi can do is report the file timestamps. It's then the responsibility of the client to apply them to downloaded files. If you see the timestamps in the file list of the client, then TotalCmd-Wifi is sending them correctly. If you don't see timestamps, then TotalCmd-Wifi wasn't sending them - this can happen when you share data from other sources than a file manager (e.g. sharing the file from a Gallery/Image viewer app) and the timestamp isn't provided by that app to TotalCmd-Wifi.

[Szpak]

Thanks. I still would like to have it explained, so I iterated the topic on the gvfs side and its maintainer gave the setup with TC + TC-Wifi a try and spotted a difference between "Depth: 0" and "Depth: 1" in a request which causes "<D:getlastmodified/>" to be returned or not and might explain why the date is displayed on listing:
https://gitlab.gnome.org/GNOME/gvfs/-/issues/637#note_2136916

Could that behavior change in TC-Wifi in the period of last ~12 months?

[ghisler(Author)]

Thanks for the info! The server doesn't return the details of the collection (the folder), just of the elements in it. Normally a client gets an entire directory and then shows that to the user for download, and then downloads files from it without requesting the information separately for each entry.

I will try to add the details to the collection too.

[Szpak]

Thanks! Feel free to post the beta version here - once available - I will try to test it with gvfs.

[ghisler(Author)]

The beta version is now available as an update via Play Store:
https://play.google.com/apps/testing/com.ghisler.tcplugins.wifitransfer
or via F-Droid repository:
https://www.ghisler.com/fdroid.htm

Please test it!

[Szpak]

Thanks for the new release!

I've just tested 4.4b1 with gvfs, but I didn't work. The dates are not preserved. I will ask the gvfs maintainer to give it a try - maybe it wasn't the (main) reason why gvfs was not preserving the dates.

[ghisler(Author)]

Are you sure you have the beta version installed now? After clicking on the above link, you need to update the app via Play Store, or wait until it updates automatically. You can check in the list of installed apps whether you have version 4.4b1 or still 4.3.

[Szpak]

I've checked it before posting the results and it was 4.4b1. However, in the meantime, the gvfs maintainer also gave it a try and found something else:
https://gitlab.gnome.org/GNOME/gvfs/-/issues/637#note_2140841

WDYT?

[ghisler(Author)]

Thanks, the plugin was indeed not sending the timestamp for downloads when the file was supplied via "content" URL, which is the case on newer Android versions. I have added this now to beta 2, please try it. It's available in the Play Store now, and via our beta F-Droid repository.

[Szpak]

I've just tried 4.4b2 from Play Store and it worked as expected, big thank you!