Re: Revised formatv3 description

"Frank Pilhofer" <[email protected]>
Newsgroups gmane.comp.security.passwordsafe.devel
Message-ID <[email protected]>
Hi Rony,

one more thing that just occured to me:

On Mon, 16 Jan 2006 16:01:25 -0500, Rony Shapiro <[email protected]> wrote:
>
> 2.8.1 HDR: The database header. All data in the header is written in
> fields, as defined in Section 3. The first field contains the version
> number of the database format. For this version, the value is 0x0300
> (stored in little-endian format, that is, 0x0003). The type of this field
> is zero.  The next field is the database's UUID, stored as 16 bytes. The
> type of this field is zero.  Following this, non-default user preferences
> are written as a string (as described below), with field type zero.
> Currently, no further data is written. To allow further enhancements, the
> database header is terminated by an empty field of type 'END'. This will
> allow older versions of the program to skip over records that may be  
> added over time to the header.
>

If the field types are zero for all header fields, then their sequence
becomes important, and it will be impossible to support only a subset of
fields -- you could support a prefix, but a software would not be able to
omit header fields from in the middle. E.g., in the above example, a
software could not omit the version but still have a UUID. This smells
like a potential future issue. So I suggest to clearly define field ids
and types, as you do for the records. I.e., something like:

Name          value  Type    Implemented Comments
-------------------------------------------------
Version       0x1    short   Y           [1]
UUID          0x2    UUID    Y           [2]
Preferences   0x3    Text    Y           [3]
End of Header 0xff   [empty] Y

[1] Stored as a 2 byte little-endian integer. The higher 8 bits contain
the major version number, the lower 8 bits the minor version number of
the database file format. This document corresponds to version 3.0.

[2] A 16-byte UUID value as defined by RFC 4122.

[3] Non-default preferences stored as described in formatV2.txt.

Frank

-- 
Frank Pilhofer, [email protected]


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.