JOBB DirectoryFullException: de.waldheinz.fs.fat.DirectoryFullException: directory is full

Question

I\'m trying to use the JOBB tool on a directory containing 192 jpg files totaling about 70 mb. When I run the command as jobb -d C:/sdk/tools/dir/data -k 123456 -o com.nic

Answer 1

Root Cause Analysis:

de.waldheinz.fs.fat.DirectoryFullException: directory is full

This error occurred when either Fat16RootDirectory becomes full or ClusterChainDirectory grows beyond it's ClusterChainDirectory's maximum size(512 MB)

Exception occurs from 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 it may help you.

Solution-1:

On Windows: if you have a folder "data" whith lost of pictures, 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 mentioned error. Try to add one directory-hierarchy and make the "data"-directory to a subfolder

root/data/1.jpg
root/data/2.jpg
root/data/3.jpg
root/data/...
root/data/5000.jpg

use

console>>>jobb -d C:/sdk/tools/dir/root/data -k 123456 -o com.nick.app.obb -pn com.nick.app -pv 1

you have to keep in mind, that if you want to read from the obb later, that the pictures are now in a subfolder.

Resource Link:

1. Using jobb tool in Android
2. What causes jobb tool to throw FAT Full IOException?

---

Suggestion-1:

To check the sector/cluster/FAT sizes, run "jobb -v -dump [obb]". That will print a bunch of info including "Sectors per cluster" and "Sectors per FAT".

In my old .obb, those values were 8 and 150 respectively. 8 isn't a factor of 150 so I may have been hitting the kernel bug described above.

You need to make sure you're using the updated jobb.jar and fat32lib.jar to fix that problem. With the current versions of the libraries on Google Drive, I now get 8 sectors per cluster, 184 sectors per FAT.

I have not yet verified whether this fixes the data corruption problems I was seeing earlier. I'll do more testing and report back here.

Suggestion-2:

Hacking can solve the issue. But took more memory:

This issue is indeed starting to be very very boring. Today I kind of figured out a workaround to this, it's ridiculous, but it looks like adding extra-data to the .obb seems to fix the issue (at least for me). To be precise, my original .obb file size was 110MB, now it's 220MB and the app reads the data without corruption. This is, by far, the dirtiest hack I have ever done to an app and I don't feel proud of it, but hey, at least is working now. :p

Suggestion-3:

In Oct 19, 2015, they have release an updated version: android-sdk-fat32lib

This version forked to solve an issue with the JOBB tool distributed with the Android SDK as of (Android SDK 23) not able to produce OBB files larger than 512M.

UPDATE:

You will get original version and modified versions source code in the following portion:

• Original version available at https://github.com/waldheinz/fat32-lib/
• Modified version available at https://android.googlesource.com/platform/external/fat32lib/

For making jar file from source code, you can follow the tutorials:

1. How to create an Android Library Jar with gradle without publicly revealing source code?
2. Gradle – Create a Jar file with dependencies