Ghost in the Machine?

I’ve got an odd one here.

Lately (since the newest update) every time I create a new folder or text, the words from a completely random folder/text automatically gets pasted into the newly created folder/text. And no, it’s never been the folder/text I’d been working in just previous.

The first several times this happened I thought I’d done something wrong. Maybe an inadvertent keystroke or similar. But now I’m certain Scriv is doing this on its own. My question is: why?

The really weird (and irritating) part is when I locate the folder the “ghost” copy/paste came from, the program acts like it wants to lock up. And then I have trouble toggling between the original folder’s text and the new “ghost” folder’s text. Further, deleting the “copied” text from the new folder/text also erases it from the original folder/text. Grrr.

Having used Windows since the very beginning, I can say this and other niggling oddities are giving me the distinct impression Win-Scriv is not stable. I know staff is small, but it feels like it’s going to be years before the Win version comes close to the Mac version; both in terms of stability and (and almost more importantly) feature set.

Please don’t suggest buying a Mac. I’ll suppress my personal derision for another time. More to the point, I didn’t spend twenty years learning to build and maintain PCs, to now have to consider switching to a platform lacking the ability to be worked upon or “tweaked” to any great degree.

And no, my Win platform is rock solid, both HW and SW-wise. It is not a test bed … it’s a daily-used machine.

I’ve looked high and low, yet see no firm timeline of when the Win version will pull even with the Mac version. I’d sure appreciate knowing this, as I’m sure others are wondering the same thing.

As much as I’m digging Scriv, I’m starting to get frustrated with how far behind (feature-wise) it is from the Mac version. It feels like a weak sister comparatively. And I now prohibit myself from the game of finding something lacking, only to find its inclusion in the Mac version.

Yes, I appreciate the Mac version has five or six year’s head start, but please give us some idea of how long the wait will be. I feel like an addict who has been told his pusher moved away.

That’s a very odd problem, is the project sitting in a location that is synchronised with an offsite server? I’m wondering if the addressing backbone, the “scrivx” file, is is out of touch with the file storage, in Files/Docs, on account of changes to the file structure being made behind its back. More specifically, Scrivener uses IDs to match the file with the piece of the interface it is supposed to fill. If you make a new document, it increments the ID number and builds a file if necessary to hold what you type. So say the current number is 23. The .scrivx file has a reference to 23 in it, and the software uses that to look up 23.rtf, along with 23_synopsis.txt and whatever else it needs when you click on it in the binder and edit it or even see it on a corkboard. Now say some synchronisation glitch happens and the .scrivx file ends up reverting to a version where 22 is the highest. You go to make a new document and so it adds 23–and poof there is already data because there is a 23.rtf on the disk already. Obviously, if this is the case that’s not good at all because that means the original 23 went missing from the original hierarchy (even though the data was still there) and so now you’ve got a spot in the outline somewhere that is missing this chunk. That would be a worst case scenario, and it would take a very spotty sync service to make such an error, but that’s the first thing that pops in my head when you say you make a new file and there is already content in it. The program loads content off of the disk, unless something else unanticipated is happening at the software level (rather than the disk level), then something on the disk already has that content in the position it expects for the new file. Since I’ve never heard of this happening before, it would seem more like a disk issue than a software issue (which isn’t to say the software didn’t cause it, mind).

I’d perform this test. I’d use Explorer to navigate to the project’s location and go into the Files/Docs folder. Take at look at the highest numbered RTF file. Don’t edit it, just look at it and close it without saving anything. Now open the project and create a new file. Is the same data coming up? If so, is there a new numbered RTF file in Explorer, or is it actually using the same numbered file you just checked?

The way you describe the secondary symptoms leads me to believe the same file is being used, and this could mean the .scrivx file is not saving properly somehow. Since this isn’t an endemic problem, my first suspicioun is how the project is stored. Everything from a faulty drive to a third-party software that is tinkering with the contents. That’s my thinking process. Whatever the case, it sounds like you are in a pickle with this project and the first thing I would do is go to your automatic backup folder (or backups that you create yourself) and create a hard copy of those as soon as possible. If you have to revert to a state prior to whatever caused this, you’ll want to have a copy of that state available.

