Small and lightweight cloud storage written in C99 and POSIX.1-2008. https://gitea.privatedns.org/xavi/slcl/atom?h=v0.5.0 2026-06-13T07:38:00+00:00 2026-06-13T07:38:00+00:00 Xavier Del Campo Romero xavi92@disroot.org 2026-06-13T07:38:00+00:00 urn:sha1:30e9bcc492ffa81dabfd316a295ff4d20daaec3b Previously, HTTP error 403 was returned if an unauthenticated user attempted to access a file or directory inside /user/. However, this error message confusing because, most often, it was caused by legitimate users with missing or expired HTTP cookies. While the usual workaround was to access /index.html and authenticate, this was too confusing to some users. 2026-06-13T07:37:36+00:00 Xavier Del Campo Romero xavi92@disroot.org 2026-06-13T07:36:55+00:00 urn:sha1:3db69a5f7fdf2db48d512f60a9afe6b894877dba 2026-06-13T07:35:41+00:00 Xavier Del Campo Romero xavi92@disroot.org 2026-06-13T07:35:41+00:00 urn:sha1:8815a8b9ea8b6e5f95b056e64b15a5f049790a80 2025-10-10T13:29:55+00:00 Xavier Del Campo Romero xavi92@disroot.org 2025-10-10T13:29:55+00:00 urn:sha1:6a3a0f45f65f9be58867f271ff2a027548789bd7 2025-10-10T09:20:25+00:00 Xavier Del Campo Romero xavi92@disroot.org 2025-10-10T09:20:25+00:00 urn:sha1:4fa8915c8cd42b8bc30df3714e5163c4f4bece89 Otherwise, it is not ensured web browsers would translate a relative directory such as "dir/.." to a URL with a trailing '/'. Therefore, a POST request to "/user?download=1" would fail because slcl only considers "/user/" (note the trailing '/') as valid. 2025-10-09T08:58:59+00:00 Xavier Del Campo Romero xavi92@disroot.org 2025-10-09T08:53:36+00:00 urn:sha1:57efdf774510c2b3bd114266af81843919421d55 2025-10-08T00:03:17+00:00 Xavier Del Campo Romero xavi92@disroot.org 2025-10-07T23:48:14+00:00 urn:sha1:9542016d5d820eef0882ed7f4c3da5f238453707 So far, clicking on a directory name previewed it, whereas clicking on a file name would download it, and file previews were on a separate column. This behaviour was found to be confusing, so it has been simplified. Now, clicking on a file or directory name would preview it. On the other hand, the "Preview" column has been replaced with a "Download" column, so that both files and directories can be downloaded. Thanks to Avron for the suggestion. [1] [1]: https://codeberg.org/xavidcr/slcl/issues/2 2025-10-08T00:03:16+00:00 Xavier Del Campo Romero xavi92@disroot.org 2025-10-07T23:46:36+00:00 urn:sha1:9b928c550d53b313f8d138b6929d8b94bd699740 It feels more intuitive to keep the thumbnail and file name as first columns. It is assumed removing files and/or directories is not the main interaction from users. 2025-10-08T00:03:16+00:00 Xavier Del Campo Romero xavi92@disroot.org 2025-10-07T21:45:32+00:00 urn:sha1:32c4b34829e3d2d43f405c98f6edff32ae96a74a 2025-10-08T00:03:05+00:00 Xavier Del Campo Romero xavi92@disroot.org 2025-10-06T21:02:51+00:00 urn:sha1:00dd37604d50cbf3fb27ec0631b4d4b6d2ee893a Thanks to the fdzipstream library [1] and zlib [2], it is possible to generate ZIP files on-the-fly, therefore requiring no extra disk space usage and only a small amount of memory. Unfortunately, as of the time of this writing fdzipstream is not packaged by any distributions yet [3], so it had to be imported as a git submodule as a workaround. While libarchive [4] could be an interesting alternative, writing ZIP files is only supported by very recent versions (>= 3.8.0), which are still not packaged by many distributions [5], either. Moreover, libarchive is a package with several dependencies other than zlib and is significantly larger compared to fdzipstreams, so fdzipstreams was ultimately considered a better fit for this purpose. [1]: https://github.com/CTrabant/fdzipstream.git [2]: http://zlib.net/ [3]: https://repology.org/projects/?search=fdzipstream [4]: https://www.libarchive.org/ [5]: https://repology.org/project/libarchive/versions