Is there a way to rebuild the Snapshot index.xml to remove invalid entries? Turns out running a duplicate file checker on that folder results in a bunch of undeletable ghost snapshots. (It didn’t do this on 1.9. 
) I tried rebuild search indexes but that didn’t help. Removing index.xml from the folder just resulted in the snapshots becoming inaccessible in-program.
I couldn’t find any way to rebuild the snapshot index, but I found that I could rename the phantom snapshots to “blank” and then edit the index.xml files to remove them manually.
As you note there is no way to rebuild the snapshot index. As a static resource that isn’t meant to be modified externally, there should in theory be no need to ever do that. This a bit of an extenuating circumstance that you describe!
Disappointed to read this. I’ve been looking for a way to reconnect to some of mine that got ‘lost’ somehow and despite still being in the files, no longer show in the preview window 
.
That sounds like a display bug or something to me, it’s probably worth bringing up as a specific issue, perhaps with tech support directly, so that you can send a sample or two.
The issue being discussed here is if another tool deletes files belonging to Scrivener, not if the files are there, but aren’t displaying their text.
Yes, I’m aware of the differing issues. It was the reference to rebuilding the snapshot index I was referring to. I know I can access them it’s just a PITA finding them, having to search through hundreds of files when I need to. I’ve since stopped using the snapshot feature anyway as it’s plainly not reliable enough as a backup for previous versions. As the team don’t seem interested in fixing bugs for the current version I doubt they’d want an email from something caused in version 1.
Right, but again if a bug caused the snapshot to become damaged, so that it cannot be read in the viewer, then rebuilding the list of which files exist on the disk wouldn’t do anything for you. There is no content-level index of snapshots, in other words. The index is purely a decentralised network of XML files describing file names, date stamps and descriptive text.
I can’t speak for the v1 version in terms of data security. I honestly never used it much, but I do use v3 quite a bit and have never seen any issues with snapshots. That said, it is a purely optional feature that you don’t have to use, and there are other ways to keep your work safe with backups. So if you don’t trust it, it’s probably just a minor drop in convenience.
Personally I treat snapshots like an extended undo more than anything. I don’t really trust them—but that’s certainly more to do with how I don’t trust any technology, at all, and why I take backups upon backups, no matter what software or OS I’m using.
As the team don’t seem interested in fixing bugs for the current version I doubt they’d want an email from something caused in version 1.
Uh, as member of said team that spends a good percentage of every day working on just that… what? Would you like some balloons to pop?
That aside, sure, I doubt we’re going to spend time investigating something that happened years ago in a retired piece of software, thanks for clarifying that as the point of origination.
The snapshots aren’t damaged. They are all there in the files. Scrivener knows they are there, they’re listed in the Inspector. It just can’t display the contents of them. I have to go digging in the project files via Windows File Explorer if I need to see the text. At some point I need to go through them all and copy and paste them into a new document.
Apologies for that remark. Was uncalled for. My compile last night failed yet again due to an errant ‘&’ symbol and I’m grumpy from having to trawl through hundreds of comments to find it at silly o’clock.
No worries, I understand where you are coming from, as there are things that frustrate me that I wish they could get fixed as well. I’m having to go through the entire user manual project right now, fixing over a thousand lists because there is a limitation in the text engine that causes them to break (it’s a very niche problem that combines unusual features, but there is no workaround). But I have to do it so I can publish a version of the Scrivener project that everyone can open, and not just Mac users.
To clarify what I meant by “damaged”, I mean to the degree that Scrivener can’t view them. It could be the files are technically fine and can be loaded in Word for instance, but something in the file is working in a way that Scrivener doesn’t expect, so from its frame of view, as the sole arbiter of these files (in theory) it is damaged in that it doesn’t view them properly.
And that’s the part that I was hoping we could see a sample of. If there is a simple problem that is causing the snapshot text to not view, even though it is plainly there, it’s maybe something we can fix in the current version, even if the source of the problem was from the old version.