71–80 of 143 posts
The dropbox cli already lets you ignore folders. I've have had the following script for many years to ignore node_modules: exclude_folders=$(find . -type d -name "node_modules" | grep -v "node_modules/") echo "Excluding $exclude_folders" dropbox exclude add $exclude_folders dropbox exclude list The feature I want is pattern-based ignore in a .dropboxignore file.
This is also true of the GUI. It's called Selective Sync
Earlier quoted context omitted.
This is also true of the GUI. It's called Selective Sync
I’m finding it hard to understand how this new feature differs from Selective Sync. Is there something this lets one do that couldn’t be done before? Or is it just adding convenience?
Earlier quoted context omitted.
This is also true of the GUI. It's called Selective Sync
I’m finding it hard to understand how this new feature differs from Selective Sync. Is there something this lets one do that couldn’t be done before? Or is it just adding convenience?
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…
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.
Earlier quoted context omitted.
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.
Yeah I'm just confused why there is no UI integration. It's not like Dropbox is too light on the UI otherwise.
Earlier quoted context omitted.
I can imagine a world where a arbitrary directory is filled with gitignore, dropboxignore, googledriveignore, backblazeignore, s3ignore, rsynciginore, dotignore, ipfsignore . . . Goddamn, stop the world I want to get off
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…
Earlier quoted context omitted.
That's probably a clue something needs to be done at the OS level regarding FS integration with cloud syncing systems and permissions.
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" ² ¹ https://en.wikipedia.org/wiki/Archive_bit ² https://www.samba.org/samba/docs/using_samba/figs/sam2_0801....
Earlier quoted context omitted.
That's probably a clue something needs to be done at the OS level regarding FS integration with cloud syncing systems and permissions.
All major OS already have a permission' system. It's on dropbox & co to honor them. On linux you can create an user group named "cloud", and allow dropbox to only sync files that belong to that group.
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.
Who needs a VCS when you could just use Dropbox?