Root cause analysis:
de.waldheinz.fs.fat.DirectoryFullException: directory is full
This error occurred when either Fat16RootDirectory becomes full , or ClusterChainDirectory grows beyond it ClusterChainDirectory maximum size(512 MB)
An exception occurs where ?: DirectoryFullException.java
DirectoryFullException(int currentCapacity, int requestedCapacity) { this("directory is full", currentCapacity, requestedCapacity); }
For this problem, I want to prefer a solution and some suggestions. Hope this helps you.
Solution 1:
On Windows: if you have a data folder with image loss and copied to the android sdk-tools directory
data/1.jpg data/2.jpg data/3.jpg data/... data/5000.jpg
and you use
console>>>jobb -d C:/sdk/tools/dir/data -k 123456 -o com.nick.app.obb -pn com.nick.app -pv 1
You will get the indicated error. Try adding one directory hierarchy and making the "data" directory into a subfolder
root/data/1.jpg root/data/2.jpg root/data/3.jpg root/data/... root/data/5000.jpg
using
console>>>jobb -d C:/sdk/tools/dir/root/data -k 123456 -o com.nick.app.obb -pn com.nick.app -pv 1
you should keep in mind that if you want to read from obb later, that images are now in a subfolder.
Link to the resource:
To check the size of sector/cluster/FAT , run "jobb -v -dump [obb]" . This will print a ton of information, including "Sectors per cluster" and "Sectors per FAT" . "Sectors per FAT"
In my old .obb, these values were 8 and 150, respectively. 8 is not a factor of 150, so I may have hit the kernel error described above.
You need to make sure that you use the updated jobb.jar and fat32lib.jar to fix this problem. With current library versions on Google Drive, now I get 8 sectors per cluster, 184 sectors per FAT.
I have not yet tested whether this fixes data corruption issues that I saw earlier. I will do more tests and report here.
Offer 2:
Hacking can solve the problem . But it took more memory:
This problem really starts to be very boring. Today I somehow figured out a workaround, this is ridiculous, but it seems that adding extra data to .obb seems to fix the problem (at least for me). To be precise, my original .obb file size was 110 MB, now it is 220 MB, and the application reads the data without corruption. This is by far the dirtiest hack I have ever done with the application, and I'm not proud of it, but hey, at least now it works.: P
Offer 3:
In October 19, 2015, an updated version was released: android-sdk-fat32lib
This version is forked to solve the problem with the JOBB tool distributed with the Android SDK, with (Android SDK 23) unable to create OBB files larger than 512M.
UPDATE:
You will receive the source version and modified versions of the source code in the following part:
To create a jar file from the source code, you can follow the tutorials: