The first two weeks of the GSoC coding period are now over.
Firstly, a mapping between KIO errors and FUSE errors has now been established. Previously all KIO Job errors were simply sent back to FUSE as EIO, which isn’t entirely accurate. The mapping now provides more accurate error replies.
A major new addition is 32-bit support. KIOFuse did not compile on 32-bit but these compilation errors have now been alleviated. They mostly stemmed from the fact that
size_t has a different size on different architectures, and that file sizes should always be represented as
Another big question was whether files larger than 4GiB could be sent without data corruption. A switch from the C standard I/O functions to UNIX I/O functions was necessary to avoid data corruption. However, this alone was not sufficient. On 32-bit files larger than 4GiB I noticed that no write call was occurring, although it occurred on 64-bit and on 32-bit with smaller files. I couldn’t point this down to anything in KIOFuse (seeming as KIOFuse simply responds to requests passed by FUSE, what can we do if we don’t receive the necessary request?). Luckily one of my mentors, fvogt, spotted a kernel bug report, which fortunately was fixed about a month ago. This bug was the cause of the problem I was seeing. This means that transferring of files larger than 4GiB via KIOFuse is now supported on distros running kernels 5.1.5+ only. Because of this, we do not recommend packaging or using KIOFuse on kernels less than the mentioned version, due to likely data corruption when transferring large files. This patch is still not in master and is under active review. It is being looked into whether adding a unit test is feasible.
I’d like to thank my mentors, fvogt and chinmoy for their help and guidance so far and look forward to improving KIOFuse further. Over the next week, signal handling and password change/unmount (if necessary) support are the features that will be worked on.