save less?

[HelenF]

Hello all
I can see the value of automatic saving (and I see that we have a preference for changing the frequency). But there are times when I just want to look into a project without it automatically saving. Typical case would be when looking back at an old project - I want to read it but not update it; the automatic save changes the 'last modified' date it gets in the finder, messing up my ability to search or scan old scrivener projects by date.
Hope that description makes sense!
The question is - is there a way to make it so projects only save manually? Or so we can override automatic save at will?
Thanks!
Helen
PS The same goes for backup. I've done my best to disable all automatic backups because if you're not careful the last 5 backups are near identical - where what I want is backups that preserve major revisions (in concert with snapshots of course).

[JoRo]

The post linked below explains about Scrivener projects being packages and how the act of opening a package causes recorded systemic changes, even if no direct user input has been made to edit the project..

https://www.literatureandlatte.com/foru ... 84#p255784

If you only want to look inside a project, you can duplicate the project in Finder first and then load the uniquely named duplicate so that you don't interfere with the original project's metadata or backups.

You can configure the autosave features to keep more backups or manual backups only (opting out of running backups on project open and/or project close and/or before syncing), or, alternatively, you can configure specific projects to be excluded from automatic backups completely (relying on manual backups only). See sections B8 and C9 of the manual.

B8 and C9.pdf

(284.6 KiB) Downloaded 90 times

[scshrugged]

And an OS solution––in Finder, add columns for Tags and/or Comments. Then right-click a document > Get Info and add a date in either the Tag field or Comments one.

In addition to the quick visual ID provided, both features are scanned by Spotlight/Finder searches.

[HelenF]

Thanks very much for both replies!
Not my preferred outcome but at least it is good to know the reason.
Can't understand why that explanation didn't come up in the two searches I did before posting! I was sure someone else would have asked the same question but could not find one. So thanks for pointing me at it.
Helen

[AmberV]

I do agree with the above, that both of these concerns are best handled as an aspect of general-purpose file management.

Typical case would be when looking back at an old project - I want to read it but not update it; the automatic save changes the ‘last modified’ date it gets in the finder, messing up my ability to search or scan old scrivener projects by date.

I don’t place much trust in file system modification dates for this and many other reasons. It’s hard to beat a date stamp that is encoded as part of the file name itself. That aside, I can at least share what I do for old projects: once a project is to the point where I am no longer work on it, I file it to an archival folder, where all old files go to rest, and I tend to compress to zip the files I’m no longer working on.

There is an important side-effect in doing so (outside of simply saving space and reducing the indexing overhead of archives to one file per major project), and that is if I want to in the future consult information from these old files, double-clicking on the .zip produces a brand new copy of the folder/project every time, and every time it is identical from the original. I open the project, get what I need out of it, and when I’m done I trash it, leaving the .zip copy for long-term safekeeping.

It is the closest thing to a pure read-only long term archival system that you can achieve on most modern file systems. Almost everything otherwise, such as permissions and file system locks, tend to either not work well across all software, or can be trivially overridden. I’d rather old stuff be very difficult to modify without a process that involves many steps that must be intentionally taken. Actually overwriting and updating the contents of a .zip file fits that description perfectly.

The same goes for backup. I’ve done my best to disable all automatic backups because if you’re not careful the last 5 backups are near identical - where what I want is backups that preserve major revisions (in concert with snapshots of course).

Out of curiosity, if you are taking care to create your own backups manually (and Scrivener provides several convenient ways to do so), then why turn off the automatic backup? At worst, it’s not always useful for the reasons you specified (though as noted you can adjust the settings to avoid problems like that!), but I would be willing to wager that more often than not there is at least no harm in having five near-identical copies.

Oh and here is a hint for archival projects: if a project is well and truly to that point where, even if you don’t use my method as described above, you are done editing it and don’t want backups made of it in the future, then go into Project ▸ Project Settings... under “Backup”, and exclude the project from backups. Now you don’t have to worry about losing the older copies to subsequent review sessions in the future—of course if you date stamp your old projects in the file name, you also conveniently duck that problem entirely.

I use a combination of manual and automatic backups for these and many other reasons. Here’s what I do:

• For major “save points”, which can happen once or twice per day in an actively edited project: File ▸ Back Up ▸ Back Up To.... This file will be date and time stamped and can be optionally zip compressed (again see above for why that is a good idea for projects you don’t want to accidentally edit). These get saved into a separate folder that I use for these kinds of backups (only the most heavily worked upon projects get their own subfolder). I’ll sometimes name the backup according to what is going on as well. Perhaps I’m overhauling keyword organisation, I’ll call the backup “Pre-Keyword_Overhaul” along with the project name and date stamp. I’ll always have a copy of the project in that state, years from now, in case I ever need the old organisational schema.
• Automatic backups: though I set my to save 25.

On top of these, any protections I add myself (such as the background SpiderOak process that encrypts and stores all important data to another geographic location, or even Time Machine) are keeping track of these backups on top of my own organisation of them, and Scriveners automation. I.e. if Scrivener deletes the 5th oldest backup before you wanted it, that may not actually be a problem for you if every few minutes these things get uploaded or saved to a drive.

[devinganger]

It is the closest thing to a pure read-only long term archival system that you can achieve on most modern file systems.

Does Mac OS support the loopback fs seen in Linux and BSD? If so, that might work too -- remount part of your filesystem as an lofs into your working area, mounted read-only.

Probably a lot of overhead, though, and the system you describe is much more amenable to modification for many types of workflow.

[AmberV]

The main problem with true read-only file systems (including less technically difficult approaches like burning a DVD, for those that still use optical drives) is that they are incompatible with some software, Scrivener among them. It doesn’t have a read-only mode, and so will fail to load a project it cannot actively modify.

I think it is a good approach to use archival formats like Zip and tar to strike a balance between the volatility of “always on” modern tech and safe practices that do not entirely eschew that tech, along with accessibility of that technology. One still must be mindful that they can delete the original .zip or overwrite it, yes, and that is why we should all keep true backups rather than relying on one disk or any system within that disk, but it is a good deal safer than loading original material in software directly (which to be fair is usually quite safe; but this is a policy I even uphold for .txt files, let alone complex file formats).