TW
considering that the new "fixed" chunker is much simpler than the "buzhash" chunker, it might be easy to add sparse file support there. as the fixed chunker is better suited...
I'll try to solve this for the fixed-blocksize chunker...
Looks like this bounty is too low / too big in scope. To have a more incremental approach, I created a new issue / new bounty with a more narrow...
there was some more progress in #5620, limited to chunker and hasher. compression and storage not affected yet.
More progress in master branch: #8883 unified sparse file and fmap handling into `FileFMAPReader` and now **all** chunkers use that code (usually via `FileReader`, which has a `.read(size)` method for...
I also have seen the memory usage going upwards with just the psutil code in the loop. I didn't compare the magnitude of that with and without the msgpack call...
If the goal is publishing docs to readthedocs, using sphinx might be the simpler and well-established approach.
Guess the boundary between SSRF and potentially desired functionality is a bit unclear here: - the dns server that shall be updated as desired part of an nsupdate.info setup could...
doing that, thanks for the pointer. :)
stuff that (sometimes is somehow there but) could be better: - check usage of warning flags / linters (aside from pep8) - regularly use dynamic and static analysis tools https://bestpractices.coreinfrastructure.org/projects/271