Vector BLF
Loading...
Searching...
No Matches
Vector::BLF::RestorePoint Struct Referencefinal

#include <RestorePoint.h>

Public Member Functions

virtual void read (AbstractFile &is)
 
virtual void write (AbstractFile &os)
 

Static Public Member Functions

static uint32_t calculateObjectSize ()
 

Public Attributes

uint64_t timeStamp {}
 
uint64_t compressedFilePosition {}
 
uint32_t uncompressedFileOffset {}
 
uint32_t unknownRestorePoint {}
 

Detailed Description

Restore Point

Restore Points are kept in a list that is basically an index that references each 1001stth object. So skipping object 0, it counts 1000, 2001, 3002, ...

Note
This class is based on observations, as there is no public documentation available. There are undocumented API functions for RestorePoint handling. And this seems like it.

Member Function Documentation

◆ calculateObjectSize()

uint32_t Vector::BLF::RestorePoint::calculateObjectSize ( )
static

Calculates the objectSize

Returns
object size

◆ read()

void Vector::BLF::RestorePoint::read ( AbstractFile & is)
virtual

Read the data of this object

Parameters
isinput stream

◆ write()

void Vector::BLF::RestorePoint::write ( AbstractFile & os)
virtual

Write the data of this object

Parameters
osoutput stream

Member Data Documentation

◆ compressedFilePosition

uint64_t Vector::BLF::RestorePoint::compressedFilePosition {}

compressed file position

This designates the position of a LogContainer in the compressed file.

◆ timeStamp

uint64_t Vector::BLF::RestorePoint::timeStamp {}

time stamp (in ns)

The following file positions and offsets refer to an Object. The time stamp is from this object.

◆ uncompressedFileOffset

uint32_t Vector::BLF::RestorePoint::uncompressedFileOffset {}

uncompressed file offset

This designates the offset within the uncompressed content of the LogContainer, where an Object starts. This Object is not necessarily the first or last Object, but an arbitrary one.

◆ unknownRestorePoint

uint32_t Vector::BLF::RestorePoint::unknownRestorePoint {}
Todo
It's unclear what this variable is.

Maybe just a reserved field for future extensions.

Examples show:

  • File1: 0, 0x9a
  • File2: 0, 1, 2, 3, 4, 5, 6
  • File3: 0, 0xffffffff, 0x10020
  • File4: 0xb9
  • File5: 0, 0x2c9a8a00

This is similar data as for LogContainer.unknownLogContainer.

See also
LogContainer

The documentation for this struct was generated from the following files: