In some scenarios a 3rd party process may decided to write to a file of size N at position N+M. This is a legitimate call where it is expected that the file grows automatically.
For quite a while we had the false impression that it doesn't matter whether the "gap" is filled with NIL bytes or if we can just add some random garbage and decided to do the latter (see 80162fd). Up until some recent changes (#125) this didn't make any difference, since we used freshly allocated ByteBuffers, which are initialized with NIL bytes.
This change in behaviour led to a bug (cryptomator/cryptomator#2205) that proved our assumption wrong: There are third party processes that rely on gaps being nilled: Apparently a plain "cp" under Linux is optimized to skip empty parts in sparse files.
In some scenarios a 3rd party process may decided to write to a file of size N at position N+M. This is a legitimate call where it is expected that the file grows automatically.
For quite a while we had the false impression that it doesn't matter whether the "gap" is filled with NIL bytes or if we can just add some random garbage and decided to do the latter (see 80162fd). Up until some recent changes (#125) this didn't make any difference, since we used freshly allocated ByteBuffers, which are initialized with NIL bytes.
This change in behaviour led to a bug (cryptomator/cryptomator#2205) that proved our assumption wrong: There are third party processes that rely on gaps being nilled: Apparently a plain "cp" under Linux is optimized to skip empty parts in sparse files.