I am using Rhino 5 for mac and autosave keeps interrupting my workflow every 5 minutes. I want to disable this so i can save manually
good question. recently its very bothersome i must concur, every time while working on a model mostly during swiveling a model, it hooks up and my mouse creates a firework of exposé actions because it suddenly loses connection to the viewport.
usually OS X itself is responsible for this, but somehow i get the feeling that something has changed in the last wip making this autosave more obvious again as it has been quite a while ago already but got better in between.
if you want to use a terminal hack:
defaults write -app '###' ApplePersistence -bool no may “fix” this, meaning it probably will stop creating versions. i havent tried it yet but it seems to work on other applications. oh and replace the ### with your app name they are just placeholders.
to turn it off in general for every app you might use:
defaults write -g ApplePersistence -bool no
@dan do you know if something got changed?
Hey Richard, thanks a lot for the reply. Do you know of a similar method by which i can change the autosave time from every 5 mins to maybe every hour? thanks again
this is where i have to start guessing that this part is being controlled by rhino,
but its a wild guess… so lets wait what dan can say to this.
can not be done
well that’s disappointing! someone should fix this ASAP!
“Fixing it” would be up to Apple.
File saving and versions is a OS X / macOS thing.
I think a similar thing will happen in Windows fairly soon.
It’s not a “problem,” but a feature of the Apple OS system. You may not like the user (including me) but the autosave can NOT be disabled by the user or program developers.
no John i guess thats not just apple doing that. i didnt change my system in a long time, but with the latest wip autosave got very penetrating again.
as an extra evidence that apple my not be at fault for this issue here, you can read this which explains how frequent one wants to have office autosave documents which is being set in office itself.
Interesting. That’s not what I was led to believe by our developers. I’ll check with them again to see what we can do. I keep pushing for making Windows Rhino style BAK files but that doesn’t seems to be a reasonable thing to do with the OS X file system.
that probably works like that since Microsoft isn’t using macOS autosave and instead are using their own custom autosave implementation.
fwiw, i’m not personally experiencing any noticeable effects using the latest Rhino(s) for Mac.
also, if you’re doing something in Rhino, it’s supposed to wait until you’re doing nothing until the save happens… ie- it saves every 5 minutes unless the user is busy doing something in the application.
but you guys are saying you’re doing something then autosave noticeably activates?
you can do that… some Mac apps do work that way. (and i think Grasshopper on Mac isn’t using macOS autosave… instead, a custom version… probably the same one in Windows’ grasshopper)
in my opinion, it’s outdated and creates clutter via many unnecessary files…
in Rhino for Mac, the autosave file itself (the one for recovering in event of crash or power loss) isn’t seen nor needing management…
and the working file can remain a single file instead of (model01.3dm, model02.3dm, model03.3dm, etc)…
ie- you can have one rhino file for a project which also allow access to all previous states of the file.
for me personally, it would be hard going back to the old methods of manually saving 30 different files for a given project… especially when considering the reality of going back to any of those files is slim and when you actually do need to go back, it’s a huge pain to figure out which one exactly is the right one.
idk, i guess what i’m saying is that if there’s a problem with Rhino & autosaving in the latest WIPs then fix it and get it working as apple is meaning it to… instead of just rewriting autosave from scratch with last decade’s methodology
i dont think so Jeff, the link i provided addresses right in the beginning the system function explicitly: AutoSave, a feature that is available in Mac OS … so windows users may experience another kind of autosave.
anyway there where many discussions about the negative aspect of it, while as i said the interruptions got better, i believe it had also something to do with having to save the file first right in the beginning for autosave to work smoothly, still the cluttering may be an issue. i dont know if this makes it outdated as you say but its currently bothersome again.
hmm… yeah… i was making a blanket statement there when i should of been more clear that i was only speaking specifically of my personal experience / workflow… (which, for further clarity, involves multiple computers/devices with cloud syncing between all of them… therefore, the less files & organizational tasks i’m dealing with, the better)
yes thats understandable, maybe it would make sense to store all versions in one file till its purged, if it would save the file slim and tidy as in windows or as if you export then the place would also not be so much of an issue. i never used versions and personally dont see much use for this function and could definitely live without them.
i would say i use Versions ‘rarely’… but i do use it sometimes.
usually if i see a fork in my modeling direction, i’ll copy the object(s) i might like to revert to in the modeling environment itself… it just makes it faster to go back to a previous ‘version’ this way…
i also often find myself modeling in a new direction, the copying, then undo_ing… then pasting as another way of ‘versioning’ within the working environment…
so yes, i think i could also live without macOS Versions if need be…
that said, this functionality also ties in to (and was introduced alongside of) macOS autosaving… from a workflow point of view, they’re sort of intermingled because:
prior to this type of autosave, i used applications with customized autosaving… namely SketchUp (and you could turn it on/off… set the interval… etc.)… it’s how i imagine Windows Rhino to behave (but could be wrong)
the problem was with this type of autosaving is that the file would begin saving exactly when the time interval came regardless of what the user was doing… and many times, the autosave kicks in when you’re doing something intensive and it screwed things up. (either crash, glitch, or slow everything down)
so, users (or, at least, myself) would turn autosave off and save periodically/manually in event of a crash. (basically what Farouk is suggesting in the top post)… this left you with a folder full of files that could either be seen as Backup files or Versions… this is the workflow i’d like to avoid reverting to if at all possible… the one where you end up with all sorts of files which you’re manually managing in the event of a crash/work loss… and in my own experience, the way Rhino for Mac works has solved the above problems without me doing anything and without me noticing anything.
another problem of manually saving a bunch of different backup files/versions when compared to the way Mac autosave works is — each time the save happens, it saves the entire file… so if you’re working on a 50MB file and you create a backup, the entire 50MB is duplicated plus whatever you’ve added since the last save.
whereas on Mac, only the info since the last save is being saved… so if i have a 50MB file, add a couple of lines, then save a version/autosave… only a few hundred kilobytes are added to the main file… so the saves happen very quickly since you’re not continually duplicating all the data… only the newly added data.
i believe this from the wiki explains it quite well.
it says that one has to constantly proceed changing the model for it not to take place. so just moving the mouse is not enough and it seems also rotating the object does not count. but often do i swivel around on my model to check if i proceeded well in what i wanted and to think how to move further, while scratching my balls or let me better say my head. but whatever i scratch, it disturbs with utmost impertinence that this intim moment of my life should be disturbed by a jerky autosave.
so guys can rhino please tell the system that messing in the viewport is not to be disturbed?
that might be worded a little weird but i think it means…
you have to constantly change the model for 5 minutes straight until an autosave is forced… (i.e.-- at that point, the autosave will actually happen regardless of what the user is doing)
otherwise, within that span, autosave will not save while the model is in use an will wait for you to stop until the save occurs.
(and yes, apparently macOS sees mouse movement during an otherwise inactive application as a pause and will save if you’re simply moving the cursor around the display(s) )
edit – upon re-reading, i think i just said something which was basically the same thing you said.
the only difference is that i believe rotating the model does count as a ‘busy application’
i actually meant swiveling the model in the viewport expression error