My one-liner Linux Dropbox client
lpan.io
lpan.io
What the heck. Anyone has more information about that? Any announcement? And why would it fail to work on an encrypted (LUKS?) ext4 FS when encryption seemed to me to sit below the filesystem (since AFAIK ext4 doesn't support encryption itself)?
”If you received a notification on Linux and you are running ext4, it may be because you are also running ecryptfs. ecrypfts is not supported. However, we support full disk encryption systems, such as LUKS for Linux users.”
Source: https://www.dropboxforum.com/t5/Error-messages/Dropbox-clien...
[1]: https://www.kernel.org/doc/html/v4.19/filesystems/fscrypt.ht...
[2]: https://wiki.archlinux.org/index.php/ext4#Using_file-based_e...
"Unencrypted or decrypted ext4" might be slightly more accurate (although I guess it maybe sounds like you need to remove encryption, not that you just need to decrypt files in memory).
https://www.dell.com/community/Linux-Developer-Systems/XPS-1...
There is almost always at least one unencrypted partition on machines with full-disk encryption, since the boot loader and then the decryption routine have to be launched from somewhere. And yes, OEM recovery partitions or similar laptop-specific needs are another case.
Full-partition would be a more accurate term than full-disk.
I wouldn't know where to start if you want to use ubuntu or another more user friendly distribution though.
Migrating away from that to block-level "full disk" encryption basically requires copying all your files. If you're using <50% of your disk and you feel comfortable doing tricks with partition resizing you can do it, otherwise the best approach is to back up your files (hopefully to encrypted media...) and restore them.
Ceph/RBD with the filesystem of your choice that supports xattrs is pretty much the only way to get full application compatibility.
I guess power users are not the target market.
https://danluu.com/file-consistency/ http://danluu.com/filesystem-errors/
I thought the whole point of an encrypting filesystem was that applications using it would not need to care about such things? Unless you're going below the FS abstraction and actually accessing blocks of the device directly, it shouldn't matter.
For a system like Dropbox, which automatically renames files to things like "file.txt (userbinator's conflicted copy 2018-12-25)", this is a problem. For eCryptFS, whose limit is "we typically recommend you limit your filenames to ~140 characters", (https://unix.stackexchange.com/a/32834), the uncertainty is a problem too.
Dropbox could make this work (and did in the past), but they decided it would be more reliable to say they won't try and won't make promises about their client working 100% of the time on these filesystems. (And I guess their support or business department was not thrilled with the option of "we'll let you try but we won't support you even though you're paying".)
Another example of features not implemented everywhere is the cornucopia of file locking APIs which is why SQLite doesn't officially support being run on NFS.
It's lacking and has a weird workflow, but at least it worked for me. Didn't test it too much as I hated the apple experience and gave away the device.
[1] https://help.resilio.com/hc/en-us/articles/205451025-Can-oth...
[2] https://help.resilio.com/hc/en-us/articles/207370466-Encrypt...
If I have my desktop and my laptop, both using syncthing, does one (my desktop) need to always be online for me to sync files from my other device (my laptop)?
I'd love to use something else besides Dropbox, but it's convenient that Dropbox works as the middleman that is always operating.
What does this mean? Does my desktop always need to be on? Or, can I change a file on my laptop, then, when I turn on my desktop, get those changes on the same file?
To answer the question most directly: If you have only your desktop and your laptop, then for the sync to work, at some point they both need to be powered on and online at the same time. This is one area where syncthing is a bit weaker than some other cloud-backed options; at that point you're essentially paying a service provider to replace the cloud server in my personal setup with their own always-on solution. Personally I prefer not to rely on a third-party, depending on your goals though you should pick a solution that makes sense for you.
I tend to use my phone to ferry information between home pc and work pc. If I change something in my sync folder at work, I'll run sync thing on the pc and phone before leaving, then run it on my home pc and phone when I want the information to update on my home pc.
Another option is to simply have a third system (eg your own server) which is constantly operating on the Internet and running sync thing.
To expand on this (from some googling). All of this requires root.
1) Create a sparse file (actual size depends on usage)
truncate -s 100G /home/zzz/Dropbox.image
mkfs.ext4 -m0 /home/zzz/Dropbox.image
sudo mount /home/zzz/Dropbox.image /home/zzz/Dropbox-fs
sudo mkdir /home/zzz/Dropbox-fs/Dropbox
sudo chown -R zzz.zzz /home/zzz/Dropbox-fs/Dropbox
cp -r /home/zzz/Dropbox-original /home/zzz/Dropbox-fs/Dropbox
6) If we want to mount this automatically at login. Adding it to /etc/fstab may not work because of encryption.
But perhaps some script at login to mount it will work. For example, we can create a script at /usr/local/bin/mountDB.sh and then add a line to /etc/sudoers
zzz ALL=(root) NOPASSWD: /usr/local/bin/mountDB.sh
See the man page for `mount`: https://linux.die.net/man/8/mount (search for "loop")
Here's what the flow looks like:
open(/path/to/myfile) ->
ext4 driver ->
block operations on /dev/loop0 ->
open(/path/to/loop-file) ->
block operations on the data region of the file ->
btrfs driver ->
block operations on /dev/sda
find $ORG_DIR | entr -r rclone sync -v $ORG_DIR $REMOTE:org
is that find will enumerate all your existing files, but starting a new one won't get picked up.
It seems like entr is prepared though, and you should just pass in -d. In fact why use find at all, if you want to rsync the directory?
I have few scripts that rely on entr and I am always sure they are OS agnostic.
EDIT Oh I see what you're saying; that's confusing, though, how's it supposed to work in the first place, then?? :))
Also, if you have an older linux distro that predates inotify(), there's similar functionality within auditd that will log changes to a file with a tag of your choosing, then you can tail the file.
Come to think of it, Dropbox isn't really so great at the notification aspect of this either. It creates a 'conflicted' file but there is no notification that I'm aware of. I have to remind myself to periodically check for conflicts.
Dropbox is now broken for certain Linux configurations and someone had a bit of fun writing a shell one-liner to replicate some of its functionality. Meanwhile, the original eleven year old comment was partly a throwaway remark that it didn't do anything he could not do already which means it wasn't interesting to him (plus two other points, but nobody links to it for those).
That's not even "not really the same", it's "and since you mentioned Dropbox, let's make fun of BrandonM some more". It comes across as just mean-spirited and shitty to me.
This is one of the most relevant topics you could quote it on, really. The post is tackling one-way sync and calling it a rough equivalent to Dropbox.
while true; do find $ORG_DIR | entr -d -r rclone sync -v $ORG_DIR $REMOTE:org; done
I've never used it myself, but I know systemd has file watching built in. I think using `PathModified=/path/to/org` would also eliminate the need for entr [1].
[1] https://www.freedesktop.org/software/systemd/man/systemd.pat...
The systemd solution may be even better, though it seems there is no way to ignore changes in temporary files that emacs likes to create.
(I didn't read any of the man pages)
while true; do ls -d src/*.c | entr -d <cmd>; doneIf your favorite language has access to those, then you can basically build your own file syncing client.
Imagine if such a provider existed and was running on top of ZFS and maintained the current, stable version of 'borg[1]' on the server side ...
Probably too much to ask.
Dropbox has some nice python modules/libraries to support me, so I’m able to download the directory as a zip and extract it in memory.
It’s stupid and unidirectional, but I’m sure more talented people are able to build a bidirectional python Dropbox client in no time, with inotify since python has bindings for this too.
Also includes first-class support for cloud syncing apps.
Personally I used syncthing which doesn't do encryption but also only uses my own devices, so I can keep the data on my machines at all times.
In the past I used seafile which does support encryption (and it's self-hostable): https://www.seafile.com/en/home/
I don't understand why they don't have it even after all these years.
That only supports excluding directories not individual files, and the actual list of exclusions is buried in some local binary config both of which are moderate annoyances - perhaps those are your qualms?
Transport security and at-rest security is very important (and is the best you can do if you want Dropbox's ability to access your files, e.g., so their servers can show your files in a web interface), but it's not the same sort of thing as end-to-end encryption.