"date" is reserved for the last-modified-timestamp of each file
if extraction of the audio metadata property "date" was enabled
(not default), this would have collided; rename the audio prop
discovered thanks to #1053
also closes#1053, a PR which inspired this commit heavily
(slightly different approach for flexibility and performance)
Co-authored-by: Dawson Jeane <dawsonmjeane@gmail.com>
uploading a folder named COMPLE:X into exfat on linux would fail
because exfat behaves like windows, rejecting <>:|?*"\/
this would also fail on windows, but then due to
sanitize_fn being overly aggressive
fix this by detecting filesystem traits on startup and
also translating vpath early on windows
plus these fixes:
* adds a previously missed libvips optimization,
giving much smaller files at the same quality
* try to align the quality-scale of each backend
(pillow, libvips, ffmpeg) by filesize
turns out reverseproxies keeping the initial Host value is the
far more common case; requiring X-Forwarded-Host is a bad idea
partially reverts ad45de9441
if x-forwarded-for is present, then also require
x-forwarded-host and x-forwarded-proto
avoids displaying subtly-incorrect values on the connect-page
and instead shows blatantly-incorrect values ("example.com")
the headernames x-forwarded-host and x-forwarded-proto can
be configured with global-options xf-host and xf-proto
in addition to write-perms, also drop move-perms from ramdisks
since that is another potential source for confusion
additionally, write-access was correctly prevented, but
the ui would still indicate write permission, so fix that too
* button "dl" in settings UI (always takes precedence)
* global-option and/or volflag "dlni"
* url-parameter ?dlni or ?dlni=0
the preference is applied per-volume when navigating between folders,
unless the settings-button has been toggled, which overrides that
until now, shares could be created with permissions read/write/delete
(any combination thereof), however the delete option was never fully
implemented and dysfunctional, hence now removed
using vn0/rem0 throughout _handle_rm would almost be sufficient
however the primary concern is ensuring integrity of metadata tables,
and _forget_file expects a dbv rather than the share's vn
responses sent early during request processing (primarily for
invalid requests) would display the username " " rater than "*"
in the controlpanel, in one case leading to user confusion
hooks returning exitcode 0 will:
* run the next hook, if any
* allow the original action, unless successive hook opposes
hooks returning exitcode 100 will:
* abort running successive hooks
* allow the original action
hooks returning anything other than 0 or 100 will:
* abort running successive hooks
* REJECT the original action
zmq can now respond with json; a dict with "rc", "rejectmsg",
"reloc" and so on, just like other hooks replying with json
context: if webworkers fail to initialize within 5sec,
up2k falls back to hashing on the main-thread instead
problem: if webworkers eventually do finish init,
they would then be racing the mainthread
fix: disconnect webworkers if init timeout
additionally, gradually extend the timeout as long as
the workers are still making progress initializing
