The best and recommended way to connect to copyparty (either from windows, linux, or macos) is with WebDAV -- this will give you much higher performance. WebDAV is also a MUCH safer choice when connecting over the internet, since it is just https after all. Meanwhile, exposing SMB to the internet is generally a recipe for, well... nasty surprises :-)

There are also very copyparty-specific reasons to not use the SMB-server, and these are explained in the readme. That's also why the SMB-server is not possible to enable in any of the official copyparty distributions without manually obtaining the necessary dependencies for that (impacket).

There were comments about security risks though, based on being a small project with a LOT of integrations.

time will show, but the only thing i actively regret adding was the support for discord embeds (the "og" option); opengraph is an awfully designed concept and, unrelatedly, it has been a source of a handful of bugs in how it was implemented in copyparty (that one's on me). Keeping that disabled avoids a lot of edgecases, most of which are decreed by the opengraph spec.

That said, there's no features keeping me up at night; i think for the most part things are fine -- just don't enable the smb server 😁

hfs v2 (the old banger of an exe) is no longer being maintained and has some known unfixed vulnerabilities, however there is now a rewrite (hfs v3) which is shaping up really nicely.

should also mention that copyparty is also available as a windows exe which will run without python or any other dependencies

so uhh, sorry for the late response to this -- was going to reply much earlier, but then suddenly it became more timely than ever...

the good news is, I'm fairly confident in how it handles the filesystem and permissions, preventing unauthorized access to files.

but the part I'm a bit less sure about is sanitizing user data; the kind of vulnerabilities where someone uploads a malicious file and bad stuff happens if you then open that file in a certain way, or someone sends you a malicious link and trick you into clicking it -- in other words, the kind of vulnerabilities which require the attacker to have a certain level of access already, or that requires tricking you into doing something.

...and with version 1.18.5 released just now, we got a prime example of exactly one of those. Really unfortunate timing, but it's a blessing to have so many new and curious eyes on it to spot these sooner rather than later. It is what it is.

the intention with that statement was that seafile, by default, places all the files inside its own proprietary file container thing, where the files are not easily accessible from the server's actual filesystem, using regular linux utilities. My knowledge of seafile is really minimal, so this could be wrong -- in which case I'll fix that right away! or, at the very least, try to clarify what I meant to avoid this confusion.

in case you happen to know -- are you aware if it's possible to use Seafile while having it just place all the files and folders on the disk like any other program would?

awesome thanks, should be able to reproduce it then :>

man... that's really unexpected, I went with h264+mp3 which should be the most conservative / broadly-supported combination you could possibly use, yet still (ﾉ ﾟヮﾟ)ﾉ ~┻━┻

what webbrowser / device / player are you using?

that should be totally fine, I think a lot of people are doing that :>

No worries, good question :>

The problem with bidirectional filesync is that it's an absolutely massive can of worms, very easy to mess up, and the consequences of messing up are usually the worst kind (loss of data). There's an insane amount of edgecases to keep in mind, and you need to get every edgecase right every single time, otherwise you might wipe someone's vacation photos, or suddenly downgrade someone's keepass database to an older version... And stuff like syncing multiple devices to the same server makes it balloon further.

I've started becoming more confident in copyparty's filesystem-index database, but it's still just a hint/guideline, with the filesystem being the only source of truth -- it's still not something I'd trust with tracking sync-state against one or more clients.

The bigger guys who offer bidirectional sync (nextcloud, syncthing, etc.) have spent years perfecting their logic, so I'd like to leave this in their capable hands.

copyparty-sfx.py is a custom packer (see this reply) created by make-sfx.sh, and copyparty.pyz is a standard zipapp, created by make-pyz.sh. The zipapp has more disadvantages than the sfx.py, so that's the default/recommended build.

sure! my implementation is really basic, just the stuff that's needed to make the clients i've tested happy, so there's probably still clients that won't be able to connect (And i'll fix those as soon as I hear about them!)

httpcli.py is the http methods handler, and the webdav-specific handlers are all next to eachother, propfind // proppatch // lock // unlock // mkcol // and there's also put for the uploads, but that's not entirely webdav-specific, just webdav-aware.

sooo this is one of the things that started with someone saying "wouldn't it be funny if..."

if you open copyparty-sfx.py in a text editor, you'll see how -- but please make sure to use an editor which is able to handle about 600 KiB of comments which contain invalid utf8 / binary garbage 😁

I ended up rolling my own packer since I wanted optimal encoding efficiency, and everything I could find would do stuff like base85 or ucs2 tricks, but it turns out python is perfectly happy with binary garbage in comments if you declare that the file is latin-1 so it realizes all hope is lost :D

the only drawback of the sfx.py is that it needs to extract to $TEMP before running, so that's the slight advantage of the zipapp (the .pyz alternative), but that suffers from some performance reduction in return, and is more hermetic (doesn't let you swap out the bundled dependencies with fresh versions as easily if necessary)