de.waldheinz.fs.fat.DirectoryFullException: directory is full
当Fat16RootDirectory becomes full或ClusterChainDirectory grows beyond it's ClusterChainDirectory's maximum size(512 MB)
DirectoryFullException(int currentCapacity, int requestedCapacity) {
this("directory is full", currentCapacity, requestedCapacity);
}
在Windows上：如果您的文件夹“数据”丢失图片，并复制到android sdk-tools目录
data/1.jpg
data/2.jpg
data/3.jpg
data/...
data/5000.jpg
而你用
console>>>jobb -d C:/sdk/tools/dir/data -k 123456 -o com.nick.app.obb -pn com.nick.app -pv 1
您将得到提到的错误。尝试添加一个目录层次结构并将“数据”目录创建到子文件夹
root/data/1.jpg
root/data/2.jpg
root/data/3.jpg
root/data/...
root/data/5000.jpg
用
console>>>jobb -d C:/sdk/tools/dir/root/data -k 123456 -o com.nick.app.obb -pn com.nick.app -pv 1
您必须牢记，如果以后要阅读Obb，则图片现在位于子文件夹中。
要检查sector/cluster/FAT尺寸，请运行"jobb -v -dump [obb]"。这将打印出包括"Sectors per cluster"和的信息"Sectors per FAT"。
在我的旧.obb文件中，这些值分别为8和150。8不是150的因数，所以我可能一直在遇到上述内核错误。
您需要确保您使用的是更新版本jobb.jar 并fat32lib.jar解决该问题。使用Google云端硬盘上的当前库版本，我现在每个群集获得8个扇区，每个FAT获得184个扇区。
我尚未验证这是否可以解决我之前看到的数据损坏问题。我将进行更多测试，并在此处报告。
黑客攻击可以解决问题。但是占用了更多的内存：
这个问题的确开始变得非常无聊。今天，我有点想出了一个解决办法，这很荒谬，但是看起来好像向.obb添加额外数据似乎可以解决问题（至少对我而言）。确切地说，我的原始.obb文件大小为110MB，现在为220MB，应用程序读取数据时不会损坏。到目前为止，这是我迄今为止对应用程序所做的最肮脏的黑客攻击，对此我并不感到骄傲，但是，至少现在正在运行。：p
2015年10月19日，他们发布了更新版本：android-sdk- fat32lib
该版本解决了与Android SDK一起发布的JOBB工具的问题，因为该工具(Android SDK 23)无法生成大于512M的OBB文件。
您将在以下部分中获得原始版本和修改版本的 ：
602392714
清零编程群