feature-request seek past end of file #262
Comments
|
Google doesn't want you to download media from torrents. Drop it. |
|
There are many use cases for the ability to extend existing files. |
|
I agree that this is a useful feature, and we happen to be working on this already. |
mkruisselbrink
added a commit
that referenced
this issue
Jan 20, 2021
Rather than rejecting when trying to write past the end of a file this changes the spec to require extending a file with 0 bytes instead. This enables creating sparse files (very useful for certain file formats such as disk images). Additionally this greatly simplifies saving content to a file when the data to be written is received out of order (such as in the case of bittorrent downloads). Without this functionality such a application would have to manually make sure to resize the file either ahead of time or when needed during writing. Note that the behavior here would have already been possible by keeping track of the file size, and inserting appropriate truncate() calls to grow the file whenever trying to write past the end of a file. Not requiring these explicit truncate calls simplifies code, and reduces the chance of bugs in websites (accidentally shrinking files when they don't need to, for example). This fixes #262
mkruisselbrink
added a commit
that referenced
this issue
Jan 20, 2021
Rather than rejecting when trying to write past the end of a file this changes the spec to require extending a file with 0 bytes instead. This enables creating sparse files (very useful for certain file formats such as disk images). Additionally this greatly simplifies saving content to a file when the data to be written is received out of order (such as in the case of bittorrent downloads). Without this functionality such a application would have to manually make sure to resize the file either ahead of time or when needed during writing. Note that the behavior here would have already been possible by keeping track of the file size, and inserting appropriate truncate() calls to grow the file whenever trying to write past the end of a file. Not requiring these explicit truncate calls simplifies code, and reduces the chance of bugs in websites (accidentally shrinking files when they don't need to, for example). This fixes #262
|
Really?! Thank god
…Sent from my Pixel XL
On Wed, Jan 20, 2021, 1:53 PM Marijn Kruisselbrink ***@***.***> 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
<#262 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AADV3LSRJIO7FDUOCH5I5ITS24RCLANCNFSM4WEZSN7Q>
.
|
mkruisselbrink
added a commit
that referenced
this issue
Jan 22, 2021
Rather than rejecting when trying to write past the end of a file this changes the spec to require extending a file with 0 bytes instead. This enables creating sparse files (very useful for certain file formats such as disk images). Additionally this greatly simplifies saving content to a file when the data to be written is received out of order (such as in the case of bittorrent downloads). Without this functionality such a application would have to manually make sure to resize the file either ahead of time or when needed during writing. Note that the behavior here would have already been possible by keeping track of the file size, and inserting appropriate truncate() calls to grow the file whenever trying to write past the end of a file. Not requiring these explicit truncate calls simplifies code, and reduces the chance of bugs in websites (accidentally shrinking files when they don't need to, for example). This fixes #262
Closed
1 task
|
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: What platforms actually implement this? +@letitz FYI. |
|
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. |
mkruisselbrink
added a commit
that referenced
this issue
Feb 4, 2021
Rather than rejecting when trying to write past the end of a file this changes the spec to require extending a file with 0 bytes instead. This enables creating sparse files (very useful for certain file formats such as disk images). Additionally this greatly simplifies saving content to a file when the data to be written is received out of order (such as in the case of bittorrent downloads). Without this functionality such a application would have to manually make sure to resize the file either ahead of time or when needed during writing. Note that the behavior here would have already been possible by keeping track of the file size, and inserting appropriate truncate() calls to grow the file whenever trying to write past the end of a file. Not requiring these explicit truncate calls simplifies code, and reduces the chance of bugs in websites (accidentally shrinking files when they don't need to, for example). This fixes #262
github-actions bot
added a commit
that referenced
this issue
Feb 4, 2021
Rather than rejecting when trying to write past the end of a file this changes the spec to require extending a file with 0 bytes instead. This enables creating sparse files (very useful for certain file formats such as disk images). Additionally this greatly simplifies saving content to a file when the data to be written is received out of order (such as in the case of bittorrent downloads). Without this functionality such a application would have to manually make sure to resize the file either ahead of time or when needed during writing. Note that the behavior here would have already been possible by keeping track of the file size, and inserting appropriate truncate() calls to grow the file whenever trying to write past the end of a file. Not requiring these explicit truncate calls simplifies code, and reduces the chance of bugs in websites (accidentally shrinking files when they don't need to, for example). This fixes #262 SHA: edc4d88 Reason: push, by @mkruisselbrink Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
The text was updated successfully, but these errors were encountered: