The vmware tools link has changed.
BDisp opened this issue · comments
Thankful to @juniormayhe who reported here #28. Probably changed with the VMware Workstation 17.0.1-21139696 release.
I also planed in a next release to remove all the code with all the olds links to get the tools. The gettools always get the last version, as I think is the correct behavior. So, if some VMware Workstation version isn't compatible with the latest vmware tools, the user must update to new vmware version or download and extract the tools manually. So, the worst that could happen is the message Couldn't find tools appears. If that happens I appreciate someone can open a new issue, if already not exist one, reporting the error.
What happened here with unlocker is that there was this erratic error in my Windows 10 environment. You see, sometimes, I could run unlocker and sometimes it just failed because there are some processes still alive, even after I had completely closed vmware software in Windows 10.
I decided to include this process killing in the script after seeing a video where a guy with had some issues with unlocker, and he was closing the vm processes manually in taskmanager before running the unlocker. I was searching and found that psutil would be a good fit for cross platform OSes.
If the goal of gettools is to bring always the latest, we cannot really guarantee that, because if those guys in vmware keep changing the paths it would be difficult to keep the binary available.
Or, they could just shutdown that address and we won't be able to download the tools anymore.
I'm wondering if there is a timeless url to host such tools files, so we could guarantee the tools aren't foverever lost, causing the script to fail.
I saw some people pushing some binary files to archive.org or we could embed the main tools files within the repo if there is no license issue around.
What happened here with unlocker is that there was this erratic error in my Windows 10 environment. You see, sometimes, I could run unlocker and sometimes it just failed because there are some processes still alive, even after I had completely closed vmware software in Windows 10.
I decided to include this process killing in the script after seeing a video where a guy with had some issues with unlocker, and he was closing the vm processes manually in taskmanager before running the unlocker. I was searching and found that psutil would be a good fit for cross platform OSes.
I don´t have that problem. The unlocker must be run with the win-install on Windows or the lnx-install on Linux. If you run directly with the unlocker.exe or with unlocker.py on Windows you will have the error. If some error occurs during running unlocker, some processes may have be locked by OS. Another erroneous procedure is run the installer more than once without run the uninstall first if installer was already runs before. What this procedure causes is patching files already patched and thus the final patched files may be corrupted. I really appreciate your effort but while the current system work well like this, I'll maintain it.
If the goal of gettools is to bring always the latest, we cannot really guarantee that, because if those guys in vmware keep changing the paths it would be difficult to keep the binary available.
Of course, is the way that it works all the time. If a more recent tools are released and the path is different than the current fetch, then I have to update it again. Normally someone open a issue to inform that the tools isn't available.
Or, they could just shutdown that address and we won't be able to download the tools anymore.
Well, that isn't possible because they must have that service open for the users.
I'm wondering if there is a timeless url to host such tools files, so we could guarantee the tools aren't foverever lost, causing the script to fail.
If that happens would be a bad news, probably we would think they stopping developing it. No problem if that happens we use another software.
I saw some people pushing some binary files to archive.org or we could embed the main tools files within the repo if there is no license issue around.
No, that it's a bad practice. I only rely on original files. I do not trust on pulling from any non official sources.