I would just like to add another ping to this thread. Odrive is excellent, but this single feature is stopping me from rolling it out to customers. They have extensive temporary files created (over 1GB) and these are being uploaded and causing issues.
I have loved using the odrive service for the last week, my amazon cloud drive is in perfect sync with my local directory. Although I had to uninstall odrive today due to the lack of this feature. I plan to use the service again in the future when the feature is available. Because of video files in my local directory that are not in my amazon drive, it continuously attempts to upload the videos into amazon. This has created over 100 GB of traffic per day, causing me to go over the limit put on me by my ISP. We need to have the ability to blacklist file extensions, or the service is useless. Please move this feature up the priority list. Thanks for your consideration.
We’ll definitely keep you updated in this thread once we are able to implement the exclusion list. There’s currently a logjam of stuff (a fair deal of which is prerequisite to offering the feature, too) that we’re trying to get out, so it’s taking us a little bit longer than expected.
Please note that if you actually do want to have the videos go up but are just having problems completing the uploads due to network faults, etc. then you can try our Infinte File Size (IFS) feature. Our usage guide has more information about it. The gist is that you can set a threshold so that files larger than a certain size get split up behind the scenes. So we’ll upload them more reliably as smaller partial files. When using the odrive desktop client, the files get reassembled properly seamlessly. You wouldn’t be able to consume the files outside of odrive since they are split up, but if you are mainly interested in archiving them, that may be good enough. There’s nothing proprietary about the file splitting so you can easily reconstruct them outside of odrive if you had to. Scripts to do that and full transparency of how it works can be found in this medium article.
Waiting for the exclusion list is the best thing to do if you simply don’t care about keeping those particular video files in the cloud, of course. =)
We developers definitely need a custom exclusion list as well as a whitelist.
My current need is to ignore ‘node_modules’ folders for certain sources. This is the most requested feature for Dropbox right now. It would be awesome if odrive could be the savior for us poor Dropbox users.
In addition I don’t want to ignore ‘.git’ folders and ‘.gitignore’ files.
I can see the reasoning behind ignoring .git folders, however Git is not synonymous with cloud storage. Git is a distributed version control system that works very well as a local-only version control system. Sometimes I just want to keep a local history of changes made to a folder without storing it on GitHub or collaborating with another Git user. But I still want to sync that history between my laptop and desktop. I can’t currently do that with odrive.
I think @gltjunk is facing the same issue that I do, and it is not about file size.
Amazon cloud offer in Europe (at least in France) is unlimited storage for pictures only - with a limited storage for any other file types.
A very large PSD file (photshop) will backup with no issue (no storage limit), but any small MP4 file will continuously attempt to sync and fail if the storage limit has already been reached.
So the issue is definitely about filtering media types here and not file size
Should the team have any idea of delay for implementing this feature, I would adapt my backup strategy accordingly
I talked about this in the another topic, but as soon as the @greenish. I believe that the use of a file by following the standard .gitignore or .rsync_ignore would be of great value, for being a pretty standard used.
Please add a +1 for a need for custom exclusion lists.
Until they are available, please add .*.swp to the internal ignore list. These are created by the vi/vim editor as temporary swap buffer files. They are then uploaded by odrive but when I’m done editing the file and the swp file is deleted, odrive then puts it into the trash and pops up a notification message. This is very annoying.
I would like to have a .odriveignore file similar to .gitignore, which you can read about the format here.
(1 and 2) The git ignore format is quite flexible. It can exclude files, folders, but then also the ability to negate a previous exclusion. It allows the use of multiple ignore files in different directories for granularity. For example, in the user home dir could be a .odriveignore file to exclude mp4 files with *.mp4. Further down, in a project subdirectory where you need to include .mp4 files, you could create another .odriveignore file in the project directory containing a '!*.mp4' rule.
(3) Using the above method of hierarchy-based ignore files, a company could create a .odriveignore file above the user’s home dir (in /Users/ or even at /) with some default ignore rules.
The user could negate those rules by creating their own .odriveignore file. However, for corporate security reasons to never upload certain files, you could create a custom feature where they could add a line where any remaining rules can’t be overridden.
*.mp4
*.mp3
#permanent
*.exe
(4) The ability to exclude based on metadata would be great! In MacOS, one of the big features is custom tags and automatically created metadata via Spotlight. It would be nice if odrive could exclude/include based on custom Spotlight search/rules or even the output of a script/command. For example, sudo mdfind "com_apple_backup_excludeItem = 'com.apple.backupd'" finds all files that are tagged as excluded from TimeMachine backups (and other 3rd party backup utilities honor these tags too)
Thanks for listening. I really hope this feature happens soon as it is way overdue.
Like “gullitmiranda” and “Smudge” suggested before a system similar to the one GIT is using would be great.
No Need for a complicated GUI to configure this. Concentrate on functionality.
This is an excellent idea. The non-overridable options could perhaps be integrated into the Spaces function. Owners and admins could create exclusion or inclusion masks that could not be altered by local (per-folder) rule sets. This would solve a problem we experienced in a multi-user environment. The master version of certain files (distinguished either by type/extension or name) should be controlled by a single person. Other files are editable by all. The major cloud providers offer tools to make this work, but the details differ for every one. Odrive would provide a consistent environment independent of the underlying infrastructure.
my use case would be to allow git to track my scripts folder in a project directory and odrive to sync all other folders (i.e. the inverse of git). .odriveignore would be nice but if it was generated as the inverse of .gitignore that would be slick.
@JeffL It’s been 11 weeks since your last update. Is this still in the works? There’s no reason for me to switch from Dropbox to ODrive until this feature is included.
I thought pCloud was going to work for me since it has a type of exclusion list, but it ignores hidden files and folders by default with no way to change it.
Please add this feature as it’s the last thing holding me back from using ODrive. At the very least, please give the community an update. Thanks.
@jordanbtucker Hi… thanks for reaching out again. It’s clear you guys really need the feature, and we want to give it to you. I can assure you that this item has our CEO and product team’s attention. One reason why we haven’t delivered it yet is because we need to make some underlying changes to the product to be able to provide this capability in a real (not duct-tape-and-cardboard) way. We do know that a solution can help with some different and high value use cases. Employees at the company want it for ourselves, too…
Anyway, thank you all again for your patience. We’re working as quickly as we can.
The built-in exclusion list is causing my great pain because I end up with a partial sync of files on other hosts.
I second the .odriveignore paradigm… it’s easy for power users to use and hidden for everyone else. You could drop one at the root of the drive with your current exclusion list.
Ideally, though, there shouldn’t be any exclusions at all. People rely on this for backups and if what they’re dropping isn’t exactly what they get back, that’s a big problem.
Depends on the usage scenario. Odrive can be used as a generic interface to cloud storage, not only as a backup solution. An example is near real time file synchronization. In our case, we use odrive for folders where we are actively editing large images. The image editor can produce temporary files well over 100GB in size. I don’t want to waste bandwidth syncing these huge, transient files.
I know there has been some discussion on this. For my recent testing, I think this is the single factor making it difficult to fully adopt odrive.
In my test last night with Lightroom, I wanted to sync the lightroom catalog, but not necessarily the previews or the lrcat-lock and lrcat-journal files. Those are only opened when Lightroom is open so it is constantly deleting and uploading these.
I second emulating a global .gitignore style file to filter out patterns of files or folders. I think this would make this much easier. Not sure that a per folder exclusion file is needed when a global .ignore file could just have the patterns easily listed like *.lrcat-journal or *\foldertoexclude\
Do you guys have ETA on this?
My scenario: As a developer, I would like to sync my “Projects” folder but would like to exclude dependencies - like node_modules for node.js
Just wanted to mention that Mega’s native sync client offers this functionality, and as a web/etc developer I have been using it with great success for the past year. It would be FANTASTIC to see this implemented in odrive using .gitignore-style directory-specific files rather than Mega’s globally-applied config textarea.