problem with SetFileTime

[Egbert Zijlema]

Hello folks,
I want to modify a file's LastWriteTime (the one that shows up in an Explorer view).
The time part of the file stamp should be "2:10" (version number).
Unfort. I get "4:10" as a result. Obviously time zone differences and daylight saving time are
automatically added here by Windows. I absolutely don't want this to happen. How do I avoid it?
Here's the crucial part of my code:

#COMPILE EXE
#INCLUDE "WIN32API.INC"
 
FUNCTION PBMain() AS LONG
  LOCAL st AS SYSTEMTIME, lwt AS FILETIME, ofs AS OFSTRUCT
  LOCAL hFile AS LONG
  LOCAL szFileName AS ASCIIZ * %MAX_PATH
 
  szFileName = "TEST.BAS"                          ' file in current dir
  st.wYear   = 2001
  st.wMonth  = 10
  st.wDay    = 19
  st.wHour   = 2
  st.wMinute = 10
  st.wSecond = 0
  
  CALL SystemTimeToFileTime(st, lwt)               ' convert SYSTEMTIME to FILETIME
  hFile = OpenFile(szFileName, ofs, %OF_READWRITE) ' create file handle
  CALL SetFileTime(hFile, BYVAL 0, BYVAL 0, lwt)
  CALL CloseHandle(hFile)
END FUNCTION

------------------
mailto:[email protected][email protected]</A>
www.basicguru.com/zijlema/

[Semen Matusovski]

Egbert --

      SystemTimeToFileTime st, lpLastWriteTime
[b]  LocalFileTimeToFileTime lpLastWriteTime, lpLastWriteTime [/b]

------------------
E-MAIL: [email protected]

[Egbert Zijlema]

Thank you, Semen.
You're great!

------------------
mailto:[email protected][email protected]</A>
www.basicguru.com/zijlema/

[Fred Oxenby]

It is a bad idea to use filetime as "version-holder"
Not even "filedate" is a good idea, not a bit better.
All this, because "YOU" are never in control what is displayed at the users screen.
Bill thougt about that and decided that a "OSVERSIONINFO" struct could help out..


------------------
Fred
mailto:[email protected][email protected]</A>
http://www.oxenby.se

[Michael Mattias]

It is a bad idea to use filetime as "version-holder"
Not even "filedate" is a good idea, not a bit better.

Amen.

Anyone from PowerBASIC, Inc. reading this?

MCM

[Egbert Zijlema]

Fred,

As far as I know, OSVERSIONINFO serves to retrieve the version of your system (i.e. Windows).
To attach version information to your own applications, I recommend you to read my article
on this subject (and download my source code, eventually). It can be found at my website.
The source code can also be downloaded from Power Basic Inc.

Bad or good, I encountered a problem when trying to modify a file stamp. Whatever its use may be,
the WinApi provides those functions. Why, if it is as bad as you suggest?

------------------
mailto:[email protected][email protected]HATERbasicguru.com</A>
www.basicguru.com/zijlema/

[Borje Hagsten]

Agree with Fred, but always mark my versions this way anyway. More advanced
users almost expects to be able to see version number in file time, and for
own sake, also makes life easier.

Not to be relied upon though. Users can have strange habits and re-date all
files in their system for whatever reasons, like see installation date, etc.
For new generation users it doesn't matter at all. They usually don't even
know what a file is..


------------------

[Tom Hanlin]

Windows version info is great when you can use it. But, it won't work
for those DOS or 16-bit programs, or any file that isn't an executable
or DLL. File time/date stamps, on the other hand, work for everything.


------------------
Tom Hanlin
PowerBASIC Staff

[Fred Oxenby]

Originally posted by Egbert Zijlema:
Fred,
As far as I know, OSVERSIONINFO .....

Egbert, I tried to be funny(and failed) ...
I should have been more careful and perhaps used "VS_VERSION_INFO"

Your actual file time is stored in GMT.
Your user see this as GMT +/- his local settings
Depending how he got this file from you, the result can vary...
And this was my point.

And yes, I think PB should take this issue under consideration



------------------
Fred
mailto:[email protected][email protected]</A>
http://www.oxenby.se

[Semen Matusovski]

Your actual file time is stored in GMT.
Your user see this as GMT +/- his local settings

Fred --
do you want to say that OS reads date/time stamp and corrects it according local settings ?
Never noticed and don't beleive (I mean FAT/FAT32). Make an experiment: reset GMT + xx and compare.
About NTFS - not sure, lazy to reboot to NT4.

[This message has been edited by Semen Matusovski (edited October 19, 2001).]

[Tom Hanlin]

Depends on what you consider the OS. The file time/date stamps are maintained
in GMT or UTC format. However, they're converted to/from local form at the user
interface level (the Windows shell, in cases such as viewing file properties
and directory listings) and, always, in DOS box operations: the emulated DOS
time/date is always in local time.


------------------
Tom Hanlin
PowerBASIC Staff

[Scott Turchin]

I use Norton Dos Utilities FD.EXE to manually adjust all of my EXE's and DLL's when I change the version on them...
Sure, someone could modify hte file and time and date of it, but they can do anything they want....
If they are using a generic install, that is the time and date of each file
Helps on tech support too...

