You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: