feature-request seek past end of file

[ddumont]

Let writers seek past the end of a file to extend it.

I'm implementing a bittorrent client, and the requirement of keeping track of chunk files adds to complexity, reduces performance, and increases needed storage while downloading. This is a basic functionality of many fs apis, and it's sorely missing here.

[youk]

Google doesn't want you to download media from torrents. Drop it.

[bradisbell]

There are many use cases for the ability to extend existing files.

[mkruisselbrink]

I agree that this is a useful feature, and we happen to be working on this already.

[ddumont]

Really?! Thank god

Sent from my Pixel XL

On Wed, Jan 20, 2021, 1:53 PM Marijn Kruisselbrink notifications@github.com wrote:

I agree that this is a useful feature, and we happen to be working on this already.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/WICG/file-system-access/issues/262#issuecomment-763859054, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADV3LSRJIO7FDUOCH5I5ITS24RCLANCNFSM4WEZSN7Q .

[ArthurSonzogni]

We were wondering during a Security & privacy review, what would happens if developers tries to seek very far away past the end of the file. Does it creates an enormous file?

The spec already contains part of the response:

Note: Implementations are expected to behave as if the skipped over file contents
are indeed filled with NUL bytes. That doesn't mean these bytes have to actually be
written to disk and take up disk space. Instead most file systems support so called
sparse files, where these NUL bytes don't take up actual disk space.

What platforms actually implement this? What happens on platforms not supporting it? How does it fails the operation exactly? Can this be used as a fingerprinting technique somehow?

+@letitz FYI.

[mkruisselbrink]

Behavior wise it should be no different than calling truncate with a very large size to resize the file. For files in the origin private file system either operation will fail with a quota exceeded error (since the empty space is still counted against quota). For files on the local file system, I imagine it does indeed depend on the underlying file system implementation. It is my understanding that pretty much every major file system today supports sparse files transparently (ntfs, apfs, and most linux file systems), although I haven't tested how exactly they behave. I don't think this will reveal more of the underlying system then other operations already do.