Welcome to OStack Knowledge Sharing Community for programmer and developer-Open, Learning and Share
Welcome To Ask or Share your Answers For Others

Categories

0 votes
1.3k views
in Technique[技术] by (71.8m points)

android - What causes jobb tool to throw FAT Full IOException?

I am trying to use the Android jobb tool to create a large OBB file for my application, but I am plagued by the "FAT Full" IOException:

java.io.IOException: FAT Full (XXXX, YYYY)
    at de.waldheinz.fs.fat.Fat.allocNew(Fat.java:298)
    at de.waldheinz.fs.fat.Fat.allocAppend(Fat.java:376)
    at de.waldheinz.fs.fat.ClusterChain.setChainLength(ClusterChain.java:175)
    at de.waldheinz.fs.fat.ClusterChain.setSize(ClusterChain.java:132)
    at de.waldheinz.fs.fat.FatFile.setLength(FatFile.java:91)
    at de.waldheinz.fs.fat.FatFile.write(FatFile.java:154)
    at com.android.jobb.Main$1.processFile(Main.java:495)
    at com.android.jobb.Main.processAllFiles(Main.java:604)
    at com.android.jobb.Main.processAllFiles(Main.java:600)
    at com.android.jobb.Main.main(Main.java:417)
Exception in thread "main" java.lang.RuntimeException: Error getting/writing file with name: LAST_PROCESSED_FILE
    at com.android.jobb.Main$1.processFile(Main.java:501)
    at com.android.jobb.Main.processAllFiles(Main.java:604)
    at com.android.jobb.Main.processAllFiles(Main.java:600)
    at com.android.jobb.Main.main(Main.java:417)

In the above error message, XXXX is always printed as exactly one integral value lower than YYYY, and represents the number of usable "clusters" (I'm not versed enough in storage jargon to know exactly what this means). YYYY represents the last successfully allocated cluster index, which in my experience is always the same as the last usable cluster index (the array is sized at XXXX + 2, so XXXX + 1 which is the same as YYYY is the last usable index).

The crash seems to appear at the point at which the total file size exceeds 511 MB (the actual limit is 536,193,820 bytes, a single byte more causes the overflow!), so LAST_PROCESSED_FILE is rather arbitrary, but it lists the file being processed when the crash occurred. Given that the storage format is FAT16 (from what I've been told), shouldn't the maximum file size then be 2 GB?

I have read through various sources that empty or small directories or files, small total file size, or individual files within the directory over 500 MB can cause this crash (though I have not been able to determine why). None of these reasons are applicable to my case (which again, is based on total file size).

My own review of the jobb tool source has not provided any insight. Can anyone please shed any light on this issue?

See Question&Answers more detail:os

与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome To Ask or Share your Answers For Others

1 Answer

0 votes
by (71.8m points)

It turns out that a lot of the issues with the jobb tool are related to the FAT Filesystem library it uses, which is incorrectly determining the maximum size of a FAT16 storage unit to be < 512 MB (while in reality it should be 2 GB).

By modifying the FAT library I am able to successfully build OBB files over 512 MB with the jobb tool. This is also relevant to the reason why OBB files under 4 MB are invalid. The jobb tool source should also be updated because the expected file system should always be FAT16. Small units should be fine, and it should only give issue if there are more than 2 GB worth of data.

I will be reporting this as a bug in the FAT library, and an issue in the jobb tool.

Edit: The modified source files and a GUI tool are available on my GitHub (though, regrettably, I didn't retain a proper version history of the changes).


与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome to OStack Knowledge Sharing Community for programmer and developer-Open, Learning and Share
Click Here to Ask a Question

...