Additional comment for fsFsSetArchiveBit()

Describe why HOS might have done this.  While the below is conjecture, the effect matches the comment added to the file.

FAT32 has a (4GiB-1) byte limit per file, but they had to support that media.
They likely wanted to avoid forcing game makers to partition game files.
If the above is true, then this hack could make sense....

The directory, rather than being a "real" directory, is storing the file in multiple parts.

Example (ignoring actual hash-based file names that HOS uses for simplicity):
* The game ships with a file named "FOO.DAT" that is 6GB in size.
* HOS does not attempt to create a 6GB file on FAT32 media (which would fail)
* HOS creates a directory named "FOO.DAT" instead.
* Inside that directory, HOS stores the first 2GB as "FileChunk01"
* Inside that directory, HOS stores the second 2GB portion as "FileChunk02"
* Inside that directory, HOS stores the final 2GB of the data as "FileChunk03"

Unfortunately, by using the archive bit, it can cause problems, especially when an OS (ahem... MacOS) or other utility changes the archive bit settings on directories....
This commit is contained in:
Selver 2018-11-30 13:01:15 -08:00 committed by GitHub
parent ba68e198db
commit 34f6c4dc4e
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

View File

@ -227,6 +227,7 @@ void fsFsClose(FsFileSystem* fs);
/// Uses \ref fsFsQueryEntry to set the archive bit on the specified absolute directory path.
/// This will cause HOS to treat the directory as if it were a file containing the directory's concatenated contents.
/// This allows HOS to support files larger than 4GB on media formatted as FAT32, for example.
Result fsFsSetArchiveBit(FsFileSystem* fs, const char *path);
// IFile