Update: Lost five years of writing archives in the switch. All the subfolders were empty. I have since ditched Scrivener for google drive. 
Lesson learned. Really loved this software for a long time, not sure what happened. Could be user error for sure, but I can’t take the risk anymore.
Something went wrong, clearly.
The most common cause of this sort of issue is mishandling of the project folder by whatever service was used to transfer it. For instance, many services – notably including Google Drive – will transfer only the top level .scriv folder, but not the folders containing your actual work.
One place to look would be Scrivener’s automatic backups, which by default are ZIP files.
2 Likes
It was a hard drive to hard drive transfer with no cloud interference.
On windows I copied all of my documents to an external hard drive from my internal hard drive. Then I disconnected the drive, physically, flashed the PC to Linux Mint, and reconnected the external drive. There were no zip files, no backups, and nothing in the sub directories for the scrivener documents. Old scrivener, new scrivener, didn’t matter. Nothing copied over. No other document or sub directory had these issues.
Originally the documents were hosted on dropbox. As projects moved from active to archived in my workflow, they were copied from dropbox to my local machine. The copies were functional, so it wasn’t a case of the dropbox transfer failing. These files disappeared after being transferred to the new drive.
User error? Yeah I’m open to that. But the previous versions of Scrivener also had a much clearer and better file structure. If there was a catastrophic failure, you could still very easily go into your folders and figure out where say, chapter 10 was. Now you can’t do that. Is this related, no, probably not.
Not mad at y’all, I know you’re doing your best and this was a) a very weird situation, and b) still most likely user error, but this is something to perhaps take a closer look at before writing off as pure user error (which again, still possible). Linux is increasing in market share, and most likely, people like me with it.
1 Like
This is not something Scrivener could’ve done, really? It can only see (and read/write) to the file you are currently working on. Scrivener doesn’t do anything to other folders or other projects. I’m not sure what happened there, but I’d be very concerned about other external things that could be messing with your files.
Regardless, that all sound horrible anyway, and I’m so sorry to hear you lost a lot of work (like… visceral groan of horror here).
I’ve been using Scrivener for well over a decade, hundreds of projects, and have never (touch wood) lost files outside of self-inflicted injury.
3 Likes
It sounds to me like you have no serialised, regular backup system, just this one external drive you copied your data to prior to formatting the disk? You have no other backups anywhere at all, even if maybe a bit out of date?
Yeah I’m open to that. But the previous versions of Scrivener also had a much clearer and better file structure.
It hasn’t really changed that much though, so I’m not sure what you’re referring to there. That said, whether its storage structure is subjectively clearer or better is beside the point when it comes to making a full backup copy of something. A full backup doesn’t care if you have ten thousand randomly named folders or a very neat and extremely carefully organised directory structure. A good backup will copy all of it, and be capable of restoring all of it verbatim, down to the byte.
Linux is increasing in market share, and most likely, people like me with it.
Well no doubt about that, but I don’t know how any of this has to do with it. A result like this could come about from any migration, not even to a different platform. A Win 10 to 11 clean upgrade on a formatted disk could see this happen.
It sounds to me like an incomplete backup was created, then the original was destroyed before the backup was verified, and now you don’t have your work any more. That has nothing to do with software or operating systems, but everything to do with the old rule of thumb regarding backups:
If you’ve never fully tested restoring from it, then you don’t have a backup.
P.S. I’ve split this off to a new discussion thread, as it doesn’t have much to do with Linux, or appealing to us to support it directly. You’ll run into this whether you run Scrivener through Wine or natively, or whether you use Scrivener at all, or Vim.
3 Likes
Yeah, that’s fair. Oh well.
By the way, what I would try in your shoes, from what you described, is this from the shell:
find ~ -type f -name "*-bak-*.zip"
Or replace the ~ with the full path to wherever your backup disk is mounted to, if you haven’t fully copied its contents into your home folder yet. This may take a while, but it will scour every file in the backup for filenames matching the pattern of Scrivener’s automatic backups. These, unlike the unpacked project folders, are self-contained in singular files (.zip) and are thus more likely to have survived an incomplete disk transfer.
3 Likes
Thanks, but no results.
All the best to y’all.
Oof, okay. Well the only other last resort I can think of is to use a similar find command, only replacing the quoted part on the end with "search.indexes". This is what Scrivener names the internal search index file in each project, and it 99.9% of the time contain a complete record of every bit of text in the project you could search for, which is a lot (labels, titles, synopses, notes, text of course, and more). One can restore a lot from that file, if they otherwise lose the data in the project. The main downside is that, as a search index, it lacks formatting, but it is otherwise a very easy to read and work with XML file.
Other than that, there are Snapshots, if those folders and files got copied but not the main ones. That will of course be in most cases much more of a patchwork though, as it would depend upon you having taken snapshots of every binder item. Those that make use of the option to automatically snapshot every modified item on manual save will potentially have a much more complete record.
2 Likes