Different timestamps under winXP, win7 and vb.net - windows

Within a VB.net program I used IO.File.GetCreationTime to read the file system's creation time of a file. I was irritated, because the returned value didn't match with the time displayed in the explorer. On another machine the time was displayed correctly.
Both machines use NTFS
I copied the file from a read-only FAT32 USB-drive to the desktop of each machine
Both machines are using the same time zone (GMT+1 plus DST)
timestamps displayed:
my VB.net app (both machines) - 21:09
Explorer time Windows XP - 22:09
Explorer time Windows 7 - 21:09
(MacOS X - 21:09)
The good thing is, that the file I'm talking about is a PDF file. According to the PDF's meta information the file was created on 03. Jan. 2002 22:09
I want that the file system dates are the same on every machine.
How would you solve this problem using VB.net?

I used a simple app to summarize the timestamp information:
GetLastWriteTime(file)
GetLastWriteTimeUtc(file)
GetLastWriteTime(file).ToLocalTime
GetLastWriteTimeUtc(file).ToLocalTime
GetLastWriteTime(file).ToFileTime
GetLastWriteTimeUtc(file).ToFileTime
Date.Now
Date.Now.UtcNow
The output was the same on both machines.
For some reason I changed the time zone settings on both machines, switching DST on and off. The result is interesting ...
... when you turn off DST on Windows
XP all time stamps are reduced by
one (because during DST my time zone
is GMT+2 (now), during the
wintertime it is GMT+1)
... on a Windows 7 machine only
files created during DST (GMT+2)
are affected by this (my file was
created in January)
I guess it's the same effect vice versa. So my problem is just a disply issue. To solve this I will only use the UTC-Functions and care about DST within my app. So there still will be an offset, but it should be ok as long as it is just a display issue.

Related

MDT 2013 Update 1 Failure 5456

We currently have a working setup of MDT linked to WDS. When I PXE boot, everything works as expected, and the new computer deployment succeeds.
However, I am trying to see if we can push the build remotely with PsExec or PDQ Deploy. I've got it mostly working by pushing this command:
\\domain.org\dfs\MDT\Scripts\LiteTouch.vbs /skiptasksequence:YES /skipcomputername:YES /rulesfile:\\domain.org\dfs\MDT\Control\CustomSettings.ini /SkipDomainMembership:YES /SkipApplications:YES
The LiteTouch launches, the computer reboots into WinPE, and it begins - but it fails right when it should do "Install Operating System", giving error
FAILURE (5456): Unable to determine Destination Disk, Partition, and/or Drive. See BDD>LOG for more information. Litetouch deployment failed, Return Code = -2147467259 0x80004005
I tried a few different things I found with changing the Install Operating System step and the Format and Partition step, no dice. Fails at this point every time.
All I want is 1 partition for the whole drive for the OS to use. We've had OSDisk as the name but that doesn't even matter if it is important. And I use a script called UserExit.vbs that keeps the name of the machine when it rebuilds.
All relevant servers are Windows Server 2016, version 1607.
All client OSes are Windows 10 Enterprise, version 1507.
Screenshots
CustomSettings.ini
I tried to include all the relevant code and screenshots above, slightly anonymized with domain.org. Please let me know if there is any more information needed.
In my lab I have the latest MDT build 8443 which provides better support for deploying Win10 1607 and Server 2016. It's recommended to upgrade your MDT 2013 U1 to the latest version, the download link can be found here.
For your questions, you can give the System Partition size 350MB, mark it as a Boot partition, and create the OS partition with the rest disk space. In my test I just keep with the default configuration like below:
The System Partition will be hidden automatically and the OS partition will get C: drive latter. (During WinPE the System Partition is assigned a V: drive letter but it will be removed later)
Edit: Now I can just reproduce your issue in my lab as the below error shown:
I add "Format and partition disk" step under the "Refresh Only" group to enforce this step be executed during the TS. After configuring this, the issue appeared subsequently. If I run the same WMI query as the log stated it returns empty result. The VolumeSerialNumber(VSN) in the query is created during the partition creating and formatting process and will change each time when the disk is formatted. However, in this query the VSN used is still the previous one (before formatted) so the result will be empty.
SELECT * FROM Win32_LogicalDisk WHERE Size = '41996513280' and VolumeName = 'Windows' and VolumeSerialNumber = 'XXXXXXXX'
Commonly, when you launch the LiteTouch.vbs it will be considered as a "Refresh" deployment. In this scenario by default the disk will not be re-formatted excepted the OS drive. When you launch the TS from WinPE (via PXE or boot media) it will be considered as a "NEWCOMPUTER" scenario and disk will be formatted. These two scenarios are totally different in the deployment behavior and your TS only can be used in the NEWCOMPUTER scenario.
Solution: Do not disable the "New computer only" and "Refresh Only" groups in your TS, remove the "Format and Partition disk" step just like the default TS shown then your deployment should be okay.

