Closed RebelliousX closed 10 months ago
This is before the modification:
And this is after the fix:
@wa2c I changed those lines as requested.
There is really no standard value for EOF, each library is different. Some consider 0x26 for text files, others 0, others -1. But according to Java documentation from Oracle, read()
returns -1 at end of file, which somehow the Android kernel file com_android_internal_os_FuseAppLoop.cpp
at line 169 did not like as seen from the screenshot of the exception thrown mentioned earlier.
Here is the implementation of read()
from smbj
Thank you for teaching me.
@wa2c God forbid, my apologies. I didn't mean it that way. I just meant to bring this to your attention and exchanging information. I am learning from you. Sorry again.
This is for (JCIFS, JCIFSNG, or SMBJ)ProxyFileCallbackSafe. The none safe
onRead()
functions return 0 bytes read at EOF. But I noticed SMBJ and JCIFS-NG (safeonRead()
) return -1 to indicate EOF.This causes lots of problems. The app trying to read a file might not expect to see -1 (wrapped to 4GB if 32bit) to be read and complains that the file size is not expected and too big.
Without this fix, an exception would have been thrown, a very long exception with stack trace error log. CIFS Document Provider completely crashes, and then afterwards, the notification of
"Opening file"
shows up and there is no file opened. I had to force close CIFS Document Provider then.I am not sure about JCIFS (SMBv1), since my TrueNAS server doesn't support SMBv1, I can't test it. But I assume it would be the same, since JAVA usually returns -1 for end of file. I tested SMBJ and JCIFS-NG, which both had the same issue.
The program I used for testing, AetherSX2 loading BIOS file either
SCPH10000.bin
orSCPH39001.bin
would trigger the issue. Which only happens on Safe transfers enabled. Below are screenshots of the logcat before and after.The solution might not be optimal, feel free to modify as you like.