(copied from the other forum – just to make sure everyone see this)
I’m going to roll things out in a couple parts.
The first is a tiny point-fix for Stacks v4.2. This will be v4.2.5, a free update, and the beta should be on our servers in an hour or two.
The second is a larger update with new features and improvements. This will be a paid update and will be out in a week or two.
Let me talk about this first point fix and what we’re testing in the beta.
This beta version will come with one minor bug-fix that I think may be all that’s necessary. But I wanted to go a step further.
Since writing the file handling code of Stacks v2 back in 2012 we’ve had a few secret debugging modes that we could enable for users that were experiencing data loss or file corruption.
- The first simply exposes the Stack Image Backup. Stacks uses this cache to store a “hard-link” of the images in your loaded pages. This is a just-in-case backup that Stacks keeps if the project file is moved or renamed and the links that RapidWeaver provides become stale and no longer work.
This is rarely (ever???) a problem anymore. But when I wrote this file handling code for Stacks v2 in 2012 this happened anytime the file was renamed.
You might be worried that this is creating a lot of extra data on your hard disk – but you don’t need to. These images aren’t real “copies” they’re hard-links. ← I linked a wikipedia page about them there.
Hard links are just another icon that points to the same data on your hard drive. If the original icon is trashed or moved – then my hard-link “copy” remains pointing at the data. It’s a way to backup data without actually taking up more space on your disk. Cool, right!?
The cache also houses the images that you drag into Image stacks or into the sidebar settings. Again, stacks uses this as a backup in case the original image gets moved or renamed. We’ve now exposed this folder to you, so you can have a look and see what images Stacks knows about – and even try confusing Stacks by deleting the cache if you feel compelled (please do testing on a non-critical file or a backup of your original).
Between the original image you dragged in to stacks, the Image Backup, and the data in the file – there should always be a redundant copy of every image, just in case. When Stacks saves your project it will fall back to the Image Backup if your original file data or the project data is unavailable for any reason.
The backup folder is designed to make a system that was quite faulty (in 2012) completely fail-safe. So any sort of failure just caused a fall back to the backup.
In this beta version you can get to this folder by clicking an arrow in the Stacks Prefs (check out the screenshot below)
Normally a new folder is created in the Image Backup every time you use Stacks. Then this same folder is cleaned up when RapidWeaver Quits (there’s some longer term cleanups too).
But I’ve disabled the clean-ups in this version. It will just keep adding new folders – just while you’re using this beta. We’ll clean them up normally when we finalize the release.
Lastly, this beta version will delay pruning any images from the project. If the issue is related to Stacks making poor decisions about which images are in use and which have stopped being use, then this debug mode will keep everything just in case.
My hope is that the fix, combined with the three debug modes will correct any issues that people have been seeing related to missing data. I would appreciate hearing back from folks whether it fixes things or not.
If it does, we’ll remove the debugging modes and make the changes permanent. Once we’ve verified that everything is still working we can roll the changes out to everyone.
If you have any questions, fire away. However I may not reply immediately… I have to go get a root canal at 3pm (in two hours). Not fun.
But I’ll try to get the beta posted before the dentists hauls me away (kicking and screaming like a child – LOL).