Hi Mark,

Thanks for your response, very helpful.

Unfortunately I don't know what the filesystem of the volume with the files is - this is a client's network, and they set up a VM in the DMZ for me to work on, with this network share mounted - but I've no idea what the fileserver is.

The thing that puzzles me is why the Windows Explorer is reporting the mod date of these files correctly, while LC isn't.

However, I've now restarted the VM - no change to how Windows Explorer reports the dates; and then told it not to adjust for daylight saving time and restarted it again: the clock on the machine went back by an hour, but the time reported by Windows for the files on the network share didn't change.

I'll see what happens when the job runs overnight, whether one or both these things fixes the timestamps that LC gets...

Ben

On 31/03/2017 12:22, Mark Waddingham via use-livecode wrote:
On 2017-03-31 13:20, Mark Waddingham via use-livecode wrote:
Hi Ben,

This might be of interest:

https://msdn.microsoft.com/en-us/library/windows/desktop/ms724290(v=vs.85).aspx

On 2017-03-31 12:48, Ben Rubinstein via use-livecode wrote:
The standalone, built from LC 6.7.11, is running on a Windows machine
(VM running Windows Server 2008 R2) in London, which has a volume
mounted from a server running an unknown operating system.

What is the filesystem of the volume? The above document suggests that
FAT stores
filetimes in local time and *not* universal time which sounds like it
might be the problem...

I just re-read the pertinent paragraph:

The FAT file system records times on disk in local time. GetFileTime retrieves
cached UTC times from the FAT file system. When it becomes daylight saving
time, the time retrieved by GetFileTime is off an hour, because the cache is
not updated. When you restart the computer, the cached time that GetFileTime
retrieves is correct. FindFirstFile retrieves the local time from the FAT file
system and converts it to UTC by using the current settings for the time zone
and daylight saving time. Therefore, if it is daylight saving time,
FindFirstFile takes daylight saving time into account, even if the file time
you are converting is in standard time.

Sounds like a restart is needed to ensure that the APIs the engine has to use
are correct...

Mark.



_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Reply via email to