RBZ update issue

tt_su

Have you also checked the VirtualStore?

TIG

Have you also checked the VirtualStore?
The odd thing is that for jbb almost all of his tool's files installed from in the RBZ are updated properly, except some in nested subfolders [js & css] - I can't replicate it because they all update every time for me... so I must think there are some residual security permission for some nested subfolders/files that he already has in his Plugins folder and he has not fixed to FULL.
On a PC resetting FULL for Plugins ought to trickle that permission down to all contents [unlike MAC where you must explicitly tell it to do that].
This is a weird issue

BUT I agree that it is a very good idea to check the VirtualStore and look for any 'Compatibilities Files...' link/button in the Plugins folder's Windows Explorer window's top-bars...

jiminy-billy-bob

Okay, I finally got time to try this.
None of TIG's methods update the plugin. The permissions are identical.
The files in Plugins/jbb_layers_panel are updated properly, but none of the files in Plugins/jbb_layers_panel/js and Plugins/jbb_layers_panel/css. These subfolders are not even filled by the installer after deleting every file in them. They are not even created if I delete the folders themselves.

But... All of this works like a charm when Layers Panel is disabled in SU. So it makes me think it's related to SU, not to windows permissions.

jiminy-billy-bob

Ok, I found the faulty dude. I warn you, this is weird...

I use this method to make LP's dialog a ToolWindow : http://sketchucation.com/forums/viewtopic.php?p=280331#p280331
I noticed that when I tried to delete LP from my Plugins folder while SU was running, every file was ok to be deleted, except Win32API.so
Then I tried removing require 'jbb_layers_panel/Win32API.so' and everything using it in my ruby. And now it updates like a charm...

So I guess the rbz installer replaces every file in Plugins/jbb_layers_panel, and when it reaches Win32API.so (which is the last one due to its name), it fails and stops replacing the next files, including the sub-folders.

jiminy-billy-bob

Now, why does it work for some people and not others ? Probalby permissions-related, actually... But I have full permissions on it, exactly like the main LP folder, the sub-folders, the Plugins folder, the Programs files folder, etc.

Well, well...

tt_su

Ah! Yes. .so and .bundles that are loaded by SU cannot be updated or erased.

I have this same problem with my own plugins. I'm just about to complete a class that will take care of this.
In essence I'm moving to distributing extensions with C extensions in a manner where I place the .so/.bundle files in a "stage" folder and upon load I will copy them to a new folder given then name of the current plugin version. This should ensure files can be loaded and deleted even if the extensions are loaded.

The only thing left is to ensure that this works when UAC is enabled.

TIG

Windows won't let you replace a file when it is in use by another process.
The rb/html/js/css/png files etc are all 'read' and then done with when the script is first loads or the dialog opens is opened... but the .so is executed as the script loads and remains running until SketchUp closes.

If I don't have UAC active everything thing works fine for me and ALL files are updated as the RBZ installs.
I suspect that if you have UAC active this breaks things as you can't then replace the .so and subsequent changes are not effected.

If you ship the .so inside a 'SO' subfolder then the coded 'require' will miss it.
Do not include a version inside the RBZ's usual subfolder at all, load it with code each load.
The SO version of th .so won't be run at all as your plugin auto-loads, so any previous version of it that is preexisting should be over-writable by an RBZ installed update.
Then in your 'loader' rb code which sets everything up... before the line#16:
require 'jbb_layers_panel/Win32API.so'
add new code thus: which will try to replace the .so before the require for it: if it fails because it is already active and the UAC interferes, then it should get updated if SketchUp restarts.

begin
  pathi=File.join(File.dirname(_FILE_), 'SO', 'Win32API.so')
  pathi=File.join(File.dirname(_FILE_), 'Win32API.so')
  fii=File.open(pathi, "rb")
  fio=File.open(patho, "wb")
  fio.print(*(fii.readlines))
  fio.close
  fii.close
rescue
  UI.messagebox("Please Restart SketchUp to Complete the Update.")
  ### return nil ### ???
end
require 'jbb_layers_panel/Win32API.so'

It might fail if the .so already exists and the UAC interferes etc... so then there's the 'Restart' message...
This is untested...

tt_su

@tig said:

If I don't have UAC active everything thing works fine for me and ALL files are updated as the RBZ installs.
I suspect that if you have UAC active this breaks things as you can't then replace the .so and subsequent changes are not effected.

Is the .so file loaded then? I don't think you can update a loaded .so file regardless of UAC...

TIG

@tt

I have UAC disabled.
The tool reinstalls OK for me [I assume the .so is redone too...]
So I can update all files without problems.
JBB can't - his .so seems to stops the remainder of the insertion from the RBZ, leaving some file updates incomplete.
I was just guessing that this is because he has UAC active - that's the only difference I can see between us

My ../SO/so way [similar to yours?] will try to overwrite the required .so, perhaps failing if the .so is already-in-use, but if it fails it will recommend a restart, and that time update the .so and then the before the .so is required/run that time ?

jiminy-billy-bob

My UAC is disabled (of course ! haha)

About your "../SO/so way", I actually don't want to update the .so file, but I want the rbz installer to not stop when it runs into a file it can't override.
I guess I'll just put the .so file in a subfolder called something like "zzzzz_whatever", it will always be updated last and therefore every previous files won't have any problem.

TIG

So there is no notable difference between us - except my setup works and yours fails

If you put the maybe-needed .so file in a folder called ../SO... AND then unless File.exist?(path_to_so_in_subfolder) - i.e it's an existing installation - you just copy the data in ../SO/.so into path_to_so_in_subfolder...
That way, if the .so exists you leave it alone, and if it doesn't exist then you make it... BEFORE the require ... ??

jiminy-billy-bob

Hmmm, right.
Thanks