The most requested feature, to allow a file or folder to be ignored by Dropbox sync without using selective sync is finally in beta.
The community requested a .dropboxignore file but they chose another solution which I’m sure is reasonable for making the feature more user friendly to non-devs.
This will be immensely helpful for node_modules or build target directories.
That story makes me want to become a goat farmer every time I read it, but, Dropbox must have intended that usage if they had a publicly available API, right?
Dropbox as a VCS for separate documents intended to be accessed by non-technical users is not a terrible solution. Certainly there are better options, but I think something built on Dropbox could be workable in this case.
the problem with this solution seems to me that you can't easily recursively ignore e.g. `__pycache__` or `node_modules`. sure, it's less complexity than defining and parsing an oddball text file with potentially weird glob expressions, but also less powerful.
I can imagine a world where a arbitrary directory is filled with gitignore, dropboxignore, googledriveignore, backblazeignore, s3ignore, rsynciginore, dotignore, ipfsignore . . .
Except dropbox will be totally unaware and try to access it.
What i envisionned was more like a "control center" app of all the outgoing (and incoming) pipes from your FS to syncing systems, with both last syncing time, configuration, etc. A little bit like what's already happening for mail and calendar integration into iOS applications, only for files and on the desktop.
Yes, right now Dropbox would probably crash, but that's their problem. I really don't think it's something that should be handled by the OS when they already have a solution for it.
This isn't really a great solution when I have files that are autogenerated. I either have to have the default group be "cloud" and then go back and chgrp these files when they are generated so they don't sync. Or I have to have the default group be something else, and inevitably forget to chgrp for files that I do want backed up.
Windows (and some other OSs) have/had an "archive bit" ¹. It used to be visible in the file properties, next to the read-only and hidden attributes, and was labelled "Archive" ²
Some file-system level property could work, but the semantics of the archive bit don't match. For files I want to be ignored, I don't think it makes sense to mark them as backed up, which is what the archive bit was designed for.
I think the problem here is poor tooling that contaminates your working directory.
If you look at something like Bazel, all the build artifacts end up in ~/.cache (or similar). Thus there are no artifacts to gitignore. OCI container builds ("docker images") are done by simply adding artifacts controlled by a build rule into the image (rather than starting a vm/container, copying a working directory into the container, and running random shell commands).
To summarize, I think the problem is that node puts packages in your working directory instead of some other location, causing you to have to ignore them. It is reasonable to check in your dependencies, in which case node's strategy is fine. But you can compare this to something like go, which puts all modules in $GOPATH/pkg/mod and if you want to check in your modules, you run "go mod vendor" and it creates a vendor/ directory in your working directory to check in. All of these ignore files exist to work around other packages; it's not git or docker or dropbox's fault that some tool you use contaminates your working directory. Plenty of designs exist for those types of tools that don't.
Personally I prefer that build artifacts end up somewhere under my current working directory. That means if I want to clear everything out related to a project, it's easy to do so without interfering with anything else.
Of course it still would be an option if these were stored out of tree, but it means I need to know where that is. I also have the potential to affect other unrelated projects.
I suppose this could be addressed by the tooling, if there was an easy way to get it to echo the target, and it made sure to always keep things separate.
Bazel is the king of parallel builds though, at work we can spread out 100 actions wide across across a cluster of machines, and the only reason it's that small is we have no real need to go wider...
Output directories are unique by the user and source project workspace directory. Output artifacts don't clobber, even though they are all in ~/.cache.
I put everything in Dropbox including all of my projects. In my experience it works pretty well even if node_modules can't be ignored now.
Putting every projects in Dropbox with .git is the most awesome feature of Dropbox. With Dropbox's History and Time Machine feature, you will be almost never able to delete/overwrite your work permanently, even by intention.
Why not just use github, gitlab or other VCS? Personally, I enjoy using Dropbox for music projects (which VCS are not well suited for), but for code...
(I apologize if I sound as if I'm telling you what you should be doing; I am really just trying to understand the motivation behind such a decision - but I fully understand that even if something seems bizzare to me, it's just my personal humble uninformed opinion).
I don’t do as the parent does, but I’ve thought about it. The main difference is that a remote repo still requires an action to achieve backup parity. Using Dropbox your changes would start syncing the second you type :w. So even if you don’t finish the current development thought-line and commit upstream, you’re still backed up.
Still not sure if it’s a good idea or not, but not being able to ignore node_modules was the real blocker for me before.
You can only revert changes to states that you have explicitly stored and uploaded. Dropbox does that automatically any time you save a file. That simplicity makes it more reliable. You will never lose anything you saved. And with rewind you can go back to any point in time. The advantage of git comes from its branch/merge features. But for a single developer on a small project that doesn't know git well that's not worht the complexity.
They're completely different tools with different benefits, and both can be used together. VCS remembers only what you commit and push, per-project. Dropbox remembers your entire workspace as a whole, automatically. It remembers every time you save any file (more detail than you usually need, but can be handy in an emergency). It also remembers which projects you have on the go, and how they're organised. It remembers all the unpushed stuff within each project, including uncommitted changes, stashed changes, experimental branches, gitignored notes and ideas, even the knowledge of which branch you are currently on. Your entire workspace. And by 'remembers', I mean it automatically syncs all that stuff to all your devices, so your workspace is always exactly as you left it, whichever device you're now using.
After an office break in and having my laptop stolen my company gave me dropbox to back up my home folder.
Dropbox actually managed to completely hose every single node_modules folder by the end of the week. It got confused somehow then ended up just splitting all the files up with dates on them as if there was a conflict across hundreds of files.
I actually do this with my hobby .NET project and OneDrive. It's really a lot nicer when bouncing between two desktops and a laptop when I only have a half hour or an hour to work on something - everything is just there, and I don't have to futz around and check if I need to git pull, or worry if I get interrupted and don't get a chance to push whatever I'm working on.
Of course, NuGet is far less promiscuous than node, and I'm playing with a desktop app, so there's a lot less ephemeral stuff to have to sync.
Now they just need the also much-requested inverse feature, a reliable way to sync files outside of the Dropbox root folder. Useful for app specific config files that often don’t let you choose where to store them. Using symlinks on Mac sort of works but it’s kind of fragile and it’s a pain to remember to set up on a new machine, and on windows there’s no workaround at all.
It’s kind of crazy that there are still these low hanging fruit advanced syncing use cases, that would help keep Dropbox’s position as a leader in this crowded space, and they are a multi billion dollar company, but they drag their feet on it for so long. I know they want to keep cranking out mediocre me-too productivity tools that nobody is asking for in case they get lucky and one catches on, but they should really be able to do this too.
All linking tricks are often defeated if the program in question writes to the file. Especially on windows, it's common practice to first write out a new file, if you didn't crash, remove the old file and rename the new file. This breaks the link. I'm not sure if this is also common for config files, but I would not be surprised.
This is good to know!
On Linux, Dropbox's CLI implements an 'exclude' command that you can apply to certain files/folders. But it doesn't always work.
I've had issues especially with Docker volumes, that I set to ignore, but dropbox gets stalled in a endless syncing status...
Hope this fixes it!
I think this is a perfectly good technical solution that they haven't built a modern UI for, is all. It's great that under the hood the feature will be easily scriptable using standard OS utilities.
I'm assuming since this is beta they probably guessed enough of the users who want this are technically capable of managing without a UI during testing.
To clarify, Insync is a client used in place of Backup and Sync / Drive File Stream?
Do you have a Linux CLI client? I have a headless Ubuntu server at home that I sync personal files on. Currently using Dropbox but in the process of switching to Google Drive (both a personal and business account) and it seems like there's no good CLI only client for Linux.
Obligatory mention of Syncthing, which had .stignore file for a while [0]. It's open source, and you can selfhost in; but the downside comparing to Dropbox is that you won't be able to access your files if your computers are off.
Recommending Syncthing kind of misses the point for many Dropbox users.
I want cloud storage that's hosted on infrastructure that's not mine, because I don't trust myself to keep it redundant and up to date, a perpetual security risk. Even if I could setup a local LAN storage device at home and keep it always on and available, it's a nuisance and I don't want it.
Even more, when accessing files, I don't necessarily want to download them locally. If I have photos or documents, I want to search them or browse them without downloading entire folders locally. And I browse files on my iPhone quite often too, I need a good iPhone app.
My only problem with Dropbox is one of security, as it misses end to end encryption, but then again, the files wouldn't be as accessible if they did that, plus personally I think encryption should be local and app specific for it to be reliable, therefore I'm encrypting (via GPG mostly) the sensitive files that I need to encrypt.
Interesting. It's the first time for me to see a use of file attributes in Linux. What are the common use cases of file attributes?
Also, I just notice that every files in Dropbox folder has com.dropbox.attributes key with unreadable binary value. Does anyone have an idea about this field?
> What are the common use case of file attributes?
CephFS (a distributed filesystem) uses them to allow users to control the layout of directories and files, ie. how they are split into chunks and what pool they are stored on; and each pool has its own replication settings.
its dropbox id for each file - useful when you move files around, dropbox client can check the ids with the data on server and decide whether to upload the file or not...
always between mac and windows. i have had better experience with dropbox than drive. in fact, i have all three: onedrive, dropbox, and drive. drive is my least favorite...
Genuine answer: because it is not superior, certainly not “far superior” and it’s a Google “I’ll probably kill you tomorrow.” product made by a company whose ethics I no longer trust (Google).
I first thought you meant Google "I'll probably kill your account tomorrow."
I constantly hear about people breaking ToS on one of many Google services and having them all instantly disabled, no warning (usually losing mail email account).
I never had any sync issues with it and it is still the only one which supports both Delta sync and LAN sync and their automatic "Smart Sync" still works better than what Google offers without the need to awkwardly mount it as external/network storage.
The Backup and Sync client from Google is unreliable and imo just broken: It moves old versions of edited files into the local recycle bin and once it never recognized a file deletion I made on an other computer. Only some days later after manually restarting the client, it noticed that file deletion.
Google Drive File Stream has severe performance issues: I have an unlimited G Suite account and use it mainly for Arq Backup. While ~5 TiB data is not THAT much, Arq does create thousands of small files in its destination folder. For the initial sync the GDFS client took over a week while using more than 60 GiB RAM! Afterwards its memory usage settles down but this was just for enumerating the remote files without any anything marked as 'available offline'. On my MacBook Air with less RAM this initial sync never finishes without GDFS crashing first.
While I still use the official Dropbox client, I replaced all other sync clients with Mountain Duck. It doesn't show any deal-breaker bugs and its resource usage is also manageable.
Because, to this day, Dropbox is the only cloud storage service that is capable of syncing only the part of a file that was modified. If you have ISOs, zips etc, GDrive will re-upload the entire file while Dropbox will only upload the changed parts.
It is usually git-ignored, which means it isn't part of the "real" source directory (the one that is shared with other devs). It's a temporary output of the build process, in essence.
Because NPM's first operation is to pull in half the internet as modules so you can write 'Hello World' on your webpage. Thats too many files for the Dropbox client to handle.
The primary purpose of my project folder is to contain my project, including source, dependencies, build output, etc - so it makes sense to me that tools like Git allow you to exclude/ignore parts of it.
But the primary purpose of the Dropbox folder is to sync stuff to Dropbox. The idea that I would put something in my Dropbox folder that I didn't want to sync is bizarre.
It sounds like it's a common case where people put their project folders inside their Dropbox folder. Before today it never occurred to me that anybody would do that.
I do have some projects I periodically Git Bundle into a Dropbox folder though.
Not criticizing anybody's workflow, just surprised it's so common.
I don't use Dropbox, but in OneDrive this is a per-computer setting, so I may have some large files that I want to sync on my desktop, but not on my laptop where I only have a 256gb SSD.
Is there any reason to use dropbox over onedrive? This feature has been in onedrive I believe since Windows 10 release? (Also onedrive has linux clients too so- I use it on Linux itself and the linux client by abraunegg supports this)
But there is a huge gap between official linux support by Dropbox and a thrid-party app.
In my experience, Dropbox's syncing experience is generally superior than the others, especially when it comes to file stability. Its history and time machine feature (or folder rewind) is so great.
I have had lots of sync problems with one drive (files excluded because of characters in their names, frequent, heavy resyncs).
Perhaps you don't see these problems if you use Windows. I wanted to use it as the marginal cost was 0 (already had to have a Word license) but I couldn't rely on it.
I don't like Dropbox spraying shrapnel through my mac's UI even though I told it not to, so don't take this as a defense of DB -- it simply sucks less and does the baseline (save my files) better.
Which is also my justification for using a Mac (sucks the least of the options available to me).
First of all, this was about 2-3 years ago.. not sure if things have changed.
(1) Onedrive "for business" was completely different than OneDrive personal. It still worked under some archaic office sharepoint or whatever thing to some degree.. so first when I tried to use it there was some terrible path/file limitation (lower than normal windows) and it didn't like some special symbols.
So let's ignore that nightmare above, maybe it's changed.
(2) Even with onedrive personal and the business version I used.. it COULD NOT manage a lot of files. I mean even 50k-100k files it would just stop working basically. It would just sit there stuck, never do anything etc.
On Dropbox we have well over a million files and it works fine. Some chunk of files change all the time and it still works.
tl;dr if you have a LOT of files.. Dropbox is the way to go- nothing else I have tried comes even close to it.
LOL I think Nextcloud has this feature for years already? Such a superior experience compared to Dropbox! I will never look back! Especially now with the next big update: Nextcloud Hub: https://nextcloud.com/
Will an ignored file be ignored for all devices or just my device?
That is, what if I have a file/directory in my dropbox on one device and then another device "ignores" it? would it be ignored everywhere or just in my device?
Either way seems like a recipe for a lot of problems. No wonder it took so long to get to it (and it's still in Beta).
> Once ignored, the file or folder remains where it is in your Dropbox folder and is synced to your computer’s hard drive, but it’s deleted from the Dropbox server and your other devices, can’t be accessed on dropbox.com, and won’t sync to your Dropbox account.
This is kind of the opposite. With Selective Sync, the file exists on Dropbox.com and 0 or more client devices, and each device can choose whether or not to sync the file. The new ignore feature allows a file to exist on one device without being uploaded or synced to other devices.
I work on a major dropbox competitor. We have the ability to do regex-based ignores, but it's deliberately hidden. (And not part of any regression suite.) As we've optimized the product, regexes would cause a huge performance problem.
Why? Part of our optimization includes representing paths in an optimized data structure. In order to process the regex, each path would need to be converted back to its full string, which is computationally "expensive" when working with 20,000 or more files and folders.
I worked on a sync product that had this feature "forever." The problem with the "ignore" feature is that it creates corner cases in almost every use case we add. A huge amount of engineering resources goes into this feature, even though its only used by a minority of users.
A big problem comes with un-ignoring a file / folder, specifically if someone else has gone and added the same file / folder on another computer or in the web. The only way to make that use case work smoothly is to basically read minds, because there's no way to know which version of the file / folder is the right one.
Sync conflicts are never fun, but from personal experience programs that attempt to auto-resolve them aren’t exactly letting the user in on what’s going on.
The best way to make that work in that case would be to explicitly inform the user when unignoring of the conflict and ask which to keep (showing metadata etc). A quick “retain other version” would help if the user was unsure.
All I can say is: That's easier said than done. Dropbox's implementation has no UI, building such a wizard is probably much more complicated than they anticipated!
I've always advocated for wizards like that, but everyone gets enamored with building the next shiny feature.
Some days I wonder if I should just quit and make an open source sync product... And if I'd actually make a living doing it!
Kinda feels like a dark pattern in order to get Dropbox to be your "filesystem".
Can't lie, I've been a dropbox user since nearly the very beginning, and a paid user for longer than I can remember, and it does kinda fill this purpose for me. Application and platform specific things live outside of my Dropbox directory, but everything personal, work, and school related document wise lives in it, as well as a mostly unsynced folder that holds the backlog archive of my entire digital life, to the tune of ~400gb.
It would be cool to make a file that would be globally ignored with all syncing services so it couldn't be uploaded. Though I do not think this is possible.
Fantastic!!! Will definitely go back to Dropbox when this feature is available.
Recently I switched to OneDrive, also no ignore that I can find, but I'm only making extra copies of stuff in there that I want backed up to the cloud.
Does Dropbox know to not sync those files on a new computer, or do you have to set those settings everywhere?
If not, if this works like Selective Sync (which is a local setting), then you can end up accidentally syncing those files from new computers. And is thus not equivalent with a .gitignore.
Also does it support glob patterns?
Why couldn't they do a .gitignore that syncs along with your other Dropbox files and be done with it?
While the instructions go to a level of detail with the assumption that the person typing these commands may not be familiar with them, I don’t get why there are no instructions on this page to revert ignoring a file or folder so that it starts syncing to Dropbox again.
It's unfortunate that as startups get larger, the speed of improvement on their product often gets slower.
It's strange to me that Dropbox has thousands of employees, people have wanted this for a _long_ time, and yet this hasn't been built.
You'd think that with more engineering/PM/design talent the product would get better, and faster.
Anyone have any insight into why happens? I've never worked at a early stage startup but here are some hypotheses:
- Maybe this is a good thing. After a product is "done", adding more functionality makes it worse, not better.
- Maybe the company leadership's focus shifts from building a great product to scaling as fast as possible. And doing both at once isn't possible.
- Maybe the engineering division grows substantially, but the number of people actually working on the product doesn't change much. Instead the new engineers work on important, but auxiliary things, like dev tooling, security, infra, ops, etc
- Maybe developing features takes longer because there's more process: security/legal/ops needs to review it, several layers of management need to approve it, it needs to work in multiple countries, etc
- Maybe the urgency to keep improving your product disappears after you feel that you've made it
- Maybe it's more important to take longer to build stable, complete features instead of shipping as fast as possible
I read this somewhere on HN: if your company has $1 million in ARR with 3 people, you'll likely feel need to hire more people, even if the 3 people get the job done.
Now repeat this with $1 billion in ARR...you get the picture.
I've seen "Bullshit Jobs" recommended here on HN [1].
The larger a product gets, the risk and customer impact of regressions increases, so even "simple" changes require significant engineering and QA effort. There are also so many feature requests that prioritizing them is a full time job.
That, and, as people move on - their code remains... so part of adding new features means sifting through the codebase to learn what everything does and be very careful not to add new bugs.
I'd say customer impact, even without regressions. As an example of something that I'm currently working on:
- there is a need to add a single link to a page
- some percentage of the customers will not like this change (perhaps 5%), because it links to a non-whitelabeled area of the product
- as a result, a list of customers that will be upset has to be assembled, and then each one reached out to, which a different department, that doesn't really care if the link is there or not, has to do
I'd say that doing the above will take a month or so. All for a link.
I know "we" in the dev community are always eager for improvement, better tooling and often specific features. Many non-dev folks will also sometimes express the need for certain functionality.
But there's one factor that plays a big role in this i think: most people don't like it when somebody changes "their stuff", regardless of possible benefits.
So once a product is well established, tweaking and changing it puts you at quite a risk of annoying or losing some of your aquired userbase, and further development therefore ensues much more prudently and slowly.
One thing I’ve seen: feature priority driven by what is expected to drive sales. This is a feature that I could see, justified or not, as not driving adoption.
142 comments
[ 2.8 ms ] story [ 241 ms ] threadThe community requested a .dropboxignore file but they chose another solution which I’m sure is reasonable for making the feature more user friendly to non-devs.
This will be immensely helpful for node_modules or build target directories.
https://www.reddit.com/r/sysadmin/comments/eaphr8/a_dropbox_...
I don't do it personally, but I know people who do and it's not entirely illogical.
[1] https://news.ycombinator.com/item?id=9224
still, i'll definitely be making use of this!
Goddamn, stop the world I want to get off
On linux you can create an user group named "cloud", and allow dropbox to only sync files that belong to that group.
What i envisionned was more like a "control center" app of all the outgoing (and incoming) pipes from your FS to syncing systems, with both last syncing time, configuration, etc. A little bit like what's already happening for mail and calendar integration into iOS applications, only for files and on the desktop.
Yes, right now Dropbox would probably crash, but that's their problem. I really don't think it's something that should be handled by the OS when they already have a solution for it.
robots.txt didn't need to know about who the robot was or what the hosting server was.
¹ https://en.wikipedia.org/wiki/Archive_bit
² https://www.samba.org/samba/docs/using_samba/figs/sam2_0801....
https://xkcd.com/927/
If you look at something like Bazel, all the build artifacts end up in ~/.cache (or similar). Thus there are no artifacts to gitignore. OCI container builds ("docker images") are done by simply adding artifacts controlled by a build rule into the image (rather than starting a vm/container, copying a working directory into the container, and running random shell commands).
To summarize, I think the problem is that node puts packages in your working directory instead of some other location, causing you to have to ignore them. It is reasonable to check in your dependencies, in which case node's strategy is fine. But you can compare this to something like go, which puts all modules in $GOPATH/pkg/mod and if you want to check in your modules, you run "go mod vendor" and it creates a vendor/ directory in your working directory to check in. All of these ignore files exist to work around other packages; it's not git or docker or dropbox's fault that some tool you use contaminates your working directory. Plenty of designs exist for those types of tools that don't.
That is a terrible design, as it makes parallel builds error prone.
1. It might be NFS mounted.
2. Space might be an issue and more difficult to plan for if build outputs are going there.
Why would anyone put a node project in Dropbox to begin with?
Putting every projects in Dropbox with .git is the most awesome feature of Dropbox. With Dropbox's History and Time Machine feature, you will be almost never able to delete/overwrite your work permanently, even by intention.
(I apologize if I sound as if I'm telling you what you should be doing; I am really just trying to understand the motivation behind such a decision - but I fully understand that even if something seems bizzare to me, it's just my personal humble uninformed opinion).
Still not sure if it’s a good idea or not, but not being able to ignore node_modules was the real blocker for me before.
You can only revert changes to states that you have explicitly stored and uploaded. Dropbox does that automatically any time you save a file. That simplicity makes it more reliable. You will never lose anything you saved. And with rewind you can go back to any point in time. The advantage of git comes from its branch/merge features. But for a single developer on a small project that doesn't know git well that's not worht the complexity.
Two things that keep everything in sync:
1. Every two minutes my notesync.sh script runs, which basically does git add --all;git commit -am "New commit";git pull;git push.
2. Vim with AutoSave.vim which saves the document as I write.
Yes, there are a lot of commits, but I don't have to worry about losing anything.
Dropbox actually managed to completely hose every single node_modules folder by the end of the week. It got confused somehow then ended up just splitting all the files up with dates on them as if there was a conflict across hundreds of files.
Stopped using it after that.
Of course, NuGet is far less promiscuous than node, and I'm playing with a desktop app, so there's a lot less ephemeral stuff to have to sync.
But this begs the question: why would the "ignore file/folder" feature itself be useful to non-devs?
Seems like a win on their side.
It’s kind of crazy that there are still these low hanging fruit advanced syncing use cases, that would help keep Dropbox’s position as a leader in this crowded space, and they are a multi billion dollar company, but they drag their feet on it for so long. I know they want to keep cranking out mediocre me-too productivity tools that nobody is asking for in case they get lucky and one catches on, but they should really be able to do this too.
https://www.tenforums.com/tutorials/131182-create-soft-hard-...
Or switch to resilio sync, it’s great and selfhosted. Unlimited folders can be used.
note: i'm a co-founder
Do you have a Linux CLI client? I have a headless Ubuntu server at home that I sync personal files on. Currently using Dropbox but in the process of switching to Google Drive (both a personal and business account) and it seems like there's no good CLI only client for Linux.
we are asking for feedback here -- https://forums.insynchq.com/t/feedback-wanted-insync-3-headl...
[0] https://docs.syncthing.net/users/ignoring.html
I want cloud storage that's hosted on infrastructure that's not mine, because I don't trust myself to keep it redundant and up to date, a perpetual security risk. Even if I could setup a local LAN storage device at home and keep it always on and available, it's a nuisance and I don't want it.
Even more, when accessing files, I don't necessarily want to download them locally. If I have photos or documents, I want to search them or browse them without downloading entire folders locally. And I browse files on my iPhone quite often too, I need a good iPhone app.
My only problem with Dropbox is one of security, as it misses end to end encryption, but then again, the files wouldn't be as accessible if they did that, plus personally I think encryption should be local and app specific for it to be reliable, therefore I'm encrypting (via GPG mostly) the sensitive files that I need to encrypt.
Also, I just notice that every files in Dropbox folder has com.dropbox.attributes key with unreadable binary value. Does anyone have an idea about this field?
CephFS (a distributed filesystem) uses them to allow users to control the layout of directories and files, ie. how they are split into chunks and what pool they are stored on; and each pool has its own replication settings.
https://docs.ceph.com/docs/mimic/cephfs/file-layouts/
(1)https://www.alfredapp.com/
I constantly hear about people breaking ToS on one of many Google services and having them all instantly disabled, no warning (usually losing mail email account).
I also prefer buying services from companies whose only purpose is solving the problem I'm having.
The bigger a company gets, I feel like, the more their "we do everything" becomes untrustworthy.
I'd bet it is more unlikely that Dropbox will pivot from their main file sync product than Drive's breaking a functionality I depend on.
I never had any sync issues with it and it is still the only one which supports both Delta sync and LAN sync and their automatic "Smart Sync" still works better than what Google offers without the need to awkwardly mount it as external/network storage.
The Backup and Sync client from Google is unreliable and imo just broken: It moves old versions of edited files into the local recycle bin and once it never recognized a file deletion I made on an other computer. Only some days later after manually restarting the client, it noticed that file deletion.
Google Drive File Stream has severe performance issues: I have an unlimited G Suite account and use it mainly for Arq Backup. While ~5 TiB data is not THAT much, Arq does create thousands of small files in its destination folder. For the initial sync the GDFS client took over a week while using more than 60 GiB RAM! Afterwards its memory usage settles down but this was just for enumerating the remote files without any anything marked as 'available offline'. On my MacBook Air with less RAM this initial sync never finishes without GDFS crashing first.
While I still use the official Dropbox client, I replaced all other sync clients with Mountain Duck. It doesn't show any deal-breaker bugs and its resource usage is also manageable.
I've used both and it feels like Dropbox is more polished and user friendly in every way...
This alone is why I keep using Dropbox.
HOWEVER, there is Insync, which is cheap, works on all OS I care about and supports pattern-based sync exclusions, anyone here has experience with it?
I put things that I want to sync with Dropbox in /Dropbox and take out things that I don't want to sync.
Why would I want to leave things in /Dropbox that I don't want on Dropbox?
Every nodejs project is structured this way... node_modules is always sitting next to your src...
But the primary purpose of the Dropbox folder is to sync stuff to Dropbox. The idea that I would put something in my Dropbox folder that I didn't want to sync is bizarre.
It sounds like it's a common case where people put their project folders inside their Dropbox folder. Before today it never occurred to me that anybody would do that.
I do have some projects I periodically Git Bundle into a Dropbox folder though.
Not criticizing anybody's workflow, just surprised it's so common.
Hey! This person has a way: https://superuser.com/questions/469776/how-to-exclude-files-...
But there is a huge gap between official linux support by Dropbox and a thrid-party app.
In my experience, Dropbox's syncing experience is generally superior than the others, especially when it comes to file stability. Its history and time machine feature (or folder rewind) is so great.
Perhaps you don't see these problems if you use Windows. I wanted to use it as the marginal cost was 0 (already had to have a Word license) but I couldn't rely on it.
I don't like Dropbox spraying shrapnel through my mac's UI even though I told it not to, so don't take this as a defense of DB -- it simply sucks less and does the baseline (save my files) better.
Which is also my justification for using a Mac (sucks the least of the options available to me).
First of all, this was about 2-3 years ago.. not sure if things have changed.
(1) Onedrive "for business" was completely different than OneDrive personal. It still worked under some archaic office sharepoint or whatever thing to some degree.. so first when I tried to use it there was some terrible path/file limitation (lower than normal windows) and it didn't like some special symbols.
So let's ignore that nightmare above, maybe it's changed.
(2) Even with onedrive personal and the business version I used.. it COULD NOT manage a lot of files. I mean even 50k-100k files it would just stop working basically. It would just sit there stuck, never do anything etc.
On Dropbox we have well over a million files and it works fine. Some chunk of files change all the time and it still works.
tl;dr if you have a LOT of files.. Dropbox is the way to go- nothing else I have tried comes even close to it.
That is, what if I have a file/directory in my dropbox on one device and then another device "ignores" it? would it be ignored everywhere or just in my device?
Either way seems like a recipe for a lot of problems. No wonder it took so long to get to it (and it's still in Beta).
> Once ignored, the file or folder remains where it is in your Dropbox folder and is synced to your computer’s hard drive, but it’s deleted from the Dropbox server and your other devices, can’t be accessed on dropbox.com, and won’t sync to your Dropbox account.
Is there something this lets one do that couldn’t be done before? Or is it just adding convenience?
Why? Part of our optimization includes representing paths in an optimized data structure. In order to process the regex, each path would need to be converted back to its full string, which is computationally "expensive" when working with 20,000 or more files and folders.
A big problem comes with un-ignoring a file / folder, specifically if someone else has gone and added the same file / folder on another computer or in the web. The only way to make that use case work smoothly is to basically read minds, because there's no way to know which version of the file / folder is the right one.
The best way to make that work in that case would be to explicitly inform the user when unignoring of the conflict and ask which to keep (showing metadata etc). A quick “retain other version” would help if the user was unsure.
I've always advocated for wizards like that, but everyone gets enamored with building the next shiny feature.
Some days I wonder if I should just quit and make an open source sync product... And if I'd actually make a living doing it!
Can't lie, I've been a dropbox user since nearly the very beginning, and a paid user for longer than I can remember, and it does kinda fill this purpose for me. Application and platform specific things live outside of my Dropbox directory, but everything personal, work, and school related document wise lives in it, as well as a mostly unsynced folder that holds the backlog archive of my entire digital life, to the tune of ~400gb.
Recently I switched to OneDrive, also no ignore that I can find, but I'm only making extra copies of stuff in there that I want backed up to the cloud.
Does Dropbox know to not sync those files on a new computer, or do you have to set those settings everywhere?
If not, if this works like Selective Sync (which is a local setting), then you can end up accidentally syncing those files from new computers. And is thus not equivalent with a .gitignore.
Also does it support glob patterns?
Why couldn't they do a .gitignore that syncs along with your other Dropbox files and be done with it?
It's strange to me that Dropbox has thousands of employees, people have wanted this for a _long_ time, and yet this hasn't been built.
You'd think that with more engineering/PM/design talent the product would get better, and faster.
Anyone have any insight into why happens? I've never worked at a early stage startup but here are some hypotheses:
- Maybe this is a good thing. After a product is "done", adding more functionality makes it worse, not better.
- Maybe the company leadership's focus shifts from building a great product to scaling as fast as possible. And doing both at once isn't possible.
- Maybe the engineering division grows substantially, but the number of people actually working on the product doesn't change much. Instead the new engineers work on important, but auxiliary things, like dev tooling, security, infra, ops, etc
- Maybe developing features takes longer because there's more process: security/legal/ops needs to review it, several layers of management need to approve it, it needs to work in multiple countries, etc
- Maybe the urgency to keep improving your product disappears after you feel that you've made it
- Maybe it's more important to take longer to build stable, complete features instead of shipping as fast as possible
Now repeat this with $1 billion in ARR...you get the picture.
I've seen "Bullshit Jobs" recommended here on HN [1].
[1] https://en.wikipedia.org/wiki/Bullshit_Jobs
- there is a need to add a single link to a page
- some percentage of the customers will not like this change (perhaps 5%), because it links to a non-whitelabeled area of the product
- as a result, a list of customers that will be upset has to be assembled, and then each one reached out to, which a different department, that doesn't really care if the link is there or not, has to do
I'd say that doing the above will take a month or so. All for a link.
But there's one factor that plays a big role in this i think: most people don't like it when somebody changes "their stuff", regardless of possible benefits.
So once a product is well established, tweaking and changing it puts you at quite a risk of annoying or losing some of your aquired userbase, and further development therefore ensues much more prudently and slowly.
Dropbox//node_modules/
or similar?
"Hey Dropbox, why can't I compare file versions like this?" http://web.eecs.utk.edu/~azh/blog/whycanticomparefileversion...