question

SebastianEngel-6527 avatar image
0 Votes"
SebastianEngel-6527 asked SebastianEngel-6527 commented

[MS-ONESTORE] TransactionLogFragment's nextFragment size

OneNote seems to add some implicit padding to the TransactionLogFragment.

According to the [MS-ONESTORE] spec, section 2.3.3.1, the TransactionLogFragment has the following components with their respective size in bytes:

list of TransactionEntries (multiple of 8 byte)
nextFragment of type FileChunkReference64x32 (12 bytes)

This strictly means a TransactionLogFragment would never end at an 8-byte boundary (12 % 8 ), wouldn't it?

Anyhow, i noticed, that in all the .one files i checked, that there is an extra 4-byte of nulls padding the TransactionLogFragment to the next 8-byte boundary.
Moreover, the cb value of the FileChunkReference pointing to a TransactionLogFragment also always include this padding.

This padding is not mentioned explicitly anywhere in the spec, as far as i can recall.

I imagine, an other explanation could be that the nextFragment field is a FileChunkReference64 instead of FileChunkReference64x32. Since the 4-byte padding seems to be always located after the nextFragment FCR, the FileChunkReference64 would be conveniently equivalent with a FileChunkReference64x32 + 4 byte padding.
Consequently, this could mean there is an error.

Though, I can see it is in no way necessary to have a 64bit cb value since the TransactionLogFragment is most often only 0x400 bytes wide, very far from the 2Gb limit.

Either way, do you think this behavior should be stated explicitly in the specification? For example append an 32-bit field explicitly stating it is padding and to be ignored.


Other references:
In the OfficeDev/Interop-TestSuites the nextFragment is also implemented a FileChunkReference64x32, strictly according to the spec. the remaining bytes are ignored.

openspecs-office-fileformatsopenspecs-questions
· 6
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

Hi Sebastian

Thank you for contacting Microsoft Open Specifications Support. One of our engineers will be contacting you shortly.

Hung-Chun Yu
Microsoft Open Specifications

0 Votes 0 ·

Hi SebastianEngel-6527,

I will review this and respond with confirmation. Thank you for bringing this to our attention.
Question, do you happen to know which versions of OneNote (including whether OneNote Online web app was used) to create these files?

Best regards,
Tom Jebo
Sr Escalation Engineer
Microsoft Open Specifications

0 Votes 0 ·

Hi Tom,

I have not fully understood the FSSHTTPB protocol yet. That's why I only know for certain that the issue applys to the "non-SOAPed" OneNote files. This means it would only apply to desktop versions.

Best regards,
Sebastian

0 Votes 0 ·

Thanks Sebastian. I'm confirming but from what I see in our code, the cb value that includes 4 extra bytes is because of the allocation and we don't use that to find the next field. Which should mean we don't necessarily have to document this as it can be ignored. I'll follow up after I get the confirmation from our OneNote team.

Tom

0 Votes 0 ·

Hi Sebastian,

I've confirmed that we won't change the documentation as the extra bytes shouldn't affect implementations if they follow the specification by only using the FileChunkReference's to point to the next fragment.

Tom

0 Votes 0 ·

Hi Tom,
thanks for the information.

0 Votes 0 ·

0 Answers