KurtE
December 11, 2022, 7:32pm
1
Today, I thought I would do a quick experiment to see about adding an examples library to the Teensy install.
So I created a new directory for it...
Restarted the IDE and the examples did not show up under Teensy.
Figured maybe it is same issue as updating boards.txt or platform.txt
changes to boards.txt are not picked up · Issue #1030 · arduino/arduino-ide (github.com)
So I followed the workaround and deleted the directory:
C:\Users\<user name>\AppData\Roaming\arduino-ide\
I then restarted the IDE and got the following error:
I am running on Windows 11.
Note: I then exited and ran on a recent nightly build (yesterdays)
and it did not give me that error:
Platform arduino:avr@1.8.6 already installed
Downloading Keyboard@1.0.4
Keyboard@1.0.4
Installing Keyboard@1.0.4
Installed Keyboard@1.0.4
Downloading Mouse@1.0.1
Mouse@1.0.1
Installing Mouse@1.0.1
Installed Mouse@1.0.1
Downloading SD@1.2.4
SD@1.2.4
Installing SD@1.2.4
Installed SD@1.2.4
Downloading Servo@1.1.8
Servo@1.1.8
Installing Servo@1.1.8
Installed Servo@1.1.8
Downloading Stepper@1.1.3
Stepper@1.1.3
Installing Stepper@1.1.3
Installed Stepper@1.1.3
Downloading TFT@1.0.6
TFT@1.0.6
Installing TFT@1.0.6
Installed TFT@1.0.6
Downloading Arduino_BuiltIn@1.0.0
Arduino_BuiltIn@1.0.0
Installing Arduino_BuiltIn@1.0.0
Installed Arduino_BuiltIn@1.0.0
Downloading Ethernet@2.0.1
Ethernet@2.0.1
Installing Ethernet@2.0.1
Installed Ethernet@2.0.1
Downloading Firmata@2.5.8
Firmata@2.5.8
Installing Firmata@2.5.8
Installed Firmata@2.5.8
Downloading LiquidCrystal@1.0.7
LiquidCrystal@1.0.7
Installing LiquidCrystal@1.0.7
Installed LiquidCrystal@1.0.7
Note: Maybe it was showing up earlier after all, not sure. It was showing the name from library properties and not directory so not showing up at start of list....
Will update the file.
Not, sure if the first failure was expected or known, but reported it now just in case.
I also encounter this problem sometimes. I suspect it is a concurrency issue caused by the multiple Arduino CLI processes installing the library at the same time as updating the library index. My hypothesis is that when the index download is finished, the Arduino CLI instance is reloaded and it loses its internal state knowledge of the state produced by the installation in progress.
A similar bug is tracked here:
opened 12:06PM - 12 Jul 22 UTC
topic: code
type: imperfection
topic: gRPC
### Describe the problem
[The Arduino CLI daemon](https://arduino.github.io/a… rduino-cli/dev/commands/arduino-cli_daemon/) scans the installed libraries when a gRPC client instance is [initialized](https://arduino.github.io/arduino-cli/dev/rpc/commands/#initrequest). Library installation operations are based on the data from the scan.
The data from this scan will not be accurate if any of the following has occurred after a scan:
- Manual changes to library installations
- Installations made via [the `cc.arduino.cli.commands.v1.ArduinoCoreService.ZipLibraryInstall` method](https://arduino.github.io/arduino-cli/dev/rpc/commands/#ziplibraryinstallrequest)
- Installations made via [the `cc.arduino.cli.commands.v1.ArduinoCoreService.GitLibraryInstall` method](https://arduino.github.io/arduino-cli/dev/rpc/commands/#gitlibraryinstallrequest)
The first two are not uncommon for the user to do.
🐛 The result of library installation operations may be incorrect due to the libraries on disk not matching the internal data.
### To reproduce
#### Set up
```text
$ arduino-cli version
arduino-cli.exe Version: 0.25.0-rc1 Commit: 63b53c0f Date: 2022-07-12T01:46:05Z
$ export ARDUINO_DIRECTORIES_USER="/tmp/arduino-cli-directories-user" # Use a clean directories.data for demo
$ arduino-cli daemon
```
#### Demo
Use [grpcurl](https://github.com/fullstorydev/grpcurl) to run the following commands in another terminal:
```text
$ grpcurl \
-plaintext \
-import-path ./rpc \
-proto cc/arduino/cli/commands/v1/commands.proto \
127.0.0.1:50051 \
cc.arduino.cli.commands.v1.ArduinoCoreService.Create
{
"instance": {
"id": 1
}
}
$ grpcurl \
-plaintext \
-import-path ./rpc \
-proto cc/arduino/cli/commands/v1/commands.proto \
-d '{"instance": {"id": 1}}' \
127.0.0.1:50051 \
cc.arduino.cli.commands.v1.ArduinoCoreService.Init
$ export ARDUINO_DIRECTORIES_USER="/tmp/arduino-cli-directories-user"
$ arduino-cli lib install SD@1.2.3 # Change the libraries after Arduino CLI gRPC initialization
$ grpcurl \
-plaintext \
-import-path ./rpc \
-proto cc/arduino/cli/commands/v1/commands.proto \
-d '{"instance": {"id": 1}, "name": "SD", "version": "1.2.4"}' \
127.0.0.1:50051 \
cc.arduino.cli.commands.v1.ArduinoCoreService.LibraryInstall
ERROR:
Code: Unknown
Message: destination dir C:\Users\per\AppData\Local\Temp\arduino-cli-directories-user\libraries\SD already exists, cannot install
$ grpcurl \
-plaintext \
-import-path ./rpc \
-proto cc/arduino/cli/commands/v1/commands.proto \
-d '{"instance": {"id": 1}}' \
127.0.0.1:50051 \
cc.arduino.cli.commands.v1.ArduinoCoreService.Init
$ grpcurl \
-plaintext \
-import-path ./rpc \
-proto cc/arduino/cli/commands/v1/commands.proto \
-d '{"instance": {"id": 1}, "name": "SD", "version": "1.2.4"}' \
127.0.0.1:50051 \
cc.arduino.cli.commands.v1.ArduinoCoreService.LibraryInstall
{
"taskProgress": {
"name": "Downloading SD@1.2.4"
}
}
{
"progress": {
"file": "SD@1.2.4",
"completed": true
}
}
{
"taskProgress": {
"completed": true
}
}
{
"taskProgress": {
"name": "Installing SD@1.2.4"
}
}
{
"taskProgress": {
"message": "Replacing SD@1.2.3 with SD@1.2.4"
}
}
{
"taskProgress": {
"message": "Installed SD@1.2.4",
"completed": true
}
}
{
}
```
🐛 The library installation failed incorrectly due to the Arduino CLI gRPC daemon not being aware of the change that occurred externally. It was necessary to reinitialize the instance in order to make it behave correctly.
### Expected behavior
Libraries are re-scanned at the start of every library installation operation.
### Arduino CLI version
0.25.0-rc1 Commit: 63b53c0f
### Operating system
Windows
### Operating system version
10
### Additional context
This is a similar problem to https://github.com/arduino/arduino-cli/issues/1755. However, it was not introduced by the commit reported there.
### Issue checklist
- [X] I searched for previous reports in [the issue tracker](https://github.com/arduino/arduino-cli/issues?q=)
- [X] I verified the problem still occurs when using the [nightly build](https://arduino.github.io/arduino-cli/dev/installation/#nightly-builds)
- [X] My report contains all necessary details
And another here:
opened 04:16PM - 14 Jul 22 UTC
topic: code
type: imperfection
topic: CLI
### Describe the problem
In order to allow users to get started with Arduino … with the minimum amount of complexity, the Arduino IDE installs support for the most common boards and fundamental libraries automatically on the first run. This matches the experience provided by the Arduino IDE 1.x installation.
Users who were previously using Arduino IDE 1.x may already have some of these installed in the shared folders. Under certain conditions, this causes the installation of the "built-in" libraries to fail unexpectedly:
```
Failed to install library: Arduino_BuiltIn:1.0.0.
Error: 2 UNKNOWN: destination dir C:\Users\per\Documents\Arduino\libraries\SD already exists, cannot install
```
### To reproduce
1. Install one of the dependencies of the ["**Arduino_BuiltIn**"](https://github.com/arduino-libraries/Arduino_BuiltIn) library (e.g., ["**SD**"](https://github.com/arduino-libraries/SD)).
1. Uninstall the "**Arduino AVR Boards**" platform.
1. Select **File > Quit** from the Arduino IDE menus if it is running
1. Rename or delete (:warning: cautiously) the following folder to simulate a first run:
```
C:\Users\<user name>\AppData\Roaming\arduino-ide
```
1. Start the Arduino IDE.
1. When the Windows "**User Account Control**" dialogs for confirmation of the driver installation using "dpinst-amd64.exe" appear, promptly click the <kbd>**Yes**</kbd> button.
❗ The bug seems to be timing sensitive (likely requiring the library installation process to happen while the library and package index update is still in progress), the issue will not occur if the platform installation process is delayed excessively while blocked by this confirmation dialog.
🐛 Installation of the "Arduino_BuiltIn" library fails unexpectedly:
```text
Tool arduino:arduinoOTA@1.3.0 already installed
Downloading packages
Installing arduino:avr-gcc@7.3.0-atmel3.6.1-arduino7
arduino:avr-gcc@7.3.0-atmel3.6.1-arduino7 installed
Installing arduino:avrdude@6.3.0-arduino17
arduino:avrdude@6.3.0-arduino17 installed
Installing platform arduino:avr@1.8.5
Configuring platform.
Platform arduino:avr@1.8.5 installed
Failed to install library: Arduino_BuiltIn:1.0.0.
Error: 2 UNKNOWN: destination dir C:\Users\per\Documents\Arduino\libraries\SD already exists, cannot install
```
### Expected behavior
The library installation should be successful, skipping over the already installed "SD" library dependency:
```text
Already installed SD@1.2.4
```
### Arduino IDE version
2.0.0-rc8-snapshot-fb690c9
### Operating system
Windows
### Operating system version
10
### Additional context
I bisected the bug to https://github.com/arduino/arduino-ide/commit/a36524e02ab5fbc2ef333ff67a047dfe5718b306 (does not occur when using the build for https://github.com/arduino/arduino-ide/commit/1073c3fc7d9350532da40636aefc858c0a569e5f).
---
This appears to be related to this Arduino CLI bug:
https://github.com/arduino/arduino-cli/issues/1802
Even though the lack of awareness of external changes to the libraries reported at the link above is a bug in Arduino CLI, in this case there are no external changes to the libraries. So it seems there may also be a problem in the IDE that somehow results in the CLI being put into this state where its internal data about the libraries present does not match reality.
I was not able to reproduce this issue by running the equivalent operations via the Arduino CLI gRPC interface directly.
---
I have not been able to reproduce the issue on my Linux machine.
---
In the demo, I had the latest version of the SD library ("**SD@1.2.4**") installed, so even after https://github.com/arduino/arduino-ide/pull/1169 this would not be expected to fail.
Even under conditions where the library installation is expected to fail due to having an older version of one of the installed (e.g., "**SD@1.2.3**"), it should fail with a different error message:
```text
Error installing Arduino_BuiltIn: Library SD@1.2.4 is already installed, but with a different version: SD@1.2.3
```
---
I suspected that the same problem might also occur for people doing updates on startup, as is the normal user flow now that notifications are shown for updatable library or platforms on startup (https://github.com/arduino/arduino-ide/pull/1361).
If so, that would make the impact of the bug even more significant, since users will be performing updates regularly, whereas the first run library and platform installation operation will typically only occur once for each machine the IDE is used on.
However, I was not able to produce the bug in that way despite experimenting with different timings.
There is a report about the same error message here, triggered by an "INSTALL ALL" operation:
https://forum.arduino.cc/t/library-manager-is-empty/1002124/30
---
Reports of "`destination dir \_\_\_ already exists`" errors while installing/updating libraries:
- https://forum.arduino.cc/t/library-manager-is-empty/1002124/30
- https://forum.arduino.cc/t/question-on-2-0-0-ide/1035203
### Issue checklist
- [X] I searched for previous reports in [the issue tracker](https://github.com/arduino/arduino-ide/issues?q=)
- [X] I verified the problem still occurs when using the latest [nightly build](https://github.com/arduino/arduino-ide#nightly-builds)
- [X] My report contains all necessary details
Unfortunately I have not managed to find a straightforward set of steps that can be used to reproduce the issue. It only occurs for me when I have my ridiculous full collection of 40 boards platforms installed. If I switch to a more normal environment with only a handful of platforms, the problem never occurs. So I think it is very timing sensitive (as is often the case with concurrency bugs).
1 Like
KurtE
December 12, 2022, 1:14am
3
Thanks, I will keep an eye out to see if it reproduces with some simple setup.
Maybe sort of like the recent bug were the boards or library did not come up with the updateable option....
KurtE
December 12, 2022, 3:06pm
4
Quick update: I deleted that directory (C:\Users<user name>\AppData\Roaming\arduino-ide) again this morning,
And ended up failing again the same way, and second run worked.
My setup has several board types installed, but not outrageous.
Note: I do have on my machine the Teensy examples showing up.
I want them to show up at the start of the Teensy examples list. So thought maybe start the directory name with a . like: ".Teensy Exampes"
And they did not show up at all. Which I am guessing is already documented that it is probably using linux type rules, where files/directories whose name starts with a '.' are hidden.
So I removed the ., but left the . in the name property:
name=.Teensy Examples
And it now shows up at the start of the Teensy list:
Even before the title for the section. So, I will maybe next try starting the field with a 0 or the like
But at least I can now see the examples again
system
Closed
June 10, 2023, 3:07pm
5
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.