echoprint fingerprint generation Windows vs Linux

I used to generate fingerprint for an audiofile in Windows 7-64bit and on Ubuntu
but fingerprint codes doesnt same (i mean the code field. ). I used compiled Windows source.
does it supposed to be not same or i did something wrong.
UPDATE
Windows
C:\ecoprint\codegen.exe Kalimba.mp3 > code.txt
Ubuntu
/home/regata/echoprint-codegen$ ./echoprint-codegen Kalimba.mp3 > code.txt
the samples_decoded and code_count fields are different and ofcourse the code part also.
Generated code remain the same. If you ingested full music file and not opted for start and end time while generating code, it should remain the same. If you ingest that code to any other echoprint server, it will matched by the same music files or part of it, atleast 20 seconds of it mostly.

Can I get the BIOS date and time?

I have a script, which monitors some folder's subfolders, check their created date, and if DateDiff from created time and Now is more than 730(2 years) it deletes this folders. The problem is in that, if set current time on PC for 5/16/2015 - the script will delete folders, and it's not cool. I thought about getting time from some internet service, but there is no guarantee that PC will be connected to internet. So I tried to get BIOS time (I believe no users can change it to wrong), and compare folder's created time with this time. But, unfortunately I didn't find the way how to do that. Maybe you have any idea how to implement this task?
Having an incorrect date and time on a production-level machine is not an option nowadays. It will break a lot of things like HTTPS sites (they will fail to validate because of expired certificates), etc.
The system clock (BIOS time) is changed by the operating system whenever the time itself is changed in the OS, so you only have one clock in the computer. In other words the OS does not have a separate clock to track time with.
Nowadays most computers use the Network Time Protocol to keep their clocks in sync, so you should specify the correctly set time as a pre-requisite for your software. (Or you can just specify that the computer must be connected to an external atomic clock, but that's going to be expensive.)

Method of forcing Windows to update file access times *now*?

On Windows XP, the OS will update file access times (if enabled, and it is on my system).
But...according to Microsoft:
"The NTFS file system delays updates to the last access time
for a file by up to 1 hour after the last access."
...and that doesn't just mean "delays updating disk-resident structures" ... no, for
some period after accessing a file then "last access time" will appear as it was before the access. Sometimes for seconds, sometimes for many minutes (haven't seen an hour yet).
Is there a way ("flush", "sync", or some utility or function) where I can tell Windows XP: hey, update all those unupdated file access times now?
I'm trying to determine how some old code works by tracking the files it accesses ... easy to do on most other OS's, but not Windows. (Yes, I'll also be using ProcMon.)
(I haven't researched this behaviour in newer versions of Windows yet.)
thanks,
Stan
I just found this answer on superuser.com that explains that fsutil can be used to disable the update delay on NTFS, at the cost of performance.
fsutil behavior set disablelastaccess 0
You have to reboot the system for the change to take effect (source).

Qt QFileInfo.lastModified() Mac OSX bug?

I am developing an app for Mac and Windows with Qt. I am monitoring changes to Folder X. When a file is copied from somewhere to Folder X, I read its lastModified() date. On Windows it shows the original file's last modified date of the file, which is expected. However, on Mac it returns the Current DateTime. When I rename the file, after it has been copied to Folder X, I get the original file's last Modified date on both Windows and Mac.
So why does Qt on Mac return current DateTime when the file is copied, and returns original file's modified time after I rename the file?
date timestamps are not reliable enough to implement a folder monitoring system, as you've implied above.
i've have spent a few months writing a reliable folder monitoring system on both mac and windows. turned out each required completely different strategies.
on mac: each file and folder can be uniquely identified with an inode number (look in <sys/stat.h>), this number can then used for diff'ing a folder structure to determine changes.
on win: windows also has stat, however this number does not persist and thus cannot be used. i created a solution that uses ReadDirectoryChanges which is a part of the windows api.

Resources