You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Horizon OS treats directories with numbered files (e.g. 00, 01, etc.) *and* the archive bit flag set as a single file, which helps overcome the max file size limitation in FAT-based filesystems. This feature is known as ConcatenationFile.
In order to provide the user a hassle-free way to manage big files under FAT-based filesystems from UMS devices, it'd be desirable to implement a similar approach into the library.
Describe the solution you'd like
Implement a ConcatenationFile-like ABI that's capable of opening, reading and writing filesystem objects that follow the previously described layout.
Support for ConcatenationFile objects would be completely optional, would be exclusive to FAT-based filesystems, and would ideally be controlled by an additional mount flag. The feature itself would be enabled by default.
Details on how the actual implementation would be accomplished have not yet been planned. This is just something I'd like to do, because it's extremely useful for apps such as nxdumptool.
Additional context
Max file size for each part file would match the one used by Horizon OS.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
Horizon OS treats directories with numbered files (e.g.
00
,01
, etc.) *and* the archive bit flag set as a single file, which helps overcome the max file size limitation in FAT-based filesystems. This feature is known asConcatenationFile
.In order to provide the user a hassle-free way to manage big files under FAT-based filesystems from UMS devices, it'd be desirable to implement a similar approach into the library.
Describe the solution you'd like
Implement a ConcatenationFile-like ABI that's capable of opening, reading and writing filesystem objects that follow the previously described layout.
Support for ConcatenationFile objects would be completely optional, would be exclusive to FAT-based filesystems, and would ideally be controlled by an additional mount flag. The feature itself would be enabled by default.
Details on how the actual implementation would be accomplished have not yet been planned. This is just something I'd like to do, because it's extremely useful for apps such as nxdumptool.
Additional context
Max file size for each part file would match the one used by Horizon OS.
The text was updated successfully, but these errors were encountered: