The plot is slightly thickening. I restarted the VM, set the date+time to not
adjust for daylight saving, restarted again. This removed some 30,000 images
from the list with allegedly modified timestamps; the ones that were no longer
consider to have changed were - in some year or other -
On 2017-03-31 19:23, Local (BenR) wrote:
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
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
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
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,
I have an interesting situation. The detailed files is reporting a LIE in
modification dates.
I have a standalone app which outputs a report including the modification date
of a bunch of files (and subsequently interprets and acts on it).
On Monday, a BAD THING happened at my client's side.