Selfhosted
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
view the rest of the comments
How does syncthing know what to upload to paperless watch dir if paperless keeps deleting the files after ingesting them?
That'd exactly what you want! When the file initially lands in the sync folder, Syncthing sends it to paperless. Paperless ingests it, deletes it, and it disappears from my phone, now stored in paperless. Exactly what I need.
If I wanted the files to stay on the phone I'd set up the phone as Send Only and the paperless side as Recieved Only.
Oh you delete them from the phone too, ok that makes sense.
I don't delete them from the phone (because they're also in a different app I used since before Paperless) so that's a bit of a dilemma. I'll have to think about it better.
Again, Syncthing supports one-way sync so allowing paperless to delete them and having that delete sync back to the phone is entirely optional.
I mean, how does Syncthing know not to copy a file again if it copied it once and paperless deleted it?
The client on the sender side (the phone) knows it sent the file. It doesn't care if the receiver side changed or deleted it. It sent the file. Its job is done. That's why the mode is called "Send Only".
Meanwhile the client on the receiver side (my NAS) never pushes changes back. It only responds to received sync instructions. That why the mode is called "Receive Only".
It's... all pretty simple. Not sure where the confusion lies?
The phone sync client would have to remember all the files it ever sends, which could be thousands. I've never seen a sync client that works like that, they usually compare the files that are in the source and destination folders. If syncthing can do this that's really interesting.
No it doesn't.
Syncthing only needs to remember the current state of the files/folders it's syncing. Not everything it's every sync'd.
It does that by either periodically scanning the filesystem to look for changes since it last scanned (based on the file creation and modification dates that are stored in the filesystem), or it registers with the operating system to receive events when files are created, modified, or deleted.
When Syncthing notices a create, update, or delete, it pushes those changes to the receiver and then updates it's record of the filesystem state accordingly.
It also pushes whole files, not deltas. So it doesn't care how the files changed, only that they did.
Even with hundreds of thousands of files to sync this is a relatively small amount of state as it's just file paths and their create/modify dates.