Bug: mv: cannot stat '/home/liberal/.sdkman/tmp/groovy-3.0.9.bin': No such file or directory

[OldManGerman]

Bug report On 12th December 2021 I installed cygwin_setup-x86_64.exe on my computer with Windows 10.

$ sdk i groovy

Downloading: groovy 3.0.9

In progress...

Warning: Failed to open Warning: /home/liberal/.sdkman/var/metadata/groovy-3.0.9.headers mv: cannot stat '/home/liberal/.sdkman/tmp/groovy-3.0.9.bin': No such file or directory

To reproduce

$ curl -s "https://get.sdkman.io" | bash Looking for a previous installation of SDKMAN... Looking for unzip... Looking for zip... Looking for curl... Looking for sed... Installing SDKMAN scripts... Create distribution directories... Getting available candidates... Prime the config file... Download script archive... ######################################################################## 100,0% Extract script archive... Cygwin detected - normalizing paths for unzip... Install scripts... Set version to 5.13.1 ... Attempt update of interactive bash profile on regular UNIX... Added sdkman init snippet to /home/liberal/.bashrc Attempt update of zsh profile... Updated existing /home/liberal/.zshrc

All done!

Please open a new terminal, or run the following in the existing one:

source "/home/liberal/.sdkman/bin/sdkman-init.sh"

Then issue the following command:

sdk help

Enjoy!!!

$ source "/home/liberal/.sdkman/bin/sdkman-init.sh"

$ sdk i groovy

Downloading: groovy 3.0.9

In progress...

Warning: Failed to open Warning: /home/liberal/.sdkman/var/metadata/groovy-3.0.9.headers mv: cannot stat '/home/liberal/.sdkman/tmp/groovy-3.0.9.bin': No such file or directory

System info $ uname -a CYGWIN_NT-10.0 Wohnzimmer-PC 3.3.3(0.341/5/3) 2021-12-03 16:35 x86_64 Cygwin

$ bash --version GNU bash, version 4.4.12(3)-release (x86_64-unknown-cygwin)

$ sdk version ==== BROADCAST =================================================================

• 2021-12-14: grails 5.0.3 available on SDKMAN!
• 2021-12-14: micronaut 3.2.3 available on SDKMAN!

• 2021-12-14: vertx 3.9.11 available on SDKMAN!

SDKMAN 5.13.1

[Gvald]

Any progress with this? Happens to me too, when trying to install gradle:

XXX@XXX ~ sdk install gradle

Downloading: gradle 7.4

In progress...

Warning: Failed to open /home/ubuntu/.sdkman/var/metadata/gradle-7.4.headers
curl: (23) Failed writing received data to disk/application
mv: cannot stat '/home/ubuntu/.sdkman/tmp/gradle-7.4.bin': No such file or directory

System info

~ uname -a
Linux L1002656-01 5.13.0-30-generic #33~20.04.1-Ubuntu SMP Mon Feb 7 14:25:10 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

~ zsh --version
zsh 5.8 (x86_64-ubuntu-linux-gnu)

~ sdk version

SDKMAN 5.13.2

[marc0der]

Hi @Gvald, could I ask you to please check the ownership and permissions of the files and directories in the .sdkman folder? Also, did you perhaps ever run the sdk command under sudo?

[amynbe]

I fixed this by installing the cygwin version of curl. Window's curl must be struggling with cygwin-style paths. I had the same error at sdkman.io install step, I had the Windows version of unzip and it caused an error difficult to understand without debugging the script. Which led me to think about the same issue for curl at the sdk install step, otherwise I would have had to give up, as the sdk install script is harder to debug than the sdkman.io script.

[JeanPalies]

I have the same issue when installing any JDK on Ubuntu 22.04.3 LTS. I checked ownership and permissions in my .sdkman folder, and everything has the same user.

curl: Failed to open /home/jpalies/.sdkman/tmp/java-21-tem.headers.tmp
curl: (23) Failed writing received data to disk/application
grep: /home/jpalies/.sdkman/tmp/java-21-tem.headers.tmp: No such file or directory
Download has failed, aborting!

[marc0der]

Hi @JeanPalies,

It looks like the first line is failing when trying to write the headers file to the tmp folder:

curl: Failed to open /home/jpalies/.sdkman/tmp/java-21-tem.headers.tmp

Can you confirm for me that the tmp directory is present? If it is, can you try to touch that file?

touch /home/jpalies/.sdkman/tmp/java-21-tem.headers.tmp

[JeanPalies]

 09:36:16 
╰─❯ touch /home/jpalies/.sdkman/tmp/java-21-tem.headers.tmp
╰─❯ tree /home/jpalies/.sdkman/tmp/
Permissions Size User    Date Modified  Name
drwxrwxr-x     - jpalies 20 oct.  09:40  /home/jpalies/.sdkman/tmp
.rw-rw-r--   910 jpalies 20 oct.  09:36 ├──  hook_post_java_21-tem.sh
.rw-rw-r--     0 jpalies 20 oct.  09:40 └──  java-21-tem.headers.tmp

The java-21-tem.headers.tmp is there because I retried to install java this morning :). All other attemps are gone because I used sdk flush tmp before retrying.

for the record, I have the issue both in my shell (I use fish) and in bash (I always try with both, as I know fish uses plugins and completions to make it work)

[JeanPalies]

Hi @marc0der do you have any idea about what is going on? Even though it was a fresh install, I'll try to start another ubuntu in a VM and try to install sdkman there.

[marc0der]

Hi @JeanPalies,

I suspect this is due to some shell configuration on your machine. I tried replicating your scenario in a docker container as follows:

$ docker run -it --rm ubuntu
# apt update && apt install -y curl zip unzip
# curl -s https://get.sdkman.io | bash
# source /root/.sdkman/bin/sdkman-init.sh
# sdk install java 21.0.1-tem
# java-21.0.1-tem.headers.tmp

When looking at the results:

root@37d3f10a21a0:/# ls -lah /root/.sdkman/tmp/
total 203M
drwxr-xr-x  3 root root 4.0K Oct 29 14:48 .
drwxr-xr-x 11 root root 4.0K Oct 29 14:41 ..
-rw-r--r--  1 root root  922 Oct 29 14:48 hook_post_java_21.0.1-tem.sh
-rw-r--r--  1 root root 4.6K Oct 29 14:47 java-21.0.1-tem.headers.tmp
-rw-r--r--  1 root root 203M Oct 29 14:48 java-21.0.1-tem.zip
drwxr-xr-x  2 root root 4.0K Oct 29 14:48 out

root@37d3f10a21a0:/# java -version 
openjdk version "21.0.1" 2023-10-17 LTS
OpenJDK Runtime Environment Temurin-21.0.1+12 (build 21.0.1+12-LTS)
OpenJDK 64-Bit Server VM Temurin-21.0.1+12 (build 21.0.1+12-LTS, mixed mode, sharing)

My first thought would be to determine if you have the noclobber shell option set. Please let me know if the problem persists, and I can help you debug it further.

[timastered]

Had same issue due to environment parameter which prevents path conversion (cygwin on windows) i.e. MSYS_NO_PATHCONV was set to 1 When unsetting this variable, the install worked.

Take into account that unsetting this variable will cause other scripts to start failing. You can always set the variable to 1.