"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
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
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
previously, `xm` hooks would be called with the `txt` property
containing the url-decoded message
now, a new property `body` contains the original unmodified message,
to avoid any ambiguity caused by url-decoding
if any files are selected, the list of files is appended to
the `txt` field as lines, and as `sel` url-parameters in `body`
Co-authored-by: Carson Coder <carson@carsoncoder.com>
ntfs on linux can be picky about cloning mtime onto a new file;
generally we don't care if that fails, however, we also want the
speedup that CopyFile2 can offer, so cannot use copyfile directly
this avoids the following issue:
up2k:3537 <_symlink>: shutil.copy2(fsenc(csrc), fsenc(dst))
shutil:437 <copy2>: copystat(src, dst, follow_symlinks=follow_sym[...]
shutil:376 <copystat>: lookup("utime")(dst, ns=(st.st_atime_ns, s[...]
[PermissionError] [Errno 1] Operation not permitted, '/windows/videos'
* add RAW image file types to mimetype list
* add RAW thumbnailer via rawpy
---------
Signed-off-by: Adam R. Nelson <adam@nels.onl>
Signed-off-by: ed <s@ocv.me>
an unauthenticated user could make the server inaccessible by
accessing the recent-uploads page and using an expensive filter
fixed by making the filter not regex-based,
only supporting bare-minimum anchoring (^foo bar$)
this fixes a DOM-Based XSS in the recent-uploads page:
it was possible to execute arbitrary javascript by
tricking someone into visiting `/?ru&filter=</script>`
huge thanks to @Ju0x for finding and reporting this!