Meanwhile, I use this in some secret code to modify a file to MATCH that of another file, I hope it helps.

Function SetFileDateandTime(FileSpec As String,ft As SYSTEMTIME)Export As Long
Local hFile     As Long
Local Result    As Long
Local FileTime  As FILETIME
Local fLocTime  As FILETIME

hFile = CreateFile(FileSpec + Chr$(0), ByVal %GENERIC_READ Or %GENERIC_WRITE, _
                    ByVal 0, ByVal %NULL, ByVal %OPEN_ALWAYS, _
                    ByVal %FILE_ATTRIBUTE_NORMAL, ByVal %NULL)

' convert system date/time to file structure.
SystemTimeToFileTime ft, fLocTime

' convert local file time to UTC file time
' setfiletime expects a time that is relative to utc time.
LocalFileTimeToFileTime fLocTime, FileTime
' set the file time
Result = SetFileTime(ByVal hFile, ByVal %NULL, ByVal %NULL, FileTime)
CloseHandle hFile
Function = Result
End Function
'------------------------------------------------------------------------------------------
Function GetFileDateandTime(FileSpec As String,ft As SYSTEMTIME)Export As Long
Dim fd          As WIN32_FIND_DATA
Local hFile     As Long

hFile = FindFirstFile(ByVal StrPtr(FileSpec),fd)
If IsFalse hFile Then Exit Function
' -- Convert the file time from UTC to local time
FileTimeToLocalFileTime fd.ftLastWriteTime, fd.ftLastWriteTime
' -- Convert the file time into a compatible system time
FileTimeToSystemTime fd.ftLastWriteTime, ft
Function = %TRUE
End Function
'------------------------------------------------------------------------------------------

------------------
Scott Turchin
MCSE, MCP+I
Computer Creations Software
http://www.tngbbs.com/ccs

[Fred Oxenby]

Fred --
do you want to say that OS reads date/time stamp and corrects it according local settings ?

Semen, Open Explorer,wiev your BIN-folder of PBDLL60
PBDLL.EXE have a time of 06:00
--
open controlpanel,Date/Time
--
change timezone to "GMT Dublin London etc.."
--
Have a look at PBDLL.EXE again.
I am pretty sure time is not 06:00 anymore
--
This said, there are times it work.
You will get correct time if you unzip it from a Zipfile,
copy it from a diskette or cd and don't move it from that timezone
or to a pc within same timezone but without daylight-saving etc.



------------------
Fred
mailto:[email protected][email protected]</A>
http://www.oxenby.se



[This message has been edited by Fred Oxenby (edited October 19, 2001).]

[Egbert Zijlema]

Originally posted by Fred Oxenby:
change timezone to "GMT Dublin London etc.."
--
Have a look at PBDLL.EXE again.
I am pretty sure time is not 06:00 anymore

Fred,
I've tried this in 2 ways: by changing timezone
and even by changing regional settings (including reboot),
but PBDLL's 'version time' (6.00) does not change.

How did you fix that PB-guys?



------------------
mailto:[email protected][email protected]</A>
www.basicguru.com/zijlema/

[Semen Matusovski]

Fred --
Again - you talk about NTFS drives and here you are correct.
But FAT/FAT32 keep local time and this time not depends of local settins.

------------------
E-MAIL: [email protected]

[Fred Oxenby]

Perhaps you are right, Semen.
It was a long time since I had FAT16/32 drives in my network...
But I think this discussion proved my point...
"You" can not control what's displayed on "user-side" when dealing with
filenames/filedates/filetimes.
In this case, it is not a matter of "right or wrong" if you manipulate filetime
for your own purposes. Its up to you
But in the case of "professional software" it is dead on wrong
to show the "file-version" as file-time
My (and perhaps only mine) professional opinion

------------------
Fred
mailto:[email protected][email protected]</A>
http://www.oxenby.se



[This message has been edited by Fred Oxenby (edited October 19, 2001).]

[Egbert Zijlema]

Hi guys,

Additional question: Can a file's "lpLastAccessTime" be modified? (programmatically, I mean)
I've tried it several times, but without success.
When reading this filetime, I see that the date is set identical to the one in lpCreationTime,
while the time part is zero. Any idea?
I can't find information that points to a hint saying that this is a 'reserved' or future function.
Changing lpLastWriteTime and lpCreationTime is no problem. I wonder why the latter is the case.
A file's creation time should never be modified, simply because a file is only created once, is'nt it?

------------------
mailto:[email protected][email protected]</A>
www.basicguru.com/zijlema/

[Fred Oxenby]

Note
Not all file systems can record creation and last access time and not all file systems record them in the same manner. For example, on Windows NT FAT, create time has a resolution of 10 milliseconds, write time has a resolution of 2 seconds, and access time has a resolution of 1 day (really, the access date). On NTFS, access time has a resolution of 1 hour. Therefore, the GetFileTime function may not return the same file time information set using the SetFileTime function. Furthermore, FAT records times on disk in local time. However, NTFS records times on disk in UTC, so it is not affected by changes in time zone or daylight saving time.

------------------
Fred
mailto:[email protected][email protected]</A>
http://www.oxenby.se



[This message has been edited by Fred Oxenby (edited October 23, 2001).]