GD-111: Auto-update from 0.9.7-rc to 1.0.0 removes old version, but does not re-install new version

[Wcubed]

The used Godot version:
v3.3.2.stable.arch_linux

OS including version:
Manjaro, kernel 5.10.49-1 (64-bit)
Windows 10 (#113 )

Describe the bug
After running the auto-update, the addons directory is empty. The runtest.cmd and runtest.sh scripts are still there.

Steps to Reproduce

1. Start a new Godot project.
2. Go to the "AssetLib" tab ad install GdUnit3. At the moment (2021-07-22) this installs 0.9.7-rc (which I'm guessing will soon change to 1.0.0). Don't uncheck any files when installing.
3. Enable the plugin.
4. The updater pops up as expected. And notifies that v1.0.0 is available.
5. Click update
6. The update bar will show that the download is successful and the installation is complete.
7. Look in the addons folder, the plugin is no longer there. An update.zip sits in the project directory, with the files for v1.0.0 inside.

Workaround
As workaround you have to reinstall and press cancel on the upgrade screen

[MikeSchulze]

Thanks for reporting this bug.

At the moment (2021-07-22) this installs 0.9.7-rc (which I'm guessing will soon change to 1.0.0).

Yes, it will be updated later, I'm just leaving it for a while to get answers to possible updater errors ;)
You found one ;(

Have you any error logs collected?
I guess its a problem of missing tar util.
Can you verify tar is installed on your system, please.

[Wcubed]

Good point, should've added it right away :P

This is the entire log, from starting Godot, installing GdUnit, and updating it. The thing that stands out to me is the drivers/unix/file_access_unix.cpp:279 - Condition "!p_src" is true. lines.

Godot Engine v3.3.2.stable.arch_linux (c) 2007-2021 Juan Linietsky, Ariel Manzur & Godot Contributors.
--- GDScript language server started ---
GdUnit3: Set inital settings 'gdunit3/settings/update_notification_enabled' to 'True'.
GdUnit3: Set inital settings 'gdunit3/settings/server_connection_timeout_minutes' to '30'.
GdUnit3: Set inital settings 'gdunit3/settings/test_timeout_seconds' to '300'.
GdUnit3: Set inital settings 'gdunit3/report/error_notification' to 'False'.
GdUnit3: Set inital settings 'gdunit3/report/verbose_orphans' to 'True'.
GdUnit3: Set inital settings 'gdunit3/report/assert/verbose_errors' to 'True'.
GdUnit3: Set inital settings 'gdunit3/report/assert/verbose_warnings' to 'True'.
GdUnit3: Server successfully started on port 31002
Loading GdUnit3 Plugin success
Update .. Downloading update ..
 drivers/unix/file_access_unix.cpp:279 - Condition "!p_src" is true.
 drivers/unix/file_access_unix.cpp:279 - Condition "!p_src" is true.
Update .. disable GdUnit3 ..
Close all current opened scrpts ..
Unload GdUnit3 Plugin success
Update .. extracting zip ..
Update .. uninstall GdUnit3 ..
Update .. install new GdUnit3 version ..
Update .. refresh editor resources ..
Update .. executing patches ..
Update .. enable GdUnit3 ..
 core/project_settings.cpp:209 - Property not found: editor_plugins/enabled
 editor/editor_node.cpp:3255 - Addon 'res://addons/gdUnit3/plugin.cfg' failed to load. No directory found. Removing from enabled plugins.
Update .. New GdUnit successfully installed

The tar command is installed: Version 1.34

[MikeSchulze]

hmm interesting, Update .. extracting zip .. looks like it was extracted successfully

The error drivers/unix/file_access_unix.cpp:279 - Condition "!p_src" is true. is related to zero byte files, thats an reported Godot bug.

[MikeSchulze]

@Wcubed can you try to unpack the update.zip by tar -xf update.zip -C <a path>

The update.zip should normally located in the user temp and not in the project root folder.

[Wcubed]

Running this on the update.zip in the project directory: tar -xf update.zip -C ../output/ gives:

tar: This does not look like a tar archive
tar: Skipping to next header
tar: Exiting with failure status due to previous errors

[MikeSchulze]

thats interesting can you please attache the update.zip

[Wcubed]

Here you go 👍🏼
update.zip

[MikeSchulze]

Hm ... the zip file is not corrupted.
Looks like the zip format is not compatible with the tar version on your system.
I think i have to add some fallback options to e.g. unzip.

Can you try to unpack with other tools available in your system and provide me the used comand line options?
Also the result of OS.get_name()

[Wcubed]

Turns out apparently tar doesn't extract .zip files in general: https://unix.stackexchange.com/questions/146206/why-cant-tar-extract-zip-files

The unzip update.zip command works for extracting the zip file. To target a different directory, the -d flag worked.

OS.get_name() -> X11

[MikeSchulze]

nice, thanks for testing this in detail.
With this info i can add a fallback to unzip for X11

[Wcubed]

Sounds good 👍🏼 A final check to see if the unzipping worked correctly might also not be amiss ;)

[MikeSchulze]

Yes, definitely, is on my ToDo list ;)