Symbolic Links danger

For the last 15 years developing for SketchUp I’ve used symbolic links from the SketchUp Plugins folder to my dev disk. It means when you build, or change anything, its instantly visible in the Sketchup folder. A real time saver.

However. Today, I had some problems with my Plugin and without thinking.. clicked the “Remove Plugin” button in Extension Manager. It instantly wiped my dev disk partition.

Luckily I have mirrors / rcs etc but more than a bit of swearing was heard.

It would be great if SketchUp checked if the folder was a symbolic link before nuking it. Yes, I know the Plugins folder is owned by SketchUp. But it would be a Good Citizen thing not to delete non regular folders. Just sayin.

Oof - Thanks for the heads up. Accidentally deleting an extension with Remove Plugin usually happens about once. That accident with sym links would be unexpected and a potentially catastrophic learning experience. Glad you had backups.

For one project I have in Xcode there is about 110 GB of Conan data, which is a lot of internal drive space to give up, so I have the data folder symbolic linked to an external drive. Xcode can build the app without a clue that the data isn’t where it appears to be.

Are symbolic links suppose to really look like the data? Would the extension manager know if the data was local or not?

When I create symlinks in the Plugins folder and view their properties, the location (in General tab) is the Plugins folder. The target (in Shortcut tab) is shown as the path of the actual extension files. I happen to have a number of extensions in some of those folders. It sounds like using the EM to remove one could obliterate the whole bunch. It’s a very good heads up since it’s not obvious that removing the extension (symlink) via EM would remove the extension files located elsewhere.

Hello @AdamB,

I’m not sure that checking symlink is a solution.
Deleting DEV folder can be done too by loading extension from a normal path out of the SketchUp’s Plugins folder. I know, I did it too :slight_smile:

Are symbolic links suppose to really look like the data? Would the extension manager know if the data was local or not?

Yes, if you stat() a file/directory that is a link it will show as having st_nlink > 1 and you could skip deleting it.

A plain vanilla file/directory will show as having just st_nlink == 1

sys/stat.h for more info

Let’s tag @CraigTrickett - he might be able to run the idea by the team.

What is the advantage over just having a little “path pusher” file in the normal Plugins folder?

# !!_push_dev_path.rb
$LOAD_PATH.push("D:/Projects/SketchUp/Plugins/")

… OR using ThomThom’s Extension Sources interface?

With everything we need/want to do, big and small, I don’t know how realistic it is to get to this. Also, with a conventional project file structure, uninstalling an extension from the Extension Manager should just remove the files that map to the final package, the git history should be preserved allowing you to restore files.

Within each extension repository, I have a sub directory called src mapping to the RBZ and ultimately the user’s Plugins folder. Outside of it I have tests, internal documentation, build scripts, Extension Warehouse description, Extension Warehouse screenshots and anything else that doesn’t go into the actual build, including the git history.

In the Plugins folder I have a simple script like this

# working_directory_loader.rb

pattern = "path_to_my_extension_projects/*/src"
Dir.glob(pattern).each do |dir|
  $LOAD_PATH << dir
  Dir.glob("#{dir}/*.rb").each { |p| require p }
end

You can also use Extension Sources as Dan said.

Appreciate you are busy. But I think you are missing the point.

Its clear I am not the only one to have Extension Manager nuke files by mistake.

An installer should - as a matter of course - wrap their File I/O routines so they are very conservative and don’t do things like this. Blindly deleting entire file hierarchies “because you shouldn’t have put it there” isn’t great.

And sure, your suggestion about altering the $LOAD_PATH works too.

I am in the habit of actually installing or manually copying updated extension files from my dev location to the normal “Plugins” folder path.

Why? Because this is what SketchUp expects out “in the wild”. SketchUp expects that itself will be installing the files and that itself would then be free to delete them during an uninstall routine. So I feel this is the best way to test them. (I have not yet made the mistake of uninstalling a dev folder.)

But I also do on occasion use ThomThom’s utility for some projects and when not working on it I switch them off using this utility.

I understand that that the EM’s uninstaller is destructive and would not be desirable for extensions in development.

  • Perhaps the EM could be made to gray out (disable) the Uninstall button if the EM’s "extension_info.txt" file and the extension’s .susig certificate are not present?

FWIW, I do not see any (or easy) way to “monkey-patch” the SketchupExtension class to prevent certain extension files from being deleted during an uninstall. (I.e., the actual uninstall operation is apparently coded on the C-side.)
Also, the Uninstall button is available even for little scripts I’ve manually dropped into the Plugins folder.