Ending support for Dropbox syncing to drives with certain uncommon file systems
dropboxforum.com
dropboxforum.com
If instead you used dmcrypt and encrypted the whole device or partition you'd probably have no issue as it looks just like any other EXT4 FS to the system.
Would be a lot better if they specified what features they need the underlying FS to support.
Maybe they’re doing uncommon stuff with ’em that uncommon filesystems cannot cope with... ;)
Thanks, I updated the title.
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.
On the O365 Personal/Home or direct OneDrive plans, it looks like your data remains available but read-only for 3 months, then your account is "frozen." You can do a one-time 30-day "unfreeze" to get access to download/delete (to get under your quota), then it gets "frozen" again. Eventually it'll be deleted, but I don't see documentation for how long that takes. (source: https://support.office.com/en-us/article/what-does-it-mean-w... linked from https://support.office.com/en-us/article/OneDrive-storage-pl...)
> "The installer no longer offers the encrypted home option using ecryptfs-utils. It is recommended to use full-disk encryption instead for this release."
https://defuse.ca/audits/ecryptfs.htm
The full disk block-based (as opposed to this file-based) encryption is really the way to go if you want a good security and performance margin.
Yes, this presents a security risk in that someone could (offhand I think the term is 'evil maid'?) attack the root filesystem, but they could still have done that to the bootloader anyway.
Remote interaction is then required to bring the VMs on that system up.
I don't, but secureboot can detect changes to the root filesystem if you want it to. I think this generally requires setting the rootfs to mount readonly.
This would certainly be more work to set up than vanilla full-disk encryption, though.
"Series of issues?" Really? There were 3, and they were all scored "Low" by the authors for exploitability and security impact.
That said, I generally agree FDE is the way to go if your platform's constraints allow for it -- but only for security. Native EXT4 encryption will give you equal or better performance than FDE primarily because the file system metadata isn't encrypted. Which isn't to say that's a good tradeoff -- it's just the nature of the beast.
Because of performance and functionality issues (file name length, possibility of page cache inconsistency) eCryptfs shouldn't be used for anything any more.
https://defuse.ca/audits/encfs.htm
I wasn't even aware Ext4 had native encryption support though! I'll definitely have to give that a go. Thanks for the tip.
"I was also the project lead for encryption in EXT4, which is now available as the mechanism implementing file-based encryption on Android."
a) This hasn't ceased to work for your desktop - you can continue to do this through the upgrade cycle, as it would only affect new installs (safely converting native fs to dmcrypt isn't possible, AFAIK)
b) during an installation you could eschew FDE and opt for a PV, as I do, that you put your selected, secure LV's onto. I use Debian in preference to Ubuntu, but I'm sure they're materially identical in this case -- two physical partitions -- /boot and not-boot. /boot isn't encrypted in my case, but /, and /home (and a couple of others, though not swap of course) are LVM2 volumes sitting on top of the encrypted 'rest of the disk' partition. If you have /home only with noauto option in fstab , pointing to a an LV on the crypted partition, you could continue to do what you're doing, with the same reduced security confidence.
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/
YMMV ^__^;
I also use Syncthing, which I am very impressed by, it works really well.
Also, when you consider that being offline for an extended period of time means that your files are not being synced, then the purpose of Dropbox is somewhat defeated. Basically Dropbox can't sync without connectivity and if you have connectivity then you would have access to the Keybase "file store" anyway.
Yeah, no, I don't think so. If my bus or train goes through a tunnel, losing my dotfiles or my OneNote notebooks or whatever else is pretty bad.
Forget first world problems--"people almost always have connectivity" is some...like...zeroth world stuff.
I really doubt that in most modern environments (i.e. where smartphones are pervasive) that you are going to go very long without connectivity in an unplanned scenario.
"I copy files out of it to get around that it's not good at what I'm trying to use it for" is not a super winning argument, either.
KBFS is fine. I use it for stuff like SSH keys. It's fine. It's not Dropbox and it isn't substitutable and it doesn't need capes.
The point I was trying to make is that for many people being able to copy back and forth between a local folder and a mounted directory is no different than what they do everyday at work with networked folders. Many people are just moving the occasional document, picture, or folder. For those people Keybase could definitely work as a Dropbox replacement. I don't think the typical Dropbox user is expecting their ZSH profile to be omnipresent on their multiple computers/laptops/tablets.
You may be misunderstanding intent.
Also, to be clear, you could use the mounted files directly, but you just have to be aware that if you lose connectivity you may run into issues. If I was traveling somewhere and I'd like to work on a document in transit then I would recommend copying that to another folder on your local machine first.
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.
No, wait.
I want my computer to do scutwork for me instead because that's its job.
You're describing useful workarounds for the status quo when one can foresee dealing with these situations occasionally. Those are certainly good to document.
But they're workarounds and not true solutions, especially not for frequent needs.
Sorry for letting a rushed comment perpetuate the common Western stereotype of conflating all of Africa as if one single thing.
Long term I do still plan on moving to NextCloud, the core dev team from owncloud moved over and I've always been happy with OC, but I need the time to actually figure out why I'm getting sync errors with the suggested setup after following all the suggested fixes.
One of the machines even runs an old version found in Debian stable repos, but there has been no issues syncing with machines running newer versions.
Only downside for me is that there's no iOS client.
That said, Ext4 is still supported, just not with encryption.
It's a terrible idea to not turn on hard drive encryption. Anyone who gets their hands on the machine can read and write to the drive by booting it with a thumb drive.
With the fragmentation of Linux, even the "most popular" distro may hold a tiny market share. The guys at dropbox probably know far more about their users than what is reflected in some arbitrary popularity contest, so I doubt it's either ignorance or stupidity that led them to this decision.
Edit: Actually I can't find that it was ever the default, but it was a pretty prominent option so I assume this decision is going to mess with a ton of customers.
I know that I installed Ubuntu with default settings, and was pleasantly surprised by that. Not sure about the exact version though.
Both are checkboxes, though, so one could select whichever they wanted. Full disk encryption is the most sensible one, though (better evil maid protection).
I've heard several admins flat out scoff at the idea of using it.
Make sure you have backups with a reliable fs.
Step 1: "You can now use dropbox in fewer scenarios than before" Step 2: ??? Step 3: More customers paying more money
Dropbox is paid for and used in various places I work and personally because of the Linux support. (Their competitors ignore Linux for some reason.) In my case step 2 is going to be them losing at least $1,000 in annual revenue. And they won't have that the next year either (ie recurring revenue). Nor will they be part of future options for work or personal.
Seriously. No company this large can justify supporting a fringe operating system to their investors and shareholders. In a perfect world they would open source what they did to support it so others could pick up the work and integrate it into other products. Oh well.
In places (eg tech) where there is a Linux user base (eg the developers, devops etc) then Dropbox was the main realistic solution for the whole company. It is now just a random entry in that list, and there is no compelling reason to chose them over the others. Heck Google and Microsoft become the top choices simply because that is where the user accounts, email, calendars and then docs end up.
We don't know just how big this "Linux" group is and it certainly is small (your point). I believe the resulting effect will be larger than Dropbox expected. For example the Windows users I collaborate with do so using Dropbox because I use that for Linux. Dropbox might think they are losing me as one user, but they are also going to lose those Windows users too (they find OneDrive far more convenient as it is already there on Windows and in your Microsoft account).
I'd also argue that in aggregate Linux users are more technical and more likely to be influencers. So again that is more future revenue dropbox won't get, unless they get better than their competitors. Recurring revenue is hurt and helped much in the same way as compound interest works. As you add up the missed revenue over the years, it does get to be a big number. And that money likely went to someone else strengthening them. Remember that Dropbox grew essentially by word of mouth. They are going to lose some of that.
The open source approach would be nice, but I am skeptical. Why would a developer spend their time helping dropbox (the server side won't be open source), and not something completely open? The Linux clients done as 3rd party projects for their competitors seem to be far less complete and reliable compared to the vendor implementation.
TLDR: Dropbox did have a unique selling point in their Linux support. Without it they are indistinguishable from their competitors.
They are only partially supporting Linux already (eg no SmartSync). They are now removing support for the default configuration on many existing distros. They are removing support for setups that have worked for years, and earned them much revenue. It is their business and they can do what they want. Linux support is what distinguishes them from their competitors. And now they will lose future revenue from me and others who have posted here about it. Also note that their technical explanation is complete nonsense which is exacerbating the problem. Hopefully they will revisit the decision, or communicate in more detail what the problem actually is. I have no doubt that Linux will fix whatever it is.
News headline - "Company removes X feature"
Hacker News comment - "Company is sure to lose customers over this!"
News headline - "Company reports record profits"
If Dropbox really wanted to save some money, they'd fire their accountants and just rely on armchair HN comments to tell them how well their financials are doing.
Ubuntu doesn't use ecryptfs (or even support it afaik) by default.
This does not appear to still be the case based on testing just now (creating a folder named ".foldername", containing a file named ".testfile" then verifying that they've synced up to OneDrive). Several years ago it didn't support syncing folders with a . in the name, but that was resolved 3 years ago.
With Microsoft's relatively new focus on Git, I can't imagine that problems with repositories stored in OneDrive folders would remain unfixed.
I will note that there are names that Windows Explorer won't let you create - notably, names beginning with a ".". That's an Explorer issue, not a OneDrive or filesystem issue - you can create such files and folders programmatically or from a command prompt.
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.
I mean, the Linux manpage itself says it's stable and can be used, with the inode number, to uniquely identify a file. http://man7.org/linux/man-pages/man2/statfs.2.html
I'm not surprised, though. Fancy copy-on-write filesystems like btrfs have some other subtle gotchas. If you allocate (like, really, not as a hole) a big file on btrfs and mmap it for write, you might see a SIGBUS upon writing because btrfs needed to recompress a block and the new compressed block didn't fit where the old one did.
I've gained a new appreciation for the predictability and simplicity of ext4.
There are even third parties that install it and manage it for you.
This is a shame because I just started using Dropbox significantly more to back up shared photos. Time to search for something else, I guess.
It is (funnily enough) even possible to enable _both_ kinds of encryption simultaneously.
I'd say that they don't use full-disk encryption _instead_ of home folder. They just prompt for it sooner (and it is not the same thing if you have a modestly old machine, or a machine you share with other users).
Edit: It's listed under "Other base system changes since 16.04 LTS" https://wiki.ubuntu.com/BionicBeaver/ReleaseNotes
Atleast the ubuntu server does that, though I wouldn't enable that either way since it's a pain to deal with from the outside.
I'm assuming encryptfs-ext4 has some attribute issue that prevents them for doing efficient deltas. That aside, what's the use case for encryptfs at all? Isn't it strictly worse than LUKS on the underlying volume or a volume file mounted via loopback?
>The supported file systems are NTFS for Windows, HFS+ or APFS for Mac, and Ext4 for Linux.
>A supported file system is required as Dropbox relies on extended attributes (X-attrs) to identify files in the Dropbox folder and keep them in sync. We will keep supporting only the most common file systems that support X-attrs, so we can ensure stability and a consistent experience. (emphasis mine)[1]
XFS may support xattrs but that doesn't mean that Dropbox officially supports it. They are pretty clear on ext4 being the only supported filesystem.
[1]https://www.dropboxforum.com/t5/Syncing-and-uploads/Linux-Dr...
Edit: added link to the proper comment in the Dropbox thread
If Dropbox go ahead with this I'm bailing. The only reason I use a managed service like this is so I don't have to care about the technical details (filesystems etc.)
Of course you can do security for isolation on top of it any time, and sure, you won't get security updates after a while which would be nice, but there are tools to secure an outdated app in other ways either.
Not really.
It is nice to know where my data is.
I was expecting to still be using Dropbox for a while after that, but it's been surprisingly low maintenance after the initial setup, and it has replaced it perfectly for me :) Highly recommended for anyone bothered by this change.
If you're willing to invest setup effort it might also be worth considering Tahoe-LAFS's "GridSync" which seems to be making some progress as of late.
That's a vague assertion that can apply to anything.
> provision enough storage to hold everything
Syncthing can ignore directories/patterns at the local level.
> secure them
And this notion somehow doesn't apply to your Dropbox credentials or shared folders? Furthermore, Dropbox has access to your data - with Syncthing that's limited only to the synchronized devices.
> have a backup plan
Another non-sequitur. Either tool can be part of a backup solution.
It's a very specific assertion which does not apply to every thing: with syncthing, you need to operate every piece of the system. With a cloud service, you are delegating that to other people, presumably professionals. That's a big difference for most people and it has significant implications for things like backups — e.g. if someone breaks into your house and steals two computers, did you just lose every copy of your data?
> > provision enough storage to hold everything > > Syncthing can ignore directories/patterns at the local level.
That's an unrelated topic. This is about the total size of your data and whether it fits on multiple devices without inconvenience. If you have a phone and a laptop, do you have enough storage for a full copy of everything? If not, you need to add a third computer, deal with external drives, etc. One appeal of cloud services for many people is that you can save your data without needing to have enough space to have a full local copy and still be able to access it.
> > secure them > > And this notion somehow doesn't apply to your Dropbox credentials or shared folders? Furthermore, Dropbox has access to your data - with Syncthing that's limited only to the synchronized devices.
Again, this is a comparison question. A service has a separate security trust boundary so someone who compromises your account doesn't get infrastructure-level access and cannot permanently delete things without you having a chance to recover. If you're doing it yourself, you're taking on that responsibility entirely yourself. Maybe you're confident with that, maybe you're not but it's something that you absolutely have to think about for a data storage system.
> > have a backup plan > > Another non-sequitur. Either tool can be part of a backup solution.
You might want to check the definition of non-sequitur – it's not a get-out-of-jail-free card for avoiding an answer. Just to reiterate, ask what happens if your hard drive starts corrupting blocks, someone steals your computer, your house burns down, you get malware which encrypts every file on your computer, etc. With Dropbox the answer is “I buy a new computer and restore my data. Since the malware couldn't overwrite the older copies, I lost nothing”. If you're self-hosting, that could have the same answer but it requires more skills and ongoing commitment to do things like off-site backups.
What I've found to be sadly common is that people do these comparisons without actually matching equivalent levels of service and then get a painful educational lesson when something goes wrong and they lose something they cared about.
Again, this is false. The P2P relay/discovery nodes are operated by third parties donating server time and bandwidth. The user is not required to operate those parts of the network.
> That's an unrelated topic.
Definitely related to storage provisioning.
> This is about the total size of your data and whether it fits on multiple devices without inconvenience.
Convenience is entirely dependent upon the user's requirements. As I said, each node is not required to maintain full replication.
> you can save your data without needing to have enough space to have a full local copy
I'm not sure that putting a significant fraction of one's proverbial eggs in one basket is a selling point.
> If you're doing it yourself, you're taking on that responsibility entirely yourself.
I would add that you're always responsible for your data, third parties or not.
> What I've found to be sadly common is that people do these comparisons without actually matching equivalent levels of service and then get a painful educational lesson when something goes wrong and they lose something they cared about.
You and I could tell those people until we are both blue in the face, they are not going to learn until they have experienced it themselves.
Okay, let's think about this a bit more in depth: who's operating the computer which stores the data? If I have a laptop and a desktop, can my laptop backup its data if my desktop is powered off or my cable modem is down? If those third-parties decide to stop donating their time or something breaks and they don't have time to fix it, does my data still sync?
I don't see how the answers to any of those questions are compatible with “this is false” being a correct statement.
> You and I could tell those people until we are both blue in the face, they are not going to learn until they have experienced it themselves.
… and that's why for most people it makes sense to outsource these tasks to professionals who specialize in that work, just as most people pay mechanics to work on cars and contractors to fix their houses.
Again, my point was not that syncthing is bad but that an open-source project is not the same thing as a supported service. I get that you like this and want to evangelize it but misrepresenting what it does is just asking for someone to be disappointed.
Are you saying dropbox works without computers O_o?
> provision enough storage to hold everything
It's true that on all your clients put together, you need enough space to have one copy of your data; where for dropbox you can have one single sparse checkout and let their servers hold the full data set. I've never seen that be an issue in practice though - on the contrary, my laptops have enough space to hold all my data, and my dropbox account doesn't, which is why I went to syncthing in the first place.
> secure them
What security do you need to add to syncthing that you don't need for dropbox?
> make sure you have a backup plan
I guess dropbox counts as having offsite backup implicitly; personally I'm using syncthing between a few laptops and desktops in different locations and counting that as the off-site backup plan.
I'm saying that Dropbox does not require you to run every computer yourself. If your house burns, floods, gets burgled, etc. not losing every copy is a really nice benefit for the average person. Not needing to make sure that their laptop is running at the same time as a desktop computer is similarly nice for being able to depend on having n > 1 copies.
> > provision enough storage to hold everything > > It's true that on all your clients put together, you need enough space to have one copy of your data; where for dropbox you can have one single sparse checkout and let their servers hold the full data set. I've never seen that be an issue in practice though - on the contrary, my laptops have enough space to hold all my data, and my dropbox account doesn't, which is why I went to syncthing in the first place.
It definitely depends on the user and is less of a problem as SSDs get larger but I definitely know people who had things like large photo/video libraries which they didn't want to have taking up 80% of storage on every computer they own.
> > secure them > > What security do you need to add to syncthing that you don't need for dropbox?
Two aspects: one is relatively low-impact but still worth making sure you're comfortable with any risk of data loss. If you use FDE on your phone / laptop but someone steals the desktop which has all of your synced data on it, is that a problem? Do you forensically wipe drives before getting rid of them? Dropbox's data is encrypted at rest and since they're hosted in a proper data center you don't have to worry about someone stealing a copy as easily as breaking into someone's apartment.
The other is more important now that ransomware is an industry: if you get malware, how robust are your recovery options? Simple versioning doesn't help if, say, the malware touches a file multiple times or if the versioning system wasn't designed to handle malice and so e.g. an attacker can just empty the trash or overwrite the old versions too.
One nice thing about the hosted model is that it has a completely different trust chain so even if you're totally compromised it doesn't allow them infrastructure-level access. That's far from perfect but enough people have recovered deleted Gmail messages, Dropbox files, etc. that it's worth asking whether you're comfortable about your data recovery options in any comparison.
> > make sure you have a backup plan > > I guess dropbox counts as having offsite backup implicitly; personally I'm using syncthing between a few laptops and desktops in different locations and counting that as the off-site backup plan.
That probably works for most scenarios other than a bad security compromise but how frequently do you verify those copies? Does syncthing have checksums to ensure that the copy you think you have hasn't been corrupted?
Again, I'm not saying that syncthing is a bad choice, only that “It works better” is a very broad claim which is clearly not true as a general statement. Convenience and reliability have significant value to most people.
To my mind, the Android app leaves a bit to be desired. Usually you don't want your phone to hold local copies of everything in the shared folder(s) as it is usually space constrained. You want to be able to view and pull files down as desired (possibly with the option to flag individual files to always be cached locally).
Like most open source software: don't bother with the "apps" just install it in termux the same way you would on any other computer.
Unlike what their name (rsync) suggests, they do seem to support Windows clients and aren't *nix only:
1 - https://www.rsync.net/resources/howto/windows_backup_agent.h...
The point of rsync.net is that you can log onto any unix system, anywhere, and interact with your cloud storage - with no software installation or configuration necessary.
The Windows Backup Agent works very well and has recently been updated but the documentation you are seeing reflects the fact that it is a secondary function here at rsync.net that is mostly provided for the convenience of customers in mixed environments.
We are not a dropbox alternative.
This is a weird, known issue that somehow keeps cropping up on our init7 network connection specifically to scandinavian countries.
I'm sorry we couldn't resolve it.
If you can stand your data being in the United States, our Denver location has a 10gb he.net fiber connection which is God's own Internet. Recommended.
I’ve seen many other services have major issues syncing files... dealing with conflicts, corruption, random file types like issues around Mac resource forks and file-folder types, etc. I’ve seen weeks of work get lost because gdrive stopped syncing, then when resuming overwrote all of a colleagues updated files.
Dropbox has solved all such problems.. in part because they’be been around forever, but also because they’ve hired great talent to do nothing but sync. I trust them way more on that core competency.
If you look at the filename on the linux download is says 2015 in the filename. Has the linux client gone untouched for 3 years?
Dropbox is violating their philosophy as a universal solution and squandering their key selling point for some small cost savings. What a horrible decision.
Time for some of us to start work on adding extended attributes to more filesystems?
Source: Using XFS at work for OpenStack Swift, which makes extensive use of xattrs and thus prefers to run on XFS.
So, if other programs follow suit, will we start seeing options to lie about the filesystem type?
Right now it just links to the second page of the discussion; the community moderator's message is on the first page.
The sync client has worked flawelessly for me so far. Plus you get CalDAV/CardDAV right out of the box.
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."
a- FS is something we support, great! Go on... b- FS is an unsupported one, so run the tests and if they pass warn the user: "Hey! We don't support this, but it looks like working. If it fails we can not support you. Are you sure? (Y/N)" c- FS is an unsupported one, so run the tests and if they fail tell the user: "Hey! We can not work on this FS, sorry.".
The good thing is you implement the tests once. Since, POSIX standard is a standard, so run the tests over that interface. You practically don't need to maintain anything about the tests. Maybe run a couple of unit tests over a simulated environment, that's all.
If you are going to pay for something, Insync and Google Drive make a decent Dropbox alternative. I'll be honest, though, I simply stopped using syncing solutions like these, so I really don't know if there are now better options across platforms.
Btw: Resilio Sync used to be known as BitTorrent Sync.
Their focus seems to be on cost cutting and better value extraction than growth and features these days.
Dropbox tells with a very unhelpful popup: "Move Dropbox location - Dropbox will stop syncing in November".
And on the forums, dropboxer Jay precises that starting Nov. 7, 2018, they're limiting support to Windows / NTFS, macOS / HFS+ & APFS, linux/Ext4. They say missing X-attrs support is what guides dropping other fs.
They didn't answer yet if displaying this message to users of common-through-Ubuntu Ext4+ecryptfs is intentional.
Colin is the founder, and also a HN celebrity because of this comment (which he regrets, but never gets old):
And then how does that compare on macOS where there's JHFS+/HFSX and APFS?
Think nerd friendly and minimal, like NearlyFreeSpeech is to domain registrars
So, why would one pay?
EDIT: Found it.
For the record I would be very glad if I could seamlessy use ZFS, but from my perspective it looks like a lot of work that can break in unexpected places.
I used these instructions:
https://nixos.wiki/wiki/NixOS_on_ZFS
Ironically, I felt less of a need to use ZFS on NixOS. I don't have a large pool and snapshotting the system is not really necessary, since in NixOS you can always roll back to a non-GCed previous version on your system. But I use filesystem compression and might use snapshots on /home.
Just because Red Hat marked btrfs deprecated on their systems, doesn't mean the technology itself is deprecated.
Also, from what I've read, they deprecated it because of resources issues rather than tech issues (seems like they had 0 btrfs devs and lots of XFS specialists on the team).
SUSE is pretty much dead. Anything still running on that should be planning budget and resources for a migration.
EDIT: Shit, misread -- those are the supported ones. Thanks for the headsmack. :-)
Also, I'm pretty sure Btrfs supports xattrs unless I'm missing something.
Yeah this is not how it works. This is not how any of this works
> A supported file system is required as Dropbox relies on extended attributes (X-attrs) to identify files in the Dropbox folder and keep them in sync. We will keep supporting only the most common file systems that support X-attrs, so we can ensure stability and a consistent experience.
Certainly XFS supports xattr and hence ideally should be supported. I don't know why they singled out ext4. I am running Dropbox on ext4 LUKS encrypted partition and I haven't seen the warning yet.
Lose the most active users, keep the ones paying for something they don't need.
Why? Because there's always exceptions for 'abuse of service' and other exemptions.
The only time something is unlimited is if you do it yourself. Then you only have yourself to lean on.
Because the alternate explantation I assumed is that they don't want to continue maintaining a bunch of different filesystems. That complicates development quite a bit (because you need to have developers who know the quirks of the file systems) and testing a lot (because all changes have to be tested on all variants, and it becomes multiplicative when a platform has multiple file systems).
But they don't have to maintain a bunch of different filesystems. That's the OS's job. From the application's PoV there shouldn't be any difference between these filesystems, all they need to do is check if the required feature (xattrs) is enabled for a certain FS and that's all.
My guess at the time was that they were using it for cheaper rename detection, using an xattr UUID, instead of using heuristics to compare {inode, btime, mtime, size, name, folder}.
In other words, they would match up the xattr UUID across CREATE and DELETE events to merge them into RENAME events.
Missing RENAME events is pretty bad for the user experience as it can lead to a loss of version history when the file ID changes through the DELETE, CREATE events.
Anyone have any other ideas as to why they would be reliant on xattrs?
It prevents a whole lot of pipeline and concurrency optimizations since it forces you to rehash every file in the change set, before your rename detection algorithm can kick in.
For example, if a user renames a root folder with tens of thousands of descendants, then the hash approach would have poor time-to-first-change-synced latency.
Furthermore, relying on file hashes won't actually work.
A user could have done both a RENAME and UPDATE on the file, since the sync app last ran (you need scanning logic for this, and can't rely solely on inotify). To survive a RENAME and UPDATE, you would then need to compare partial file hashes. But again, it affects latency too much.
Move to where? How do I get it to work on Ubuntu again?
Slack has the better part of a billion dollars in funding for what's essentially resource-hungry IRC with pictures. Dropbox does little you couldn't accomplish with a server and rsync.
What I'm really eager to see is git for everyone else.
Most cloud storage providers offer rudimentary versioning; are you referring to the idea of promoting commits to being first-class? It would need to be baked into Word, Excel and similar, and those tools already have builtin version tracking, as horrible(?) as it is, so... :/
Of course, a solution that works well with all the different binary file formats people in those fields use wouldn't be easy.
It would definitely need to work with large files though, which categorically precludes Git.
The first point, I think, would be building a delta engine with case-specific code for the most common ubiquitous file formats, like docx, xlsx, psd, etc. Of course it wouldn't be able to be perfect with everything but it would certainly be better than eg just recompressing each version or something equally naive.
The UX would be the next major hurdle. Time Machine is a good example of the kind of simplicity that would be needed, but it would need to be a have a bit more surface area to be applicable and useful to all scenarios.
One other feature that comes to mind, which would be incredibly difficult to get right but probably critical, would be useful version diffing. I think keeping this simple and just building something that can do $anything->SVG (with maybe cheats where bunches of the SVG is mostly just a bitmap in certain cases) and then doing something fast on the SVG (and/or its bitmap contents...) would probably be the most viable target.
No doubt there would be a learning curve. I think that's OK. The target market here is serious users who already dedicate time to learning professional tools like Photoshop.
:(
That would take years to get anywhere with ._.
The diffing idea I suggested above is just manageable, a la macOS Preview, with hacks. Branching requires folding-back-in, and that's not just a case of "A or B", it's a case of "A, B and C conflict with D and E, while F G and H are okay," where I could then say "save B and E but drop F". If B is a layer, E is an imported asset and F is a custom filter... you get the picture. You need a reimplementation of Photoshop (halting problem).
:/
Sad that everyone hates GIMP.
But... hmm, this could get folded into Blender, and then make the rest of the industry jealous.......
When you simplify and generalize git to the point where "everyone else" can use it, you get Apple's Time Machine and Windows' File History. I'm not that familiar with Time Machine, but if File History had a more visible interface that you could use to easily "checkpoint" individual documents or directories on demand, you'd pretty much be there.
Branching is too complicated for most people to work with and overkill for most scenarios.
Also, to get more ideas:
echo "Make a startup with "$(ls /bin /usr/bin | sort -R | head -n 3)This has aged gloriously, thank you!
The 3G was the breakthrough model, but I lend that as much to the dock connector (which was available in USB and FireWire) and the growth of x-platform iTunes as anything.
The broader point that it required Windows support for the iPod to become mainstream is of course true. That said, the iPod was also the reason so many of us became Mac users in the early 00s because the “halo effect” was undeniable.
This idea that we're always making sale predictions is a vice of the startup culture.
Thankfully your options are not limited to either Dropbox or FTP. Thus people who want simplicity can have Dropbox (or similar) and people who want control can have sshfs or any number of other tools out there that require some assembly but also don't suffer from the numerous problems that pre-TCP/IP protocols like FTP suffer from.
I’m literally talking about the theory of the paper by Richard Gabriel (https://www.dreamsongs.com/RiseOfWorseIsBetter.html) which is that worse solutions often win because it takes too much time to bring a good solution to market.
If you were trying to make a “good” solution to the problem addressed by Drop Box, it probably would not look like Drop Box. For example, you’d do a real network file system that wouldn’t need to do a binary diff of the file each time to see what changed, because it would have access to the block level changes at the file system layer.[1] You'd have file locking in the protocol (like CFS), and could sync data from a locked file instead of waiting for the lock to be released.[1]
It also probably wouldn’t have made Houston a billionaire because who is going to install a kernel driver off the internet? But on the flip side, Dropbox almost certainly killed much of the interest in real network file systems, because it is good enough.
Which is why we’re all using an internet powered by Javascript, Electron apps on the desktop, etc. Worse is better.
[1] https://www.dropbox.com/help/syncing-uploads/upload-entire-f...
[2] https://www.dropbox.com/help/syncing-uploads/stuck-syncing
NFS and AFS (from what limited I know of it) are more designed for local networks thus to leverage NFS over a WAN you'd then need to tunnel your connection (eg via SSH or VPN). So while there is obviously overlap between them and Dropbox I wouldn't really say the two are all that comparable.
However to answer your point, I don't think anyone would disagree with the specific part of your point regarding how simplicity is often better than something arguably more powerful. However just because something is simple it doesn't mean it isn't also good. "Good" is just a question of whether it meets requirements. If your requirement is that it can be installed and operated by layman then Dropbox is a far better solution than any other the other proposals you've mentioned.
Well, there is an sshfs FUSE filesystem, for what it's worth
That's being a bit alarmist, isn't it? It's not worse is better. It's the right amount of compromises is better. Or, "good enough is better".
Perfection usually has diminishing returns and is rarely obtainable. Worse is not better. Good enough is better; objectively so.
Even SMB is better
A good comparison would be comparing using make files and a simple text editor like vim to visual studio. Is visual studio truly better because it offers more features when a make file and vim can do much the same? A programmer used to VS might call the make file method worse, but the reality is that it is the simpler path which makes it better. Realize that simple doesn't mean "simple to use" but simple in terms of complexity (philosophical simplicity is at play here).
Worse is better is better translated as "A simple design is better, but not from the users perspective."
> Simplicity -- the design must be simple, both in implementation and interface. It is more important for the implementation to be simple than the interface. Simplicity is the most important consideration in a design.
> Correctness -- the design must be correct in all observable aspects. It is slightly better to be simple than correct.
Dropbox is simple in implementation, at the cost of simplicity in the interface and correctness. E.g. it is simpler to simply punt on locked files in Windows. Tell the user to quit Word if they want their file to sync, instead of handling file locking at the protocol level. Likewise, it's simpler to detect changed files after the fact than write a filesystem driver to knows what blocks are changed. But it degrades the user experience (their computer burns clock cycles re-figuring-out information a real filesystem driver would've had).
The upside of all that is that Dropbox was simple to implement, simple to port, and simple to deploy, which made it popular:
> Therefore, the worse-is-better software first will gain acceptance, second will condition its users to expect less, and third will be improved to a point that is almost the right thing.
How many files do you have? I've got 26000 files in my Mac's dropbox folder. (Granted, very few of them change more than once or twice a day; maybe 20 or so of those do.)
EDIT: Clearly not just me: https://news.ycombinator.com/item?id=12464901 (thread from 2016)
If this was your intent, then using the tired "worse is better" trope and claiming an issue from 7 years ago, that no one else has claimed to have seen is seems a far cry from it.
Dropbox became popular because it was easy, it worked, and did exactly what it said it did. That might be "dumb" in that it's not feature packed, but you use a lot of negative connotations when none are required.
IIRC, there was a variable, hard limit for objects in a folder or locks in a folder where it would go wacky.
Docker (3.13) Dropbox (2.08) Outlook (2.03) Safari (2.02) Slack (1.57)
Total 131771 files currently on disk (I'm using Selective Sync, because SSD prices)
And famously so.
I set my grandmother up with Synctrayzor and she doesn't know the difference between that and Dropbox.
It is missing the ability to share things with a direct link, or share a repository or folder "easily" (read: in the same way it's done with Dropbox), but the trade off has been worth it for me.
You run it on your machines and they will sync among themselves. No need for any cloud backend.
Some people with Synology or QNAP run an instance on their NAS.
2) you can run your own off-site instance, that can be hosted with your favourite cloud provider.
How much would it cost to hire an admin to set up and maintain that instance?
The whole point of Dropbox is that I don't have to do any work.
Individuals don't, but most individuals have no clue about the repercussions of hosting their plaintext data on Dropbox in the USA. Its a ticking timebomb.
For example, if you have Synology or QNAP, there are packages to sync with cloud providers, like Backblaze B2, Amazon S3, Azure Cloud Storage, etc. So if one of your syncthing sync instances (which you can make with few clicks) is such a device, with few more clicks you can choose your cloud platform and backup to that.
Or you can be using something entirely different. That's the beauty, you can use whatever fits your needs and budget, you don't have to fit yourself to limitations of one or two pre-packaged solutions. You can do something entirely different, e.g. if someone from your family also has some NAS, you can backup to each others devices and not rely on third parties at all. The possibilities are limitless.
For every human being on the planet needs their own privacy. Its a common theme in the EU, but it isn't only important within the EU.
Therefore, there are two viable options:
1) You store your data locally (encrypted if you want to protect against burglars).
2) You store your data remotely, but encrypt it before you send it and decrypt it after you receive it (public key cryptography).
There is no other, viable, long-term option. Dropbox's solution is a short term solution.
Now, the question is whether you really need to sync to your LAN right away. You most likely don't. You can just sync in the evening and at night while your device(s) recharge. If you really need to sync ad hoc you have the option to punch holes in your firewall, or use a VPN. One opportunity for innovation here is to allow a user to define what must be synced right away over WAN and what shouldn't. Another opportunity is to make cloud backups easier. But these require the above requirement #2, and as you might know, public key cryptography just doesn't seem to be user-friendly.
Speaking of which, you can use such together with Cryptomator or GPG or whatever and synchronize your encrypted files. To any cloud. Or you can sync it to your NAS which stores them on an encrypted filesystem.
You can do that with Dropbox/Google Drive/etc as well. But I'd use that as yet another encrypted backup of my most important NAS content.
My instinctive reaction is not to trust any brand new effort without more evidence of its correctness.
Where can I find more information on this? Search is failing me.
I intermittently maintain a list of these things at https://github.com/pjc50/pjc50.github.io/blob/master/secure-... ; none of them have ever been precisely what I wanted. The cheap alternative to Dropbox with Linux support you want was "Hubic" from OVH (edit: now discontinued)
"These folders are encrypted using only your device-specific keys and mine.
The Keybase servers do not have private keys that can read this data. Nor can they inject any public keys into this process, to trick you into encrypting for extra parties. Your and my key additions and removals are signed by us into a public merkle tree, which in turn is hashed into the Bitcoin block chain to prevent a forking attack. Here's a screenshot of my 7 device keys and 9 public identities, and how they're all related."
Not meant critically, I love that they exist and found funding. It's just, as long as the model is "once the privacy shit hits the fan in some widely published scandal, we'll be the one that's ahead" there's only two outcomes: 1. It doesn't happen soon enough and Keybase runs out of runway, or 2. It happens, one of the many Keybase products becomes wildly popular because of it, and Keybase will ditch the others because "yada yada focus core business".
Although it's arguably a more intelligent decission to share private files not with a company like dropbox.
You sync across your devices (or anything where you can run a standalone binary). Phone, PC, server, whatever. It's pretty good and very stable when your packager doesn't fuck up the service file (https://svnweb.freebsd.org/ports/head/net/syncthing/files/sy...).
> without the need to set up configure your home nas
That's only needed if you need access to your files from the outside world (which is probably a bad idea). For instance, my ~/Documents are syncthing-only, not available through my Nextcloud instance. Can't access my payslip from last year on my phone. Can't have it stolen through that channel either!
(Sure, "don't do that then", but I'd rather not have to remember to not do that)
Hubic has been discontinued recently as a non-core business to OVH[1].
It is not like they are not implementing a feature but removing one.
Seriously.
Dropbox is but a new Linux kernel module away from being completely and utterly irrelevant.
$ insmod ifps
Which one of these are old?
By the way, NTFS dates back to 1993. It not included in the expiry list. Every file system mentioned as losing support is newer than that, and they're all under active development and getting better all the time.
XFS became the default file system in Redhat 7 and derivatives. ecryptfs is the default for home directories on Ubuntu. They're talking about wiping out a significant proportion of Linux users here.