Document locking

I’ve been following the debate here, and would like to add a respectful voice in favour of document locking.

I use a SINGLE project for several volumes of a series. So far I have a novella published, am prepping a short-short story for submission to an anthology, and am working on a full-scale novel with follow-on volumes partly outlined. All different stories, but with the same protagonists and same universe.

If I had a massive scrivening and was doing a global change therein, and had included already published material for some reason (likely inadvertent), I ABSOLUTELY would like a dialog telling me that I had locked 76 files out of 207 and therefore the global change would not happen.

I have taken snapshots, of course, just as you suggest, and could back out. Nonetheless, there is no warning of impending doom, and I might not remember to check by comparing to backup when, say, doing a compile of an omnibus volume.

I understand the fear of tech support nightmare: I was a software QA engineer for many years, and was often called upon to help tech support during release of new or revised software. (I was SO glad it was not my regular job! ) I certainly can respect your decision to avoid it. Nonetheless, in my own workflow, an ability to lock would be wizard.

Whew yeah, I’m a huge fan of that File ▸ Back Up ▸ Back Up To… command prior to running any kind of large-scale search and replace—or really anything that would impact an unknown quantity of items in a difficult to reverse way, like deleting a keyword that is in use. I’m pretty sure I want to do the thing, but I’d rather have a zipped sidecar copy of the project called “The Novel - pre-before I changed Doug to Suzy.scriv.zip”!

Another approach more designed for this example is the practice of forking off a reference .scriv of each finished work when it comes to that point, compile settings and everything intact, so that future revisions can be spun off from the forked project and the copies left in the master WIP project can be considered loose backup references—research material not source material (and it isn’t difficult to keep that up to date at the conclusion of a revision cycle, either).

Or here’s another:

  1. Select all of the items you intend to bulk replace.
  2. Hit ⇧⌘5 and do a bulk snapshot with title.
  3. Use the Edit ▸ Find ▸ Project Replace… command with the selection filter on (or the Scrivenings route if you prefer, but that does come with the risk of hitting un-protected subdocuments).

Now in a year say if you’re positive this never had any awful effects, you can search for the title you gave in step 2 with the Snapshots Manager and nuke the whole backup for that action. There is very little investment in protecting the changed work beforehand, very little cost in keeping the protective measure around and little investment in removing it, once time has proven it was a safe move. I just think the concept of Snapshots is so much more powerful now that we can slice out bulk chunks like that as needed. It’s a tool that probably requires a little reexamination from us veteran users, who aren’t used to the concept of having 400 snapshots being anything other than ultimately very unwieldy down the road.

There are surely other approaches as well—what I’m getting at is that I think Scrivener does have good mechanisms for safeguarding our work that do not involve locking—snapshots only be one of them. So is the massive UI undertaking that would entail coding such a feature (again the whole program is built from the ground up as an always-on editor, we’re talking hundreds of buttons and switches that would have to have manual overrides built in just to do this—and it goes into the data model as well, not just the UI, this is a deep change to how the entire program is designed to work), and the potential confusions and oddities that would evolve from such a change, worth implementation if there are viable approaches that avoid the hazards that a lack of locking might bring—approaches which incidentally will also serve to protect the kinds of data that wouldn’t and shouldn’t be locked as well? I mean to say, a lock would have fixed the described problem of source material for other books in the binder, but it won’t solve the same action being done on too much of the current WIP, while preventive habits on the other hand protect both.

Maybe—don’t get me wrong, personally I would love a hard lock, from the Title on down in fact, no even touching metadata (a stance probably most would disagree with, but that’s another issue)—but this is something that has been requested since… well it wouldn’t surprise me if it were first brought up in the pre-Scrivener Gold days, thirteen years ago—it’s going on a little more than one year now! :wink: I think our energies will be best spent finding good ways to make locking unnecessary, by either avoiding the scenarios that would make it so, or adopting preventive measures before executing potentially destructive functions.

sighs I understand the “this is a deep change to how the entire program is designed to work” thing. And it’s just Keith (may he live a thousand years!) to do it on Mac & iOS. And two developers on Windows whose names I have not memorised (my apologies.) For the Mac-centric who might not see the need, there would not only be the Mac version, but changing iOS and Windows to manage locked files, as it implies a project format change. It probably could not be done short of a major revision such as the one we are still in the middle of (Mac 2.x + Windows 1.x -> 3.0.x) with all the rollout issues we have now. I totally get that

  1. Keith is not about to do a feature like this when he’s still stomping Mac 3.0.x bugs and maybe considering feature tweaks, and
  2. if I were one of the Windows developers and Keith said “Oh by the way make locking files possible; you can do that without slipping the Windows 3 release, right?” I’d shoot him with a bazooka.

Thanks for some alternative strategies for working with my massive pile of words. :wink: I’ll re-read your suggestions carefully to see which might work best in my current workflow.

Still, to quote from the movie “Excalibur”—“It is a dream I have.” :smiley: (Arthur knew dang well that he was not going to get what he asked.)

I agree with Silverdragon. Scrivener is perfect for research and when I type out quotes/lists/summaries from text books that page is fixed as it is not my creative work but research. The reference library I use does not allow photocopying or photography so I am basically doing manual photocopying (fortunately I’m quite a fast typist).
I used to use Scrivener for poetry, once the poem is finished and carefully checked I don’t want any accidental changes. However I will give snapshots another try as it is less inconvenient than using MacJournal for something it wasn’t designed for.
Thank you for all your suggestions AMBERV, as I said I think saving just one snapshot and calling it something like Final Version (Checked) would be a good solution. When I need to be certain it hasn’t been changed I will just use Roll Back - I have started trying this and it is not as" convoluted" as I originally experienced it. I will reread your posts as there is really good advice there. This is good because as I said Scrivener is almost the perfect software for what I do.

Glad to hear it wasn’t all quite as messy as you remembered it being. It’s funny in a way because Scrivener has had two particular tools available to it, the auto-save and snapshot features, long before the concept was terribly popular—so it does do some things differently. With macOS 10.7, Apple introduced a similar mechanism system-wide, but with slightly less control over when a version is made. I find their implementation, although it doesn’t require any awareness to be using it, rather too far over on the side of chaff. If I browse through versions for documents I see micro-edits being preserved as whole slices in the version stack, and finding what I want can mean trawling through dozens of sentence level edits. And well, the less said about the Star Trek interface that blots out the entire computer until you are done with it, the better. :slight_smile:

I do prefer the more intentional mechanism Scrivener uses. To me, ⌘5 is a bit like ⌘S (and not just in appearance!). I use it whenever I’m about to change course while editing, and I use it when I’m done. I can browse “versions” that were made for human reasons in a comfortable and integrated environment. Make ⌘5 as habitual as saving in Word, or ⇧⌘5 as habitual as using Save As, and you’ll rarely run into cases where a sentence gets lost to an over-aggressive edit.

To summarise our offerings in terms of safety nets:

  • Fully automatic (by default): project backups. Every time you close the whole thing gets backed up, down to label changes and compile settings, let alone text.
  • Automatic snapshots (as an option): triggered whenever you save the whole project.
  • Manual backups: setting aside simply triggering the automatic backup system, manually setting aside a stack of backups in another location provides that same level of human reasoning for having them. The automatic stuff is good—like Time Machine and Versions can be—but a stack of files that isn’t rotated by software and that can be labelled meaningfully is often a life saver. If you accidentally modify an old book that is laying around in the binder for reference, you can pull up the milestone that was created when that book was finalised as a project and drag in as much binder tree as needed to restore it intact.
  • And of course by that same token, manually created snapshots fall into that same realm. You can have a somewhat macOS Versionesque spool of incidental time frames, but unlike macOS you can have labelled milestones thrown into the mix too.

For the stuff we write that we probably won’t want to edit again, that’s all well and good, but for the stuff that we definitely don’t want to edit, ever, try this:

  1. Hit ⌘P from the editor on the text you wish to preserve.
  2. From the print preview, use the “PDF” button to send a copy of the file back to Scrivener.
  3. Maybe copy and paste the original text it came from into the Document Notes for the PDF.

PDF remains searchable, can be annotated simply in Scrivener or more thoroughly in dedicated readers, and is pretty good for copy and paste (though the sidebar Notes copy would probably be preferable for that). And of course a similar approach can be adopted from the start—instead of dragging a .docx into the binder, just open it in LibreOffice or whatever and print it to Scrivener. If something truly is never meant to be touched, why import it as a text file at all?

Printing directly to Scrivener is a really good idea, I hadn’t thought of that. I have also discovered that a file in the draft folder can also be printed directly to the research folder which is wonderful.
With a snapshot for the final draft and printing for research my concerns are completely allayed and I now use Scrivener as my basic software again for writing and research.
Finally anyone reading my previous posts should be aware my one and only concern with Scrivener was fear of accidentally changing something after several months. This is definitely no longer a concern and I recommend this software without reservation.
(Please note: I have absolutely now connection with L&L whatsoever.)

I came here to suggest exactly this. This is different than snapshots as it is a different flow. Sometimes someone could accidentaly change a document (as minor as it is) in a project and not notice. Snapshots wouldn’t help with this.

The lock would make it simple to avoid documents being edited. It could be a padlock icon that someone clicks to lock/unlock, or perhaps a status could be set to lock the document from editing. For example, final draft sets locking to TRUE.

Make a ZIP backup, call it something like FirstDraftMilestone or MyProjectAsPublished and put it in a safe place.

If you need to look at it, unzip, which will create a brand new project. Do whatever you need to, then throw this new project away. The ZIP version is unchanged.

1 Like

That doesn’t address the issue. That is clunky, cumbersome.

On the other hand, it’s a feature that exists now and has not (in this very thread) been explicitly ruled out by the developer: Document locking - #5 by KB

1 Like

Just yesterday I was showing Scrivener and parts of my manuscript to someone, as I was going through documents I accidentally deleted part of the text (text was selected and I stroke a key by accident).

Even though I take snapshots, make backups, perform cloud sync and all of that – I could have been a disaster if I haven’t went back to the previous document and realised that a part of the text was done. A few Command+Zs has reverted what I did. But have I closed Scrivener, I might have never noticed what happened.

But locking a project would only help if you either showed the person a project you weren’t actively working on or remembered to lock it first.

If you’re demonstrating Scrivener, use the Tutorial project. That’s what it’s for and I use it for that purpose all the time.

If you’re demonstrating something relevant to your own work, make a backup first or use a duplicate project for the demonstration.

The developer has explicitly ruled out the feature you are requesting.

1 Like

That is not it – at all. I wasn’t demonstrating Scrivener. I was going through my writing. Saw the developer reply and… pff… Honestly. A little baffled as a software developer myself.

It is all down to UX design.

At the lower bar of each document (near the compile / don’t compile, label and first draft indicator), you could have a padlock icon. Clicking on it opens / closes the lock (enables / disables the lock).

If the document is locked, and the user tries to type on it, a gentle overlay appears saying “document is locked. Click on the padlock at the lower bar to unlock it”, the overlay then fades out (much like a mute/unmute overlay on MacOS).

Anyway this is just one of the many possible ways to do this. It could also be a pop-up instead and an option to “do not show this again” (I find this to be less elegant).

As a dev myself, I think I will add this feature into a well-known open-source alternative just because I can :laughing: Perhaps a practical demonstration of this feature is what is needed here :laughing:

Subject: Feature Request: Virtual Write Protection for Documents in Scrivener

Dear Scrivener Development Team,

I hope this message finds you well. I would like to request a new feature for Scrivener that I believe would greatly enhance the user experience: the option to add virtual write protection to documents.

Feature Request:

I propose implementing a virtual write protection for documents, allowing users to mark certain files as “write-protected.” This would prevent unintentional edits on documents that are not actively being worked on. An ideal implementation could involve a small “lock” icon located at the bottom-right corner of the document (next to the target icon), which the user can toggle on and off.

Why is this feature valuable?

When working with split-screen mode, it is common to have one document open as a reference while working on another in the main window. In such cases, it’s easy to accidentally modify the reference document, even when no changes are intended. Having the ability to lock a document would provide peace of mind and allow users to focus on their primary task without worrying about making unintended edits.

What should happen when a write-protected file is edited?

To maintain the user’s flow, I suggest a non-intrusive alert. For example, if a user attempts to edit a write-protected document, the lock icon could flash briefly, indicating that the document is locked from editing. This subtle feedback would remind the user that the document is protected, without disrupting their workflow.

Importance of the feature:

As a developer, I frequently use this feature in programming environments to protect critical parts of the code from accidental modifications. I believe it would serve a similar purpose in Scrivener, helping to safeguard important sections of documents or reference materials from accidental edits. Given Scrivener’s versatility, adding this virtual write-protection functionality would be an invaluable tool for writers managing large projects.

I look forward to any feedback or further discussion on this feature. Thank you.

1 Like

I like the idea, but the official answer is probably still “no”: Document locking - #5 by KB

1 Like

Can you explain why? Writing is the core-feature of your system. Many people write at home, a cat rushes over the keyboard or a wrong key is pressed without noticing it and the text is gone. So what’s so bad about it?
Regards

Read @AmberV’s post in that thread.

:slight_smile:
Mark

2 Likes

It’s not “my” system, I’m just a fellow writer. :innocent: As @xiamenese pointed out, please read the linked thread. KB and other L&L staff explained why over there uh, above now.

3 Likes

As noted, I’ve merged the thread, as I can’t imagine having a new discussion on this will produce much more than variations of what has already been gone over (and in other older duplicate threads as well). I don’t say that to be dismissive, just trying to avoid unnecessary repetition.

My posts in particular:

  • Implementation issues: the problem in Scrivener is not nearly as straightforward considering how it is more of an outliner that can generate pseudo-documents out of hundreds of outline nodes. Node level locking in an outliner would be unusual in and of itself, but not many outliners can do what I just described, which makes the idea even less appealing to design around.

    Sure, there are perhaps levels of alertness that could be used, like the flashing icon idea you bring up; but I don’t know, even if I knew why, I still feel like it would be off putting, having scattered ‘random’ paragraphs in the middle of a “document” that can’t be edited. That’s really more the design context we would be looking at here, than “lock file ‘name.txt’ in this folder”, from other software design models, such as IDEs.

  • A description of the safety nets already in place, all of which work with the design rather than being at conceptual friction with it.

Thanks for the clear write-up though!