RBZ update issue

jiminy-billy-bob

On my PC, I have full permissions on the Plugins folder. And I guess it's the same for Rich.
Have you tried reproducing the issue ? Do you have it ?

TIG

@jiminy-billy-bob said:

On my PC, I have full permissions on the Plugins folder. And I guess it's the same for Rich.
Have you tried reproducing the issue ? Do you have it ?
I do not get this issue at all.
v2013.
I have FULL read/write permissions to the Plugins folder.
I install your layer_panel plugin using the RBZ downloaded and the Extensions...button...
It's all OK.
I modify several of the files [rb/html/js/css], by adding non-intrusive <spaces> or 'rem' statements #, //, /**/ etc - in files in all subfolders etc.
I reinstall the plugin - manually using the RBZ again.
It's all OK again.
I check the changed files and they have all reverted to the original versions.
I repeat the 'remming' and get the AutoInstall version from the dialog.
It's all OK yet again.
I check the changed files and they have all reverted to the original versions yet again.

So for me it's all acting as I'd expect...

I haven't had an 'older version installed when I try this.

Can you check the permissions of your own installed subfolders/files etc... before trying a re-installation ?

jiminy-billy-bob

I also have full permissions. I checked 10 times.

Can you try removing LP from your plugins folder, then install the version 0.6 I uploaded in the first post, then update to 0.7 from the plugin store ?

jiminy-billy-bob

@tig said:

I install your layer_panel plugin using the RBZ downloaded and the Extensions...button...
It's all OK.
I modify several of the files [rb/html/js/css], by adding non-intrusive <spaces> or 'rem' statements #, //, /**/ etc - in files in all subfolders etc.
I reinstall the plugin - manually using the RBZ again.
It's all OK again.
I check the changed files and they have all reverted to the original versions.
I repeat the 'remming' and get the AutoInstall version from the dialog.
It's all OK yet again.
I check the changed files and they have all reverted to the original versions yet again.

Tried this, and everything gets updated except files in Plugins/jbb_layers_panel/... subfolders. Exactly as before...
I really don't get it.

TIG

Neither do I.
Does your plugin's own subfolder's contents never get updated, no matter which way you install the RBZ or equivalent ?
Every one of the installation methods works for me !
What is the security permission of that subfolder ?
'Exactly', compared to the main Plugins folder - it should be identical... including its 'owner'...
Have you changed it somehow ?
I hope it doesn't have a custom-icon !
That can subtly change permissions enough to break things although they still say 'FULL' they are slightly downgraded...
Perhaps reset to FULL for the main Plugins folder and ensure it filters down to the contents, and retry.
On my set up it takes the permission/ownership from the Plugins folder itself...

jiminy-billy-bob

@tig said:

On my set up it takes the permission/ownership from the Plugins folder itself...

Me too... They don't have special icons or anything.
The content of the "main" folder jbb_layers_panel gets updated, but not the two subfolders "js" and "css".

TIG

Have you double checked the sub-subfolders and their files' ownership/permissions etc.
EVERYTHING updates with me - I deliberately 'remmed' your js & css files and they were ALL updated back to be as they are in the RBZ, when I did a reinstall - by ANY of the 'RBZ install' methods.
They are share owner and permissions with the Plugins folder and your subfolder...

So I can't reproduce your problem...
There must be something intrinsically different between our two set ups ???
I can't think what.
Weird

TIG

OK... here's a test for you jbb...

Rename all of your 'jbb_layer_panel' in Plugins [as .rbXX for the the file [so it doesn't autoload AND not the more normal .rbX so the reinstalltion doesn't see it as a match and auto-delete it] and the plugin's subfolder with an 'X' on the end of its name so it's not compromised by the reinsatll yet to come]. We don't want to move these out of the Plugins folder because we want to compare permissions in situ...

Now install your plugin using one of the following methods:
Downloaded RBZ from the PluginStore page, then use Extensions > Install... button
Downloaded RBZ from the PluginStore page, then use SketchUcation Archive Installer from the menu.
AutoInstall using the SketchUcation Plugin Store dialog within SketchUp and 'AutoInstall' button.

Restart SketchUp and check it works.
Edit several of your files, including some in the plugin's subfolder and its nested folders.
Add 'rem' type text so the files are not changed in their operation, but are still easily seen as different - extra spaces, carriage-returns, #, //, /**/ etc.
Save the changes.
Note which are the changed files - although if you leave them open in Notepad++ any overwriting subsequently will be flagged anyway.

Now reinstall your plugin using one of the following methods:
Downloaded RBZ from the PluginStore page, then use Extensions > Install... button
Downloaded RBZ from the PluginStore page, then use SketchUcation Archive Installer from the menu.
AutoInstall using the SketchUcation Plugin Store dialog within SketchUp and 'AutoInstall' button.
You should find that all of the edits you have just saved have been undone and the files replaced with the originals again.
Repeat with the same 'rem' edits and reinstall for the other two methods.
If the changes are NOT undone then for some reason your installation is not overwriting all files, as it ought to.

When I do this I find that the [re]installation by any of the three methods works exactly as expected and all of the manually edited files are reverted to their original state, showing that the installer is working exactly as expected.

You say that files in the css & js nested subfolders are not being updated for you.
Choose a file in there and get its Properties > Security permissions.
Do the same for the equivalent file in the older subfolder you have previously renamed with the final X.
If the permissions are different and it's updating properly that's a clue.
If the permissions are different and it's NOT updating properly that's a mystery.
If the permissions are identical and it's NOT updating properly that's a clue.
If the permissions are identical and it's updating properly that's a mystery.

tt_su

Have you also checked the VirtualStore?

TIG

@tt_su said:

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