6 to 7, copying Addons

Has anyone researched/does anyone know what’s actually happening when RW 7 copies Addons to their new location, please?

All that it seemed to do was create a new subfolder, ‘RapidWeaver 7’, inside ~/Library/Containers/com.realmacsoftware.rapidweaver/Data/Library/Application Support and put these three files there:

• RapidWeaver 7.log, 73539 bytes
• paddata.padl, 1592
• queue.pak, 674 bytes

It also took almost 45 minutes.

Any extra info about this would be welcome, please :slight_smile:

TIA!

Hmm I created a folder in my drop box and pointed the add ons in RW 7 and all the Haddon files are there as well as in RW6. Those files may point to the new add ons folder you may want to ask this by popping an email to support@realmacsoftware.com

Thanks, Scott - I have written to RM. Some clear docs would help… I bet they’re there somewhere :slight_smile:

It looked like a huge mess on my computer so I just took the plunge and moved the add ons folder to Dropbox. It makes more sense now and cleared out several empty folders that shouldn’t even be there. Best of all it’s much easier to locate manually now.

At some stage I’ll no doubt delete RW6 and I’m already working on RW7 full-time but I think this makes everything easier.

It’s a great idea (DropBox). But exactly what the upgrade-from-6-to-7 Copy does is still unclear (to me).

Specifically: doesn’t the process create a second folder in ~/Library/Containers, namely com.realmacsoftware.rapidweaver; and rename the ‘old’ one there to: com.realmacsoftware.rapidweaver6?

Doesn’t it then create a copy of the ‘Data’ hierarchy in ~/Library/Containers/com.realmacsoftware.rapidweaver and essentially copy Addons to ~/Library/Containers/com.realmacsoftware.rapidweaver/Data/Library/Application Support in /Library/Containers/com.realmacsoftware.rapidweaver/Data/Library/Application Support/RapidWeaver with the addition of /Library/Containers/com.realmacsoftware.rapidweaver/Data/Library/Application Support/RapidWeaver 7 with these files inside:

• RapidWeaver 7.log, 73539 bytes
• paddata.padl, 1592
• queue.pak, 674 bytes

If that’s it - is it safe to delete: ~/Library/Containers/com.realmacsoftware.rapidweaver6?

And only then start the DropBox move - presumably limiting that to: ~/Library/Containers/com.realmacsoftware.rapidweaver ?

TIA!

I would ask Realmac if it’s safe to delete any folders after moving the addons to Dropbox but if I check the old location now for RW6 there are a bunch of folders listing stacks etc that are entirely empty. Meanwhile RW7 contains those three items you discovered and a few empty folders that look out of place but aren’t doing any harm. I gather these are related to something before Stacks 3.1 was finalised.

One way or another it works now on both RW6 and RW7 but it would be helpful if Realmac could clear the muddy waters to explain what is going on assuming they understand it themselves!

Thanks @ashleykaryl! Agreed.

I have written to support@… - and hope to hear from them soon.

Maybe a simple page in the RW FAQ explaining exactly how this process (which does seem to work well) was conceived; and how we can best use it?

It doesn’t look like you can actually share the addons folder between RW6 and RW7 but I imagine there are practical reasons for not doing so including plugins that may only work with RW7 for example.

In general RW7 is working well enough for me and I see little reason to use RW6 if you have paid for the upgrade. I just wish the FTP was more reliable.

@ashleykaryl, I agree about reliability… FTP for me is also excellent :slight_smile:

I am just concerned that the copy process did work as designed the first time; and that everything really is where it should be; and that I can also delete the other directory… no going back.

Documentation, confirmation, that’s all!

Regarding the addons all I can tell you is that the switch took me 30 seconds and I’ve been working all day on a new site in RW7 without a hiccup using the various stacks.

RW FTP has never been reliable for me and it’s practically a case of guess the error with every upload, yet I never have a problem with Yummy. This was another baffling error message I had just half an hour ago at the end of an upload: