Snapshot lost me loads

I decided to do a snapshot of all the parts that made-up my document and so selected them all and did the snapshot. The result was that all part became the same as the top one and all old snapshots as well.

It has made me very wary of trusting the snapshot tool, and maybe Scrivener too.

Anyone else had any issues with Snapshot?

In Christ, Karl.

Hmm, it’s not possible for the snapshot tool to affect document contents - there’s nothing in the code that would do that. On the other hand, the “Show Snapshots” panel has to be called separately for each document. If you select “Show Snapshots” and then click on another document, the “Show Snapshots” panel will still show the snapshots for the document previously selected until you go to “Show Snapshots” again - are you sure you’re not just viewing the snapshots of the first document?

Thanks for the reply Keith.
After I did it I then clicked on each of the parts in my document and all were then the same, even empty ones then contained the same text. I now have re-written all the other text once again.

I can’t think how it happened, maybe the program had simply locked onto the first part and froze?

I’m still a bit wary but if no one else is having issues maybe it is only a one off, I’ll let you know if it happens again. Thank goodness I wasn’t a huge document. I’m using back-up until I feel more confident again.

In Christ Jesus, Karl.

This is really strange. Would it be possible to zip up your project and send it to me at support AT literatureandlatte DOT com? I’d like to take a look to see if I can find out what has happened.


Um, I’m no techie, but it sounds to me like you did something wrong. You (Karlos) selected multiple files and then hit “Snapshot”, right? From my own practice, that would only make a snapshot of the single file that had the cursor in it within your multiple-file selection. It wouldn’t have taken snapshots of the other files.

My understanding is that snapshots can only be taken/applied one file at a time. (That’s why, if I’m going to change more than one file, or if I’m gonna start a revision, I select, right-click, Duplicate the files and stick them in a “Versions” folder, then change the originals all I like.)

Now, from your second post, it sounds like you’re saying that all the selected files ended up overwritten with copies of the first document.

…Am I interpreting this correctly?

(Just trying to make sure you two are understanding each other.)

You’re right Carradee.
I selected them all then went to 'Documents>Snapshot>Take Snapshot of Selected Documents.

Seems a logical instruction from the menu so I did it and I am sure others will too. :slight_smile:

In Christ Jesus, Karl.

Karlos used the right command. There are three different snapshot functions, single-use, selection based, and global. Selection based uses the Binder selection and will snapshot each document individually, just as it sounds like it should do. Ordinarily, this works fine. I just tested it again myself with three test documents. All three snapshots were created and they all reflect the unique test data in each document. So the feature does work as intended and as described in the menu—outstanding potential bug above, aside.

Scrivener actually prohibits you from using the single-use snapshot feature when more than one item is selected in the Binder and that selection is being viewed in the editor as a corkboard. That prohibition is lifted as soon as the editor has a singular fix on a file. This can be achieved in two ways: double-clicking on a Corkboard icon in multiple selection mode to load a single file: now you can snapshot. Second method: Cmd-Opt-4 to Edit Scrivenings. Now snapshot works on whichever document the caret is in. So it is impossible to use single-use snapshot in a way that would impact more than one document.

Maybe there is a loophole in the prohibition logic, but that wouldn’t explain how the source documents and old snapshots got messed up. That’s very weird.

All that was a little over my head AmberV.
But does that mean that there is a real chance that all the individual parts of a document can be over written by the first if someone accidentally duplicates my (easy to make) error?

In Christ, Karl.

No - in fact, this should never be possible. Taking a snapshot is non-destructive. Nothing in the snapshot code even touches the text in the documents other than to copy it, so it should not be possible for taking a snapshot to overwrite any document text, which is why this is so odd. Could you set up a test project - one you don’t mind losing data in - and see if you can reproduce this?

I just tried but could not reproduce the error. When it happened it seemed to lock-up and the first time I hit the red close window button it would not close, it did the second time. Still, I lost most of my data. All the same I can not reproduce the error.

In Christ Jesus, Karl.

The red close button not working isn’t a good sign - that does sound like a bug. Could you please go to the ~/Applications/Utilities folder in the Finder and open the program, and then see if there are any errors reported in that program pertaining to Scrivener at around the time the problem occurred?

Does this mean anything…

I’m not sure what time the issue occurred.

In Christ, Karl.

I would like to add to the remarks of some earlier posters about snapshots. I think some sort of group or folder snapshot is a missing piece in the current snapshot functionality.

Perhaps the simplest way to do this would be to modify the behavior when snapshotting a folder. Taking a snapshot of a folder does not behave in scrivener as one would naively suspect: a folder snapshot only works on the data of the folder object itself — it’s synopsis, metadata, etc. — saving nothing about the contents of the folder.

But the ability of scrivener to organize a text as any number of separate documents organized as one wishes means necessarily that a lot of information about a text is then distributed across multiple documents and their particular organizational structure in a folder hierarchy. It is this structure, along with the individual document contents, that most often holds the state one would like to snapshot.

For example, snapshotting currently offers me no help if I reorganize the order of scenes in my screenplay: important information!

This simple change (conceptually simple, at least — the programming may be another matter!) would add no new complexity for users to keep track of, and would indeed be closer to a normal and intuitive understanding of how an operation on a folder should behave.

You can use File > Backup To to save a backup of the project in its current state if you are concerned about making changing the hierarchy. There’s no good way - technically - of snapshotting hierarchies given that the contents can change between snapshots, and no plans to do anything like this; snapshots are, as you point out, entirely for textual content.


