Synchronizing on File Formating

As I am about to finish my works on the backend library, I offer you to 
help me synchronize with your undertakings (PasswordSafe and others).

There are some areas of the file format definition that are, to my 
feeling, not completely "defined" or leaving open questions. So I am 
either asking questions here or I simply state how I am going to 
interpret stuff currently.

A. Timestamp values
Can this be true? [format-v2.txt]:

"Timestamps will be stored as 32 bit, little endian, unsigned integers,
   representing the number of seconds since Midnight, January 1, 1970,   
   GMT. (This is equivalent to the time_t type on Windows and POSIX."

As I understood "time_t" type, it is a long integer showing 
milliseconds, not seconds. I'ld be happy with a "second" granularity in 
pws files (it makes the format 1000-year prove!) but the format 
definition should be made consistent.

--> currently I am using seconds as time values

B. Password Life Time
It is open in format definition whether this field expresses a timepoint 
or a time span. I assume the former.

--> I am using an "epoch" timepoint for values

C. Password Policy

--> I assume the same format of interpreting the 4-byte value as is 
available for the global policy.

D. Unicode Option

--> I use UTF-8 text field interpretation if and only if there is a 
substring "B 24 1" in the options string

E. File Access Key
A solution for text interpretation of file access keys seems pending. I 
don't see how an option could possibly help here!

 --> I always use the local default charset for comparing and applying 
file access keys

Please have a look and compare it with your existing or planned solutions.

Regards
- Wolfgang






-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click