361–370 of 429 posts
dropboxforum thread here: https://www.dropboxforum.com/t5/Installation-and-desktop-app...
Why not run a small set of tests after installing and see whether the required set of FS features available? Experienced users run plethora of filesystems which support the needs of dropbox. IMHO, this is a lazy solution to a relatively simple problem.
I'm an architect for a Dropbox competitor. Sometimes we need to draw a line in the sand for what we support, and what we don't support. This is mostly due to balancing cost / benefit. A customer may do something strange that we don't support, and we have to weigh how many engineering resources it will take to support the customer. This can apply to unusual filesystems that we don't actively test our product with.
IMO, Dropbox did the right thing. It's only real technical users who get into different kinds of filesystems; and these are the same kind of users who can understand, "Dropbox only works on X, Y, and Z."
Earlier quoted context omitted.
Doesn’t mean the niche user base isn’t big enough to support a small scale operation Think nerd friendly and minimal, like NearlyFreeSpeech is to domain registrars
Those little already have syncthing for sync and borg/duplicity systems for backup. (With a backend of choice) Why would they use a service that locks then in to one provider?
It appears this might be related to dropbox (mis)using statfs's f_fsid field as part of its authentication system. The dropbox devs apparently assumed that this field was stable, but on XFS (for instance) it can change. dropboxforum thread here: https://www.dropboxforum.com/t5/Installation-and-desktop-app...
Once saw a system that used inode numbers as "unique identifiers for files on local disk" and it turns out that on Linux / ext filesystems, they're not unique (they get reused if you delete a file and then create a new one). That team just decided to not support Linux at all.
Earlier quoted context omitted.
> I take your point that they use different mechanisms to provide access to files which are not fully interchangeable. With that said, I think many people probably don't really care or have a need for offline access, since nowadays people almost always have connectivity. Given this I would say in many (maybe most?) instances Keybase could replace Dropbox in practice. Yeah, no, I don't think so. If my bus or train goe…
Really? If you lose access to your dotfiles and OneNote notebooks for 5 or 10 minutes (that would be one long tunnel) that's completely unacceptable? This also sounds like a daily commute that could have easily been planned around if that time is really that important. Besides, when I work with Keybase I copy the files to my machine ahead of time to a local directory, so I likely would never notice such a drop in con…
Being on a NYC subway train is an even more interesting case, because depending on the precise client setup there's often intermittent or bad connectivity but rarely a good sustained connection between stations.
As in most of the world, smartphones are pervasive in both of these contexts.
Mobile and computer apps used to support these cases a lot better. As Bay Area connectivity has gotten better in those areas where well-off techies congregate (e.g. not underground Muni Metro), apps have gotten much worse at this except for apps targeting developing countries like India and Africa.
Earlier quoted context omitted.
I use Google drive, but the Linux support was awful and I started using insync. It's about $25 for a lifetime license and I love it. I run Ubuntu with encrypted home and have for years. It works great and I highly recommend it, and I don't work there, just a happy user. The Nautilus integration is decent too.
Not trying to rain on your parade, I hope it fills your use case. However, my IT company onboarded a media-intense client with insync and it has been nothing but a nightmare. There are hardcoded limits (like only syncing two files at a time, IIRC) that make it effectively useless for anything beyond small, personal use. It's cheap and you get what you pay for.
rclone is rsync for cloud storage services -- https://rclone.org/
Earlier quoted context omitted.
On the contrary, Ubuntu 18.04 dropped the home directory encryption entirely and now only supports full disk encryption.
Indeed: https://wiki.ubuntu.com/BionicBeaver/ReleaseNotes#Other_base... > "The installer no longer offers the encrypted home option using ecryptfs-utils. It is recommended to use full-disk encryption instead for this release."
Earlier quoted context omitted.
Home directory encryption via ecryptfs is now the default in most Ubuntu variants, and it would be insane not to attempt to support it. That said, given that my Dropbox subscription just renewed (and that Linux is pretty much the only reason I'm still using it, since there is no OneDrive client I can rely on), I am really sad this seems to be a future direction for Dropbox.
You could use Nextcloud instead.
I also use Syncthing, which I am very impressed by, it works really well.
Earlier quoted context omitted.
Encryption is opt-in, not the default.
I'm pretty sure home-dir encryption was the default with Ubutunu 15.04. I know that I installed Ubuntu with default settings, and was pleasantly surprised by that. Not sure about the exact version though.