[ninefathom]

I'm a bit puzzled as to how split files with name standardization is an "extension." It seems to me that SEGGER is simply proposing a de facto file naming convention, and offering a few free tools (including a few abstraction drivers) to encourage adoption.

Can somebody fill me in, here- where's the value in what SEGGER is proposing, as opposed to what the entire IT community has already been doing for decades?

[mort96]

Well, if we view FAT32 + this name convention as a new filesystem, then filesystem drivers could let you transparently operate on files bigger than 4GB (GiB?) and take care of the splitting for you. FAT32 + this convention would essentially become a filesystem which supports files up to around 4TB. You wouldn't have to make the choice between the patent-encumbered exFAT and the open but limited FAT32.

[didgetmaster]

I think many programmers have used file splitting technology at the application level for decades. I know I wrote one for a backup utility (Drive Image) back in the 90s that would split the output files into smaller pieces for transfer to removable media (floppies, Zip drives, CDs, DVDs, etc.).

It sounds like BigFat is an extension that takes away the need to do this at the application level. The code does all the splitting and merging for you so you can write a program that acts like the file is on a file system that supports files > 4GB.

[jaclaz]

I had the same impression, I cannot see how it is different from the tools that allow file splitting (for later archiving on floppies. CD's, DVD's, etc.) that exist since forever, when/if implemented in OS filesystem drivers then it will be more "transparent", but until then it seems to me not different from multi-part archives, such as rar or similar.

If I may it would make more sense (to me at least) to use a directory and have a descriptor file, not entirely unlike multi-part vmdk's are implemented.

[noAnswer]

Using split, cat or rar doesn't allow random access.

[jaclaz]

But also this "extension" doesn't seem like allowing it.

On the contrary (but it is a specific "niche" case) the mentioned vmdk split format allows to mount the vmdk same as monolithic, with full random access.

[noAnswer]

Of course it does. "BigFAT allows random read and write access to any file, even if larger than 4GB, as required by databases."

[jaclaz]

I think we are talking of two different things, I was talking of the extension document/specification, that one seems to bring no particular innovation.

The actual implementation (by SEGGER or by someone else):

>Q: Can I implement BigFAT myself?

>A: Absolutely. BigFAT is a specification made available by SEGGER. Anybody is free to write a piece of software implementing it. No fees, no royalties, no headaches. You do not even have to let SEGGER or anybody else know.

is what may allow that (random access), this implementation would be useful if - instead of a "feature" of a given app/program - it would be implemented as a filesystem driver of sorts.

[netsharc]

Edit: I guess my first look is wrong, on second look, it appears it needs their own filesystem driver. If the hack as I wrote would've worked, it would've been very clever, and dangerous...

> de facto file naming convention

From a first look, like it's using Microsoft's own hack of long file names[1] to create file entries that look like they belong to 1 file. A file that has a long file name (more than the 8+3 character limit) is actually several file entries, but they're empty files. Seems like the tool is creating non-empty files instead, that Windows is chaining together as one.

[1] https://en.wikipedia.org/wiki/Design_of_the_FAT_file_system#...