As for deadlines of that magnitude you won’t find any. Our goal is to steadily work toward parity with a priority on performance, stability and data safety. These things aren’t as glamorous as new features; they don’t make posters, but it’s important stuff. We’re just as anxious as you are to get things matching in large part because we know how people think. We know they love their car with its crank down windows and never even think otherwise until they see a car with power windows—and now suddenly the lack of power windows is all that matters, and forget they even have the fortune of owning a car. That’s just how our brains work, so we don’t like having things like they are because of that, and not only that, because we want it to be as good for ourselves as well. I think they are doing excellent work so far. We’ve got the “car” on Windows in this analogy. It might not have heated massaging power operated seats yet, but at least you can get to work in twenty minutes instead of four hours of hiking.

If you look on the bright side of things, you’ve got a piece of software that already does everything it needs to from a core operating perspective, and on top of that it’s got a clearly mapped out, refined and published roadmap. You might not know when, but you know exactly how good it’s going to get. You can’t say that about too many programs. Not even Mac users can say that. It’ll be cool when both programs are breaking the ice together, nobody is denying that, but I wouldn’t myself complain about being able to speedboat up the broken path. With other programs, you might pick something that ends up going in a direction you don’t like, that happens all of the time. With Scrivener, you can see where it is headed and if you like what you see, then you’ve got a kind of security most people don’t get. To belabour the analogy further, what we don’t want to do is redline the boat all the way to the goal just to satisfy feature lust. You do that, and you end up with something that barely even works any more. It might be more frustrating when there is all that clear water in front, but sometimes its best to keep the development speed at a steady and prudent pace.

I was speaking about this issue and Jennifer had an idea that sparked another idea. Could it be you’ve been loading two different .scrivx files? For example, if you are accessing this project from two different machines, and at some point the main binder file got conflicted between them, and you ended up loading version A on one machine and B on another, then from that point on relied upon the re-open recent projects feature or the recent projects menu, and so have been thus working on two slightly different projects that almost look the same, but are not exactly and are yet using the same data pool. This could explain why when you create a new document in the binder, the RTF file already exists and you get magical data populated in it. The one odd thing is that you mentioned the you can find the data in the project elsewhere as well and that editing one changes the other. That’s where it gets a little weird and hard to explain—but the first thing I would do is go to this project’s location in Explorer and take a look in there. See if you’ve got more than one .scrivx file, and if anything else looks like it has been duplicated within the subfolders.


Thanks for the considered response. And while I agree with most of your analogies re: the Mac vs. Win vers. of Scrivener, the disparity causes gnashing of teeth regardless.

As to the oddity I mentioned, none of your or your colleague’s ideas are likely. This install of Scriv., the only one I use, is not on a server. Nor do I use any other machines to access any file in Scriv.

However, I do save all files to an external drive attached to this machine. But that isn’t likely the problem either, since no other program I use on this machine have any issue accessing data from this drive.

Neither is any third party software messing with things. I also name each iteration of any project I’m working on very clearly different so I don’t run into problems with similar-seeming versions.

I realize if I answer everything you suggested, my post will be longer than yours. So, to sum: I sincerely doubt anything you’ve suggested so far is the cause of this problem.

I’ll keep tabs on this and will drop by to see if anyone else starts to see this damnable ghost. Until then, I’ll keep a mallet next to the keyboard to whack whomever (or whatever) I catch mucking about in my machine.

Thanks much,


Thanks for the clarifications. It wouldn’t matter so much where Scrivener is installed, it’s where the data is stored that is more important. If the data is on a local machine (external drives are something I would include within that umbrella) and that is the only way it is accessed or even possible to access, then third-party duplications of critical infrastructure files are, I would agree with you, very unlikely. I was informed that this problem did crop up a few times before, but they always happened in cases where the project was stored on Dropbox, which readily qualifies under third-party tampering, and even just one editing session offline without precautions can cause issues.

Since it sounds like you do a good job of keeping a trail of your efforts recorded, do you have a spot prior to the update that you can go back to? What might be beneficial at this point is to revert to a copy of the project prior to when everything went afoul. Duplicate the folder and rename it; use it as your current latest and verify that nothing weird happens with a few quick tests. If everything looks good, then open up the one you’ve been using up to this point alongside it, and drag over any pieces you need to get it up to date from the old binder to the new one. Another thing you could do is select everything in the binder of the broken project and use File/Export/Files... into a new folder. Then just drag that entire folder into the recovery project. That way you’ll have the material right there ongoing, in case you notice any edit reversions.