I made a video about copyparty, the selfhosted fileserver I’ve been making for the past 5 years.
The main focus of the video is the features, but it also touches upon configuration. Was hoping it would be easier to follow than the readme on github… not sure how well that went, but hey :D
This video is also available to watch on the copyparty demo server, as a high-quality AV1 file and a lower-quality h264.
Now it would be interesting to setup a raspberry pi with harddrives plugged in the USB 3 ports💡
🤯
Elderly raspberry pi B [✓]
Large portable drive gathering dust [✓]
Guess I’m setting up a locally hosted file server in the near future.
Everyone loves CP. Tell all your friends about CP.
I have a question, and I want to emphasise thar this is not criticism but a request for dive into technicalities.
In the video you mentioned copyparty has an one-way sync tool. Is there a good reason why it’s not two-way, or is this just something you weren’t motivated to do?
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.
Thank you for your answer! Do you think copyparty would work together with Syncthing on the same backing directory, or would they compete for changes etc? Copyparty in this scenario would be for sharing content with friends and occasional remote upload
that should be totally fine, I think a lot of people are doing that :>
Look cool! I think you should consider putting a screenshot of the UI somewhere near the top of the README
Oh my gawd what a README!! I’m on my phone and I was trying to scroll back to the top of it from the bottom and I just kept on scrolling… Holy shit I’m going to put this on my kanban board give it proper attention
At this rate might be faster to read code than a read me. Or convert to a wiki style if this much details are really needed.
Haven’t looked at the project yet, but that’s just the greatest name for a fileserver…
Can you point me to the WebDAV code? I’m interested to see your implementation. There are some parts of the spec that are ambiguous, and I like to see how those are implemented in different servers.
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.
Very sleek project. The language switcher bit was brilliant hahaha. Seriously, good job.
The fact you mention security features, without ever saying it’s ‘super secure’ tells me you know a lot about what you’re doing. I’m so sick of apps like this that start with “most secure app on the net” but you know they’re delusional. Thank you, going to check this out.
You made this on your phone on the bus ride to and from work.
I cleaned the cat box yesterday and considered that an accomplishment.
Fuck.
Looks fantastic, I’ll actually be trying this. Love how it doesn’t lock my files into some obscure format like seafiles.
Hey fellow scener, cool project!
Just a few thoughts/questions:
- BTRFS and ZFS support real deduplication via copy on write, and would eliminate all current disadvantages of symlink and hardlink deduplication. It just works.
- Why have it be one huge python source file? This is a serious code smell imo, and something you really should avoid doing as this can be a major maintenance burden.
Just a remark from someone who runs ZFS since the beginning. Many people don’t like the deduplication feature because of its memory footprint.
It’s also nice to have this feature without relying on a certain filesystem.
BTRFS and ZFS support real deduplication via copy on write, and would eliminate all current disadvantages of symlink and hardlink deduplication. It just works.
yeah that’s a good point, I’ll add an option to take advantage of this if you know you’re running on a filesystem where that works as intended.
Why have it be one huge python source file?
oh don’t worry, it’s all separate files during development – there’s a build-stage which bundles everything up into a single file for distribution. But thanks for the concern :D
What do you use to bundle into one file?
copyparty-sfx.pyis a custom packer (see this reply) created by make-sfx.sh, andcopyparty.pyzis a standard zipapp, created by make-pyz.sh. The zipapp has more disadvantages than thesfx.py, so that’s the default/recommended build.
Ah, so you have compiled it into one file? Didn’t know that was possible for python, what tool do you use for this?
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-1so it realizes all hope is lost :Dthe 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)
you even mention ladybird as browser, nice 😎
it’s such an impressive project! Amazing what they’ve accomplished in so little time, and so important too – we need as many options as we can get.
I agree but it’s still in an early development state. Not really usable for everyday work let alone most people never heard about it 😅 But yeah still cool to mention it under “modern” browsers. I wish them good luck with the first alpha next year. I hope it’ll be successful.
