A ZIP backup is a single file, and is handled as such by sync services.
A Scrivener project is a folder, and is handled as such by sync services. That is, the individual component files may be uploaded/downloaded independently of each other. That’s mostly a good thing – that’s how you’re able to upload/download only the files that have changed – but does allow parts of the project to fail to download. (Or to be deliberately “left behind” by “smart” sync operations.)
Thanks.
I see those smart sync operators out to extract revenue for their cloud offerings.
I’m saying something different. Let me say it with a simple example…
Writer puts the Zip backups in a Dropbox folder (separate from the Project files, of course). For some reason the writer accidentally or deliberately deletes the backup Dropbox folder, or files in the folder, or there was a flaw on the computer which caused files to get corrupted–happens.
“That’s ok, I guess” says the writer, I can recover the file(s) from the online Dropbox copy.
Well, probably no can do. Dropbox probably has already synced the flaw (accidental or deliberate deletion, corruption, or whatever) to the online Dropbox server. Backup integrity gone.
My stuff, especially Scrivener stuff, is too important to me to not have a backup location that is seperate from the computer and thus more immune to failure. Nothing is perfect. That’s why the 3-2-1 backup regime was invented and advocated. My back-up regime is 3-2-1 with probably even more automatic redundancy.
Read about 3-2-1 Backup regime on the internet. Been around for years.
ps. That being said, Dropbox sync as backup is better than nothing, which unfortunately some people naievely do.
If someone does that they should ask for a refund on their school fees. A disinterested teacher has fooled them into believing they’re computer literate. It’s probably dangerous to allow them access to a calculator.
Dropbox gives a warning and if people blindly do crazy things they should take responsibility and live with the consequences of their bad decisions.
That said, I do multiple automatic backups and have a weekly routine of backing up to other locations.
I agree writer deleting (accidently or deliberately) backup files & folders in Dropbox is a silly thing to do, but that only one of a few things that can go wrong with backup files in a synced location. IMHO. Why do it when it’s so easy to not do it?
Exactly. Me too.
All right, so I managed to figure out and fix this issue, but figured I’d reply so as to ensure that others who might have a similar problem will be able to solve it for themselves.
I’ve been working off a micro because I often move from a main station to a laptop depending on where I’m writing that day. (I often go places without internet so as not to be distracted). The problem is that microsd’s seem to be copy error prone. The error won’t prevent scrivener from opening the file, but when it comes time to copy it elsewhere or save, the operating system refuses to perform.
It seems that backing up from a micro was what caused the system to copy the whole file into a temp folder for the zip process, and because the copy process failed, it wouldn’t perform the backup either. Same issue with trying to copy the whole folder off the micro to the hard drive.
Since Scrivener could still OPEN the file from the micro, I reasoned that whatever the operating system was seeing as corruption wasn’t a critical error, and if I could force the copy somehow, it would work once the files were properly on the drive.
For windows eleven, xcopy works. It’s native, and - run from the command line as administrator - will quietly force the move, though it will say there was a copy error. I was able to open the new file on the hard drive without any issue, and thence back them up and move them around without any indication of error.
For those of you who might need to force move your scrivener files, here is the line I used:
xcopy $SOURCE $DESTINATION /C /E /Q
/C flag forces xcopy to ignore any issues
/E flag orders xcopy to copy folders (even empty ones)
/Q flag makes it a quiet operation
So the moral of the story is, don’t work with your files on a micro. It’s fine to transport the backup zips on a micro, just don’t expand and run them from there or you’re liable to run into problems.
What’s a micro? A USB drive?
I think they were using a microSD drive, which is a tiny little thing about the size of a fingernail. Commonly used in cameras, but also in Raspberry Pis and similar gadgets.
I wouldn’t recommend working directly from a USB stick either, though, for the same reasons.