-
-
Notifications
You must be signed in to change notification settings - Fork 613
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Is there a straightforward way to deal with edge pieces? #59
Comments
Not currently. It's definitely an interesting case. On most filesystems, those edge pieces will be stored efficiently, although appear confusingly in the filesystem. There's not a simple way to handle this case, except perhaps to always store partial files with a special marker in their name. What do you think of that? Say files a, b, and c in a torrent, and you request b. If there are edge pieces overlapping with a and c, you might see in your directory upon completing b, {a.part, b, c.part}. |
Sounds good. But then there should be an efficient way to merge and grow pieces. Especially when the file system nearing its capacity or heavily fragmented. |
Assuming the filesystem in use supports sparse files (most modern ones do), the merging isn't necessary, and growing is automatic with the existing mmap and file data backends. In the case that the filesystem doesn't support sparse, you can use the piece backend, and access the files through Torrent.NewReader as required, to get maximum space efficiency. |
Ok. Thanks! |
When I'm downloading a file from a multi-file torrent I don't want edge pieces of the file to be split and stored separately.
Is there a way, might be a flag, to simply download those pieces to fill beginning and the end of the requested file and then simply removes them from the piece list without asking backed to create extra files?
The text was updated successfully, but these errors were encountered: