From 34f6c4dc4efb294ce8df7fd02cabe8292ea344e3 Mon Sep 17 00:00:00 2001 From: Selver Date: Fri, 30 Nov 2018 13:01:15 -0800 Subject: [PATCH] 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.... --- nx/include/switch/services/fs.h | 1 + 1 file changed, 1 insertion(+) diff --git a/nx/include/switch/services/fs.h b/nx/include/switch/services/fs.h index 8d143ff9..907ca612 100644 --- a/nx/include/switch/services/fs.h +++ b/nx/include/switch/services/fs.h @@ -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