mirror of
https://github.com/aaru-dps/Aaru.git
synced 2025-12-16 19:24:25 +00:00
REFACTOR: Final cleanup of DiscImageChef.Filesystems.
This commit is contained in:
@@ -37,11 +37,11 @@ namespace DiscImageChef.Filesystems.LisaFS
|
||||
public partial class LisaFS
|
||||
{
|
||||
/// <summary>
|
||||
/// The MDDF is the most import block on a Lisa FS volume.
|
||||
/// It describes the volume and its contents.
|
||||
/// On initialization the memory where it resides is not emptied
|
||||
/// so it tends to contain a lot of garbage. This has difficulted
|
||||
/// its reverse engineering.
|
||||
/// The MDDF is the most import block on a Lisa FS volume.
|
||||
/// It describes the volume and its contents.
|
||||
/// On initialization the memory where it resides is not emptied
|
||||
/// so it tends to contain a lot of garbage. This has difficulted
|
||||
/// its reverse engineering.
|
||||
/// </summary>
|
||||
struct MDDF
|
||||
{
|
||||
@@ -209,10 +209,10 @@ namespace DiscImageChef.Filesystems.LisaFS
|
||||
}
|
||||
|
||||
/// <summary>
|
||||
/// An entry in the catalog from V3.
|
||||
/// The first entry is bigger than the rest, may be a header, I have not needed any of its values so I just ignored it.
|
||||
/// Each catalog is divided in 4-sector blocks, and if it needs more than a block there are previous and next block
|
||||
/// pointers, effectively making the V3 catalog a double-linked list. Garbage is not zeroed.
|
||||
/// An entry in the catalog from V3.
|
||||
/// The first entry is bigger than the rest, may be a header, I have not needed any of its values so I just ignored it.
|
||||
/// Each catalog is divided in 4-sector blocks, and if it needs more than a block there are previous and next block
|
||||
/// pointers, effectively making the V3 catalog a double-linked list. Garbage is not zeroed.
|
||||
/// </summary>
|
||||
struct CatalogEntry
|
||||
{
|
||||
@@ -225,11 +225,11 @@ namespace DiscImageChef.Filesystems.LisaFS
|
||||
/// <summary>0x23, null-termination</summary>
|
||||
public byte terminator;
|
||||
/// <summary>
|
||||
/// At 0x24
|
||||
/// 0x01 here for subdirectories, entries 48 bytes long
|
||||
/// 0x03 here for entries 64 bytes long
|
||||
/// 0x08 here for entries 78 bytes long
|
||||
/// This is incomplete, may fail, mostly works...
|
||||
/// At 0x24
|
||||
/// 0x01 here for subdirectories, entries 48 bytes long
|
||||
/// 0x03 here for entries 64 bytes long
|
||||
/// 0x08 here for entries 78 bytes long
|
||||
/// This is incomplete, may fail, mostly works...
|
||||
/// </summary>
|
||||
public byte fileType;
|
||||
/// <summary>0x25, lot of values found here, unknown</summary>
|
||||
@@ -249,7 +249,7 @@ namespace DiscImageChef.Filesystems.LisaFS
|
||||
}
|
||||
|
||||
/// <summary>
|
||||
/// An extent indicating a start and a run of sectors.
|
||||
/// An extent indicating a start and a run of sectors.
|
||||
/// </summary>
|
||||
struct Extent
|
||||
{
|
||||
@@ -258,12 +258,12 @@ namespace DiscImageChef.Filesystems.LisaFS
|
||||
}
|
||||
|
||||
/// <summary>
|
||||
/// The Extents File. There is one Extents File per each file stored on disk.
|
||||
/// The file ID present on the sectors tags for the Extents File is the negated
|
||||
/// value of the file ID it represents. e.g. file = 5 (0x0005) extents = -5 (0xFFFB)
|
||||
/// It spans a single sector on V2 and V3 but 2 sectors on V1.
|
||||
/// It contains all information about a file, and is indexed in the S-Records file.
|
||||
/// It also contains the label. Garbage is zeroed.
|
||||
/// The Extents File. There is one Extents File per each file stored on disk.
|
||||
/// The file ID present on the sectors tags for the Extents File is the negated
|
||||
/// value of the file ID it represents. e.g. file = 5 (0x0005) extents = -5 (0xFFFB)
|
||||
/// It spans a single sector on V2 and V3 but 2 sectors on V1.
|
||||
/// It contains all information about a file, and is indexed in the S-Records file.
|
||||
/// It also contains the label. Garbage is zeroed.
|
||||
/// </summary>
|
||||
struct ExtentFile
|
||||
{
|
||||
@@ -335,29 +335,38 @@ namespace DiscImageChef.Filesystems.LisaFS
|
||||
public int length;
|
||||
/// <summary>0x84, 0x204 in v1, unknown</summary>
|
||||
public int unknown9;
|
||||
/// <summary>0x88, 0x208 in v1, extents, can contain up to 41 extents (85 in v1), dunno LisaOS maximum (never seen more than 3)</summary>
|
||||
/// <summary>
|
||||
/// 0x88, 0x208 in v1, extents, can contain up to 41 extents (85 in v1), dunno LisaOS maximum (never seen more
|
||||
/// than 3)
|
||||
/// </summary>
|
||||
public Extent[] extents;
|
||||
/// <summary>0x17E, unknown, empty, padding?</summary>
|
||||
public short unknown10;
|
||||
/// <summary>
|
||||
/// At 0x180, this is the label.
|
||||
/// While 1982 pre-release documentation says the label can be up to 448 bytes, v1 onward only have space for a 128 bytes one.
|
||||
/// Any application can write whatever they want in the label, however, Lisa Office uses it to store its own information, something
|
||||
/// that will effectively overwrite any information a user application wrote there.
|
||||
/// The information written here by Lisa Office is like the information Finder writes in the FinderInfo structures, plus
|
||||
/// the non-unique name that is shown on the GUI. For this reason I called it LisaInfo.
|
||||
/// I have not tried to reverse engineer it.
|
||||
/// At 0x180, this is the label.
|
||||
/// While 1982 pre-release documentation says the label can be up to 448 bytes, v1 onward only have space for a 128
|
||||
/// bytes one.
|
||||
/// Any application can write whatever they want in the label, however, Lisa Office uses it to store its own
|
||||
/// information, something
|
||||
/// that will effectively overwrite any information a user application wrote there.
|
||||
/// The information written here by Lisa Office is like the information Finder writes in the FinderInfo structures,
|
||||
/// plus
|
||||
/// the non-unique name that is shown on the GUI. For this reason I called it LisaInfo.
|
||||
/// I have not tried to reverse engineer it.
|
||||
/// </summary>
|
||||
public byte[] LisaInfo;
|
||||
}
|
||||
|
||||
/// <summary>
|
||||
/// The S-Records File is a hashtable of S-Records, where the hash is the file ID they belong to.
|
||||
/// The S-Records File cannot be fragmented or grown, and it can easily become full before the 32766 file IDs are exhausted.
|
||||
/// Each S-Record entry contains a block pointer to the Extents File that correspond to that file ID as well as the real file size,
|
||||
/// the only important information about a file that's not inside the Extents File.
|
||||
/// It also contains a low value (less than 0x200) variable field of unknown meaning and another one that seems to be flags,
|
||||
/// with values like 0, 1, 3 and 5.
|
||||
/// The S-Records File is a hashtable of S-Records, where the hash is the file ID they belong to.
|
||||
/// The S-Records File cannot be fragmented or grown, and it can easily become full before the 32766 file IDs are
|
||||
/// exhausted.
|
||||
/// Each S-Record entry contains a block pointer to the Extents File that correspond to that file ID as well as the
|
||||
/// real file size,
|
||||
/// the only important information about a file that's not inside the Extents File.
|
||||
/// It also contains a low value (less than 0x200) variable field of unknown meaning and another one that seems to be
|
||||
/// flags,
|
||||
/// with values like 0, 1, 3 and 5.
|
||||
/// </summary>
|
||||
struct SRecord
|
||||
{
|
||||
@@ -372,13 +381,13 @@ namespace DiscImageChef.Filesystems.LisaFS
|
||||
}
|
||||
|
||||
/// <summary>
|
||||
/// The catalog entry for the V1 and V2 volume formats.
|
||||
/// It merely contains the file name, type and ID, plus a few (mostly empty) unknown fields.
|
||||
/// Contrary to V3, it has no header and instead of being a double-linked list it is fragmented using an Extents File.
|
||||
/// The Extents File position for the root catalog is then stored in the S-Records File.
|
||||
/// Its entries are not filed sequentially denoting some kind of in-memory structure while at the same time
|
||||
/// forcing LisaOS to read the whole catalog. That or I missed the pointers.
|
||||
/// Empty entries just contain a 0-len filename. Garbage is not zeroed.
|
||||
/// The catalog entry for the V1 and V2 volume formats.
|
||||
/// It merely contains the file name, type and ID, plus a few (mostly empty) unknown fields.
|
||||
/// Contrary to V3, it has no header and instead of being a double-linked list it is fragmented using an Extents File.
|
||||
/// The Extents File position for the root catalog is then stored in the S-Records File.
|
||||
/// Its entries are not filed sequentially denoting some kind of in-memory structure while at the same time
|
||||
/// forcing LisaOS to read the whole catalog. That or I missed the pointers.
|
||||
/// Empty entries just contain a 0-len filename. Garbage is not zeroed.
|
||||
/// </summary>
|
||||
struct CatalogEntryV2
|
||||
{
|
||||
|
||||
Reference in New Issue
Block a user