I’m using Lightroom as my main work tool. Sadly the way it’s working is apparently messing with Odrive quiet a bit.
For exemple everytime there is a change in the catalog, Odrive reupload the WHOLE catalog (942Mo in my case).
Is there a way to stop the syncing of this specific file and keep it local to prevent this while waiting for a new type of synchronization?
Other issue, I ALWAYS have around 83 .lrprev files in the trash, no matter how often I click “empty trash” or recover and try to delete it again.
Can I have some help about these two issues?
I have a couple of solutions for you.
- You can use our global “stop sync” (sometimes it says “pause sync” when there’s no activity) which is available in the odrive tray menu. You’ll notice that edits you make will not sync up. Edited files won’t have a green badge and you’ll see them get parked into the “Waiting” status on the tray menu. Once you’re done with all of your edits, go back to the tray menu and select “start sync” again when you’re ready for odrive to start syncing changes again.
- I’ll look into getting engineering to exclude .lrprev files from sync. Since they are cached preview files, there’s no need for us to try to sync them up. That will reduce churn/bandwidth usage and it will also mean that they won’t go into Trash when they get deleted.
You can already use #1 today. For the second point, if we determine it’s the right solution get a new release out which has .lrprev files excluded/blacklisted, I’ll reply here and let you know so you can give it a shot.
Thanks for your feedback,
Allright thank you so much for the fast answer!
I’ll try this first solution right now, or is it possible to stop the sync on a specific file? (in my case the catalog). Because I don’t especially need this catalog to be saved.
This could also fix the .lprev issue, I can just select the temporary folder and stop the sync.
What do you think?
You can currently right-click on a file that is syncing in order to stop sync on it, but it will just attempt to sync up again shortly thereafter, so for what you’re trying to do I would just use the global switch. It’s quicker/easier and will be less hassle.
Unfortunately, there’s no way to set an individual file/folder to be stopped and ignored until you want to turn it back on… It may be something we can offer in the future… Not currently on the roadmap, but as we get more feedback/demand for it, that will help raise the priority for it.
The capability to specify exclusion masks would be useful. Various programs create any number of temporary or installation-specific files. Being able to add (or subtract?) from the default blacklist would allow your customers to tailor odrive to their own environment.
John: Thanks for the head’s up about Lightroom! We haven’t yet put odrive to work on LR catalogs. Looks like we should hold off.
That would be great indeed.
I’m a photographer as you can guess and I use my cloud as a tool in my workflow. I have client’s folder that I share with them.
One of the other issue is, it’s impossible for them to download a full gallery at once. So I generate links with Amazon Cloud Drive instead of Odrive, which is unfortunate
For sharing with clients, you should check out odrive Spaces. You can invite your clients to a Space (the gallery), and they can look at it directly on their system as a link within odrive. Pretty cool stuff:
By the way, we just pushed out a new desktop sync build. It includes the exclusion of .lrprev files from sync as part of the release. Let us know if that helps!
Tried the new version with a small LR catalog and it did not push temp files to the cloud. Great!
On the not-so-great front, we use different software packages that all have their own ideas about temp file names. Some are ill-behaved in the same manner as Lightroom, placing temp files in the same folder as the open document. An example is PhaseOne Capture One.
Rather than playing whack-a-mole with all the possibilities, can odrive please give the ability to add per-user file exclusion masks? Better still would be the option to specify exclusions on a per-share basis as well as globally.
We have discussed customizable blacklisting and whitelisting before (maximum control but complicated) as well as simple file extension-based exclusions. I think it’s something that we may do in the future, likely as a paid feature or part of a package, but there are all sorts of considerations… some of which you’ve touched on already with regards to individuals needing to set it up themselves vs. share-based vs. group/organization-based (once that exists). Coming out with the right form factor is important. Thanks for your thoughts on the matter–I’ll create a post under Feature Requests for this, too, so other people can engage.
Something like git’s .ignore file would work perfectly in this case (it is basically just a blacklist)
So I think you would also need a whitelist
if whitelist is empty or absent - all files included
if a file/file pattern is on the blacklist it is excluded
in case of conflicts - blacklist wins
rules apply recursively to subdirectories
each sub directory can (but doesn’t have to) have its own white list or blacklist
Conflicts between parent and child rules?
…child wins - just make sure the UI makes this clear
Doesn’t seem too complicated to code that.
Novice users could avoid it if they didn’t understand it. Power users would have an escape route.
One of my big recurring complaints about most of the various sync tools on the market is the lack of control they give you over managing and cleaning your files. I think you all could win big here. Hope this helps.
@Brett: Exactly! The white/blacklist structure used by git (inherited from Apache’s .htaccess syntax) is certainly a potential option. I’d prefer to take this one step further and use something like Apache’s global configuration file. Using a structure such as the
<Directory> directive would allow customizations that could be easily propagated to additional machines and users.
The thing to absolutely avoid is adding more options to the right click context menu. A configuration file that could be left alone by the majority of users would solve such matters.
I am trying use Capture One and DaVinci Resolve with odrive and have been running into problems. A gitignore style exclusions would be great.
I love how GitHub has .gitignore templates that you select when creating a repository. It would be amazing to set settings for a folder and select a .gitignore template for certain apps (Lightroom, Capture One, etc etc)
For now I had an idea to wrap launching Capture One or DaVinci with a script that will stop/pause odrive. But stopping or pausing the odrive seems unavailable in the CLI interface Or even running a process that watches looks for a capture one process and pauses odrive, then when I close capture one — it’ll start it again.
Any help would be appreciated!
There is a thread here that discusses this feature request:
Additionally, there was a thread a couple weeks back about scheduling odrive sync. Its not exactly what you are talking about, but I think it is close enough to be useful to you (It is Windows-centric, so if you are on Mac you would need to use different methods):
In short, you can at least use the CLI to issue the “shutdown” command and then open odrive again when you can have it start syncing. Not as efficient as a pause, but may work for you.