The problem with the software making assumptions about whether you meant the selected item or stuff you didn’t actually select, but happens to fall beneath it, is that plenty of people write and edit in the containers themselves and want to snapshot those independently from the stuff beneath them.

Not quite, actually. Snapshots don’t save anything regarding meta-data or synopsis. The only thing they save is the text content of the item.

Your definition of “contents of the folder” is different than mine, which is the text contents of the folder—not the text contents of every Binder item within the folder. But I do see and understand why you think of it that way, just to be clear. Neither way is really right—it’s just a different perspective.

That is something else entirely, and actually quite complicated. Problems start to arise when you consider that structure and content are often very entwined. Just snapshotting structure could cause some serious glitching in the content. Meanwhile, binding the two together into a single function could end up with the user having done so many content edits while playing with structure (but then not liking the structure and wanting to revert just that part) that they can no longer use the snapshot because that would also means reverting the content.

Just as a simple example: You have five scenes that you want to play around with in terms of structure. So you take a “Super Snapshot” of the folder, which as proposed memorises not only the content of everything involved, but also the placement. You proceed to shuffle things around, hit Edit Scrivenings to review the flow, and as you read you realise that some of the narrative glue is a little rough in places because the old seams have been changed. So you fix that up—then leave it for a day and come back to it, this time realising that you wrote a piece of dialogue in a fashion that is out of character for one of the participants, so you fix that. Then two days later you come back and realise—you know, the way you wrote the structure and scene-flow the first time really was superior.

You don’t remember how it was precisely—but you can’t use the snapshot anymore. You’d lose all of that work you put in to fixing the dialogue and whatever else. I don’t think this example is altogether too contrived.

And this isn’t even getting into the mess of things that can go awry. What if you add three scenes to the experimental version? Do they just disappear without a trace when you restore? What if you delete a scene? What if you move it outside of the snapshotted structure and integrate it with another part of the book entirely? Does it, in place, suddenly revert to older content—does it snap back to where it was and leave a gap? There are just so many issues with this kind of proposal that make it way more complex for everyone, from the programmer to the user.

Meanwhile, Scrivener already gives you a way to do this. It’s just called Duplicate instead of Snapshot. If you want to play with a chapter. Select it and press [b]Cmd-D[/b]. Throw that aside out of the Draft in the Binder. Now if you come back a few days later and wish you’d left the flow alone, you can just go to the backed-up copy in the Binder and use it as a reference to get everything back the way it was.

If you made no content changes, you can just put the old one back in and delete the new experimental one.

This doesn’t seem complex to me, and it’s fairly “normal” too in terms of how we’ve always worked. If you want to experiment, you make a copy and play with the copy. That’s how we did things before computers, too.

In addition to that, Scrivener provides a way to play with structure in a non-destructive way as well. Try this:

  1. Select the contents of the folder you want to play with (not the folder)
  2. You’ll get a “Multiple Selection” corkboard
  3. Drag a few things around, and keep an eye on the Binder. Nothing happens—you aren’t actually modifying the book structure, you are just playing with the index cards at this point
  4. Open up a split (you now have two identical Multiple Selection corkboards, both showing the experimental order)
  5. In the new split. Select all the cards and press Cmd-Opt-4 to Edit Scrivenings
  6. Review narrative flow (optionally, at this point, you could edit out the snags and snapshot the individual files as you go)
  7. Like it? Go back to the top split, select the index cards and drag them back into the Binder where you got them from. New order is now committed.
  8. Don’t like it? Just click anywhere in the Binder and it all goes away (though, naturally if you edited in step 6, you’ll want to revert any necessary snapshots most likely).

So that’s two ways you can experiment. One let’s you take several days to mull it over with a safe backup stored in the project. The second lets you quickly play with an idea, and if it is gold, commit it.

I’ve looked around a little and didn’t see any info on this, so I have to ask–is this an ideological choice or just a programming problem? I personally would love to have the metadata stored in a snapshot, not least so I could write notes pertaining to the state of the snapshot, but I understand it might just be too much to keep track of. Just wondered if this was something that might exist in the future, or if it’s long ago been ruled out.

Hmm, yes I don’t precisely recall any discussions on it that I could easily find. I remember it being discussed at some point, perhaps even more than once, but so long ago and in such vague terms that finding it would be difficult. I think the main reason, again if I remember correctly, was more technical than ideological, with some interface issues as spice. I’m afraid 2.0 would modify the interface situation in further away from where this would be terribly useful (especially as a highly visible way of adding notes to a snapshot).

Incidentally though, the way I annotate snapshots is to—annotate them. :slight_smile: If I want to jaw on about the current state of the document, more than a title will allow, then I just Cmd-UpArrow, and add an annotation to the very top, snap it, then delete the note. Now when you browse through the Snapshot Viewer, that note is right at the top in bright red.

Sheer brilliance! I love annotations. My only sorrow with them is that when converted to square bracket annotations, the bracket starts at the beginning of the annotation even if there’s a space left before the first word. (So it looks[ like this].) Still, a small matter, and there’s probably a way to do something fancy with MMD or something else I don’t understand and avoid that the times it’s an issue. Also, I have to thank you for all your many posts on using annotations wisely, because I’ve garnered plenty of tips from reading them!

Yeah, you’re welcome!

I don’t remember why annotations preserve their internal space padding. I know footnotes strip out the fat.

When adding the brackets, Scrivener just inserts them exactly where the annotation starts and ends.