previous behavior:
* when a chunk already existed on the server, it would
unstitch and continue retrying each individual chunk
* upon unknown-wark (file already completed), it would
upload the remaining scheduled chunks before bailing
the unknown-wark behavior was accidental bullshit
the chunk-exists behavior was intentional, assumed optimal for
preserving tcp window-scaling, just not when running behind a
bufferbloating reverseproxy which may disconnect the client on
a timeout before the response is delivered, and "some clients"
still follow rfc2616-8.2.4 (retries the POST, wtf...)
wasting bandwidth + maybe further worsening conditions
"some clients" is specifically firefox with the devtools not open
another firefox joke is that it doesn't read the server-response
if the server does not drain the request-body; we end up in
xhr.onerror with no idea why, must assume the worst
new behavior:
in both scenarios, drop all scheduled chunks to be uploaded and
redo handshake, to as far as possible avoid retransmissions;
firefox will still eagerly retry 4 times but whatever
u2c was/is fine; nothing to be done
depending on network conditions and physical distance, this MAY
result in lower total speed, but the average case is likely a
net-positive, wasting less bandwidth on retransmissions,
in exchange for resetting tcp window-scaling
Nixpkgs patches many libraries to read certificate bundle mentioned in
NIX_SSL_CERT_FILE, and /nix/store is already present in the sandbox.
Related to https://github.com/NixOS/nixpkgs/issues/409848
* descends recursively to all nested volumes
* values are static, update on volume-rescan
* closes#634#1033#1390
Co-authored-by: Victor Phillips <victor.m.phillips@protonmail.com>
previously shelled out to system32/fsutil.exe; expensive and
pointless since all it does is call DeviceIoControl (ioctl)
this is not a security fix; just like most software on windows,
copyparty is still vulnerable to DLL hijacking, so this change
makes little-to-no difference security-wise; commit bb40804f2d
plus, the default config (sharing current folder read-write
without auth) was meant to be obviously insecure, intended for
quick shares on a small LAN rather than untrusted networks
famously, windows prefers cwd when resolving a binary to execute,
rather than a predefined PATH like linux / unix / every other OS
even worse, it also does this for DLLs, and mitigating *that*
is infeasible because it depends on variables we dont control
print a warning in case someone is unaware of this
the ui would still show the option to grant write-permission
when creating a fileshare; pointless since an existing file
can't be overwritten without the delete-permission
while this is obvious and nobody would intentionally create
a fileshare with write, avoid any confusion by hiding it
use libvips as last resort due to risk of OOM; example:
libvips defers to imagemagick for animated avif, and imagemagick
probably does an identify, iterating through each frame, itself
consuming 100+ MiB RAM, which libvips amplifies to 7+ GiB
similar behavior is observed with `identify a.mkv` in a shell
