WinBatch Tech Support Home

Database Search

If you can't find the information using the categories below, post a question over in our WinBatch Tech Support Forum.

TechHome

Time - Timer and Date Functions
plus

Can't find the information you are looking for here? Then leave a message over on our WinBatch Tech Support Forum.

File Time Discrepancies and NTFS

Keywords:   file time ntfs

Question:

I do a file syncronization using FileTimeCode and FileYmdHms.

I save the FileTimeCode and FileYmdHms of a file into a updates-file. When the syncronization starts, I compare The FileTimeCode I saved into the updates-file to TheFiletimeCode of a file on a remote computer. If the value on the remote is smaller I copy the file and I set the file's modification date using the FileYmdHms Value which was also saved into the updates-file.

The Problem is: When the script runs next time the filetimecodes of the source and remote computer may have a difference of 1, for example source 714295342 and on the remote machine 714295341. How can there be a difference between these to files if they have the same modification date????? And why is there not always a difference of 1 only for about 50-60% of the files? I don't get it

Is this a bug?? By the way, is it possible to calculate the modification date based on the FileTimeCode and vice versa??? If yes, what's the algorithm used for computing this???

Answer:

It's a combo problem that you have to work with.
  1. NTFS file systems can have more accurate file times than DOS systems.

  2. FAT and FAT32 partitions have a file time resolutions of 2 seconds.

  3. WinBatch uses 1 second resolution on NTFS systems

  4. No matter what the source, the resolution of FileTimeCode is 2 seconds, as it is based on a DOS timestamp.

  5. You don't need FileTimeCode, as FileYmdHms values are directly comparable with standard comparison operators.

  6. When you get a filetime in FileTimeCode format the time is truncated to an even second.

  7. When you get a filetime of any kind off a FAT or FAT32 volume, it is *always* an even number of seconds.

  8. A FileYmdHms() off a NTFS volume will give you 1 second resolution. a FileTimeCode off a NTFS volume will lose the odd second if any. So...basically 50% of the time the numbers will disaree.

  9. Conversion script in separate message.

  10. No bug. Thats just the way it is.

Conversion routines:
#DefineFunction FileTimeCode2YmdHms(timecode)

    secs    =  (timecode & 31) * 2       ; start 0  uses 5
    minutes =  (timecode >> 5) & 63      ; start 5  uses 6
    hours   =  (timecode >> 11) & 31     ; start 11 uses 5
    days    =  (timecode >> 16) & 31     ; start 16 uses 5
    months  =  (timecode >> 21) & 15     ; start 21 uses 4
    year    =  (timecode >> 25)  + 1980  ; start 25 uses 6  1980 to 2043
    
    secs=strfixleft(secs,0,2)
    minutes=strfixleft(minutes,0,2)
    hours=strfixleft(hours,0,2)
    days=strfixleft(days,0,2)
    months=strfixleft(months,0,2)
    
    return (strcat(year,":",months,":",days,":",hours,":",minutes,":",secs))


#EndFunction

#DefineFunction  FileYmdHms2TimeCode(ymdhms)
    year    = ItemExtract(1,ymdhms,":")
    months  = ItemExtract(2,ymdhms,":")
    days    = ItemExtract(3,ymdhms,":")
    hours   = ItemExtract(4,ymdhms,":")
    minutes = ItemExtract(5,ymdhms,":")
    secs    = ItemExtract(6,ymdhms,":")
    
    Terminate(year < 1980,"TimeCode error","Year out of range (small)")
    Terminate(year > 2043,"TimeCode error","Year out of range (large)")
    
    code=0
    code = code + (secs / 2)
    code = code | (minutes << 5)
    code = code | (hours <<  11)
    code = code | (days << 16)
    code = code | (months << 21)
    code = code | ( (year-1980) << 25)
    
    return (code)
#EndFunction



fn="c:\autoexec.bat"
fc=FileTimeCode(fn)
fy=FileYmdHms(fn)

aaa=FileTimeCode2YmdHms(fc)

bbb=FileYmdHms2TimeCode(fy)

Message(fy,aaa)
Message(fc,bbb)

Article ID:   W14977
File Created: 2001:11:08:12:41:16
Last Updated: 2001:11:08:12:41:16