Fw: RE: [jcifs] Preserve lastModified TIME

[Michael B. Allen]

Chris,

I  didn't  know some of these structures were documented incorrectly. Looks
like interesting stuff worth investigating. At one time I was making little
notes  about things like these and then gave up. If you make notes of these
things,  maybe  you can show me the list once in a while, I'll explore them
with  jCIFS  where  possible  and  you can add some quality content in your
book?

PS: Did you see my hint to you in eariler in this thread?

Begin forwarded message:

Date: Wed, 14 Aug 2002 11:07:40 -0500
From: "Caldarale, Charles R" <Chuck.Caldarale at UNISYS.com>
To: "Michael B. Allen" <miallen at eskimo.com>, achernow at yahoo.com, jcifs at samba.org
Subject: RE: [jcifs] Preserve lastModified TIME


> From: Michael B. Allen [mailto:miallen at eskimo.com]
> Subject: Re: [jcifs] Preserve lastModified TIME
> 
> Actually, that's a UTIME field which according to the spec is 
> the number of seconds since Jan 1, 1970.

Would that it were that simple.

Although this specific field is UTIME (incorrectly documented in Leach, but
correct in SNIA), don't forget the other two flavors that appear in the
protocol. Some functions use SMB_DATE/SMB_TIME structure, which is local
time, based on 1980 (the structure layout is documented incorrectly in both
the Leach and SNIA specs). Others use a 64-bit timestamp (aka TIME), which
is UTC based on 1601 (Gregorian). Finally, there's the 32-bit UTIME, based
on 1970, but also apparently local time, not UTC.

Ain't this grand?

 - Chuck



-- 
A  program should be written to model the concepts of the task it
performs rather than the physical world or a process because this
maximizes  the  potential  for it to be applied to tasks that are
conceptually  similar and more importantly to tasks that have not
yet been conceived.