Ticket #613 (Fixed)Sat Aug 12 15:29:11 UTC 2023
LanmanFS reading/setting the file times wrong.
| Reported by: | Colin (478) | Severity: | Normal |
| Part: | RISC OS: Module | Release: | |
| Milestone: | Status | Fixed |
Details by Colin (478):
Lanmanfs reads a different time from the server than windows, linux or lanman98 -which all show the same.
If you have an old server like my router – it has a usb socket on the back – you can see that that there is a difference in times between lanmanfs and lanman98. The problem is lanmanfs is expecting utc from the server.
From {MS_CIFS] pdf on this page:
https://learn.microsoft.com/en-us/openspecs/win…
SMB_DATE & SMB_TIME are the servers local time not utc.
The servers time zone is given in the SMB_COM_NEGOTIATE response – this is the offset to convert server local time to utc (-60 min for me at the moment)
If you search for ‘local time’ there’s one other instance where it appears and that is when the server encounters a writetime of 0.
Changelog:
Modified by Colin (478) Sat, August 12 2023 - 20:44:35 GMT
- Attachment added: timesone_fix_patch.txt
I thought of a quick and dirty fix. see attached file. Seems to work so far.
Modified by Colin (478) Sat, August 12 2023 - 20:54:52 GMT
- Attachment added: timesone_fix_patch.txt
Unfortunately I can’t edit an entry so can someone delete the attached file above. The patch got duplicated in the file for some reason.
This is the correct version.
Modified by Sprow (202) Sun, August 13 2023 - 08:41:19 GMT
- Severity changed from Critical to Normal
- Part changed from Unspecified to RISC OS: Module
FileSwitch does indeed expect the times it is given to be UTC (since RISC OS 3 anyway, I think RISC OS 2 might have used local time). So during DST if I save something on my PC at 09:00 it appears when viewed from the PC as 08:00, but appears correctly in the RISC OS Filer because the Filer applies the localisation (same for timezones, if I was at UTC+1 in summertime that same file would be shown as 10:00).
That USHORT ServerTimeZone field is interesting – never noticed that before! Though I wouldn’t count daylight saving as a timezone change perhaps Microsoft does.
On saving we’d add that, so my summer time document at 09:00 on RISC OS, which is 08:00 UTC, would appear on the server as 09:00.
On loading we’d subtract, so a server 09:00 becomes 08:00 UTC which the Filer displays as 09:00.
A quick glance at your patch doesn’t look quite right; you’ve added a member to the ActiveShare connection, but the timezone is being extracted from the negotiate message block and stored in a global. The timezone should be being applied to the connection, as I might be connected to 2 PCs with different views of time.
The LANMAN2.1 dialect also carries a ServerTimeZone.
Modified by Colin (478) Sun, August 13 2023 - 14:06:53 GMT
So during DST if I save something on my PC at 09:00 it appears when viewed from the PC as 08:00
No it doesn’t it says 09:00.
Servertimezone is not DST it it the difference between localtime and utc ie timezone+dst.
Modified by Sprow (202) Mon, August 14 2023 - 20:51:24 GMT
- Attachment added: windows.png
> > So during DST if I save something on my PC at 09:00 it appears when viewed from the PC as 08:00
>
> No it doesn’t it says 09:00.
I’m pretty sure it does.
Time now is 21:47 BST, I saved a file to my PC (also on BST) with LanManFS 2.69, when I look on my PC it says 20:46. See attached screenshot.
Modified by Colin (478) Tue, August 15 2023 - 22:52:36 GMT
- Attachment added: lanmanfs_test.jpg
The attached file shows 4 files in a folder. 1 put there by lanman98, one put by the modified lanmanfs, one put by windows and one put by the original of lanmanfs.
The top 3 show identical times of the files. All are the correct time except for the original lanmanfs file. The original lanmanfs view only shows the correct time on the file it saves – which it has to do because it put the file there in the first place it could use any value it liked as a timestamp and as long as it could reverse the process it would see the correct time for its files. Anyway a consequence of fixing lanmanfs is that amu now works over lanmanfs in the summer.
Modified by Colin (478) Sat, August 19 2023 - 08:58:48 GMT
I have a version which doesn’t use a static variable (current_server_timezone) but passes hSERVER down to the time conversion functions. The changes are more extensive but it is a better solution. If you are interested I can put it on gitlab. If not I can save the effort.
Modified by Colin (478) Sat, August 19 2023 - 10:09:48 GMT
I mean hSHARE not hSERVER
Modified by Sprow (202) Wed, September 06 2023 - 12:43:36 GMT
> > > So during DST if I save something on my PC at 09:00 it appears when viewed from the PC as 08:00
> >
> > No it doesn’t it says 09:00.
>
> The attached file shows 4 files in a folder. 1 put there by lanman98, one put by the
> modified lanmanfs, one put by windows and one put by the original of lanmanfs.
Your screenshot shows exactly what I described above: whatever time is seen on the PC is treated as UTC by current LanManFS and once the Filer adds 1h (as it’s currently daylight savings) the time ends up correct from the Filer’s view. In your example it’s the file saved at 22:53 appears on the PC as 21:53, in my hypothetical example I happened to choose 09:00. I’m unclear how my example caused the conclusion “No it doesn’t it says 09:00.”?
Modified by Colin (478) Thu, September 07 2023 - 15:47:53 GMT
> I’m unclear how my example caused the conclusion
It was just a confusion on my part over what was saving.
> A quick glance at your patch doesn’t look quite right.
As I said it was a quick and dirty patch which tided me over and which pointed to a solution for ROOL to fix. I didn’t have time for a comprehensive solution. As it didn’t look like ROOL would fix it I eventually found time for a better solution and supplied it as a merge request on gitlab in case ROOL want to use it.
Modified by Colin (478) Tue, October 03 2023 - 16:27:14 GMT
- Status changed from Open to Fixed
Fixed in version 2.70
