[bug] Application Updater Process Can't Restart - Tauri API error: Cross-device link (os error 18)

[cosi-conda]

Describe the bug

I'm using the application updater with a static JSON file.

{ 
  "version": "v0.4.0",
  "platforms": { 
    "darwin-x86_64": {
      "signature": "something", 
      "url": "https://something.com/macos/AppName.app.tar.gz" 
    }, 
    "darwin-aarch64": { 
      "signature": "something", 
      "url": "https://something.com/macos/AppName.app.tar.gz" 
    }
  } 
}

The app uses the built in dialog to prompt to install and restart the application. The updater status reaches "DONE" in dev mode:

Downloaded 16384 of Some(7682688)
Downloaded 16384 of Some(7682688)
Downloaded 14469 of Some(7682688)
Update has been downloaded!
App has been updated

After this, if I confirm that I would like to restart the application, I get the following error in the terminal, and the update is never applied:

thread ‘tokio-runtime-worker’ panicked at ‘application failed to start: Os { code: 2, kind: NotFound, message: “No such file or directory” }

Which points to this function in the tauri api/process.rs:

pub fn restart(env: &Env) {
  use std::process::{exit, Command};
  
  if let Ok(path) = current_binary(env) {
    Command::new(path)
      .args(&env.args)
      .spawn()
      .expect("application failed to start");
  }

  exit(0);
}

I tried to offload the updater functionality to the JavaScript side to see if I could get more information and built the app. Logging errors to the console, I also saw this error when built with an updater status of "DOWNLOADED" and then "ERROR":

Tauri API error: Cross-device link (os error 18) 

How do I get the restart and update functionality to be applied?

Reproduction

1. Set tauri.conf.json to have an active updater with appropriate endpoints; Build the app with appropriate environment variables as noted in the documentation.
2. Run the application locally and it will get the static JSON file containing version and platform information for the update (at this point the app prompts to update).
3. Confirm you would like to update.
4. Confirm to restart the application (this triggers the error).

Expected behavior

I expect the application to restart successfully and apply the update.

Platform and versions

MacOS Monterey
version 12.3

> tauri info

Environment
  › OS: Mac OS 12.3.0 X64
  › Node.js: 18.12.1
  › npm: 8.19.2
  › pnpm: Not installed!
  › yarn: 1.22.19
  › rustup: 1.25.1
  › rustc: 1.65.0
  › cargo: 1.65.0
  › Rust toolchain: stable-aarch64-apple-darwin 

Packages
  › @tauri-apps/cli [NPM]: 1.2.3
  › @tauri-apps/api [NPM]: 1.2.0
  › tauri [RUST]: 1.2.1,
  › tauri-build [RUST]: 1.2.1,
  › tao [RUST]: 0.15.6,
  › wry [RUST]: 0.22.5,

App
  › framework: React
  › bundler: Vite

App directory structure
  ├─ ui
  ├─ tauri
  ├─ node_modules
  ├─ tests
  ├─ .github
  ├─ .git

Stack trace

__pthread_deallocate
thread 'tokio-runtime-worker' panicked at 'application failed to start: Os { code: 2, kind: NotFound, message: "No such file or directory" }'

Additional context

I saw this issue here regarding setting a tmp dir for Linux, so maybe it's related. However, I'm using Mac for now.

Also, the build process generates a tar.gz called <app_name>.app.tar.gz, detailed here

However this line of code in the core.rs indicates that the tar.gz MUST have the arch, even though tauri only generates the .dmg with the version and the arch, and not the tar.gz:

tauri/core/tauri/src/updater/core.rs

Line 832 in 076e1a8

// ├── [AppName]_[version]_x64.app.tar.gz # GZ generated by tauri-bundler

// MacOS
// ### Expected structure:
// ├── [AppName]_[version]_x64.app.tar.gz       # GZ generated by tauri-bundler
// │   └──[AppName].app                         # Main application
// │      └── Contents                          # Application contents...

Could this be related to by it's giving a Not Found error?

The logs show that it successfully got the tar.gz:

[2023-06-08][20:59:16][attohttpc][DEBUG] GET /<updater>.json HTTP/1.1
[2023-06-08][20:59:16][attohttpc][DEBUG] creating a length body reader
[2023-06-08][20:59:16][attohttpc][DEBUG] creating plain reader
[2023-06-08][20:59:16][attohttpc][DEBUG] status code 200
[2023-06-08][20:59:16][attohttpc][DEBUG] trying to connect to 
[2023-06-08][20:59:16][attohttpc][DEBUG] trying to connect to
[2023-06-08][20:59:16][attohttpc][DEBUG] successfully connected to , took 17ms
[2023-06-08][20:59:16][attohttpc][DEBUG] GET /macos/AppName.app.tar.gz HTTP/1.1
[2023-06-08][20:59:16][attohttpc][DEBUG] creating a length body reader
[2023-06-08][20:59:16][attohttpc][DEBUG] creating plain reader
[2023-06-08][20:59:16][attohttpc][DEBUG] status code 200

[cosi-conda]

I think I finally found the cause. It looks like the macos bundler doesn't include the version and arch in the tar.gz on build:

tauri/tooling/bundler/src/bundle/updater_bundle.rs

Line 89 in 076e1a8

let osx_archived = format!("{}.tar.gz", source_path.display());

but the updater expects the version and arch with the named tar.gz file:

tauri/core/tauri/src/updater/core.rs

Line 832 in 076e1a8

// ├── [AppName]_[version]_x64.app.tar.gz # GZ generated by tauri-bundler

I’m a bit confused about that because the docs here say it should just generate appname.app.tar.gz from the build, but the static json file shows the target in the url, even though we already specify the platform and the arch in the json structure.
https://tauri.app/v1/guides/distribution/updater/#static-json-file

[FabianLars]

Thanks for looking into it! I highly doubt that the name is the issue though, the updater shouldn't actually care/know about it. Also tauri-action which is pretty widely used, changes the default name and no issues were reported about it yet.

No idea about the cross-device link error, but the No such file or directory error most often means you're not running an installed app (like just the binary in target/ or tauri dev), could that be the case here too?

[cosi-conda]

@FabianLars Thank you for getting back to me! I realized I get NotFound when it's in dev, but I still get the cross link error with the installed app. Manually changing the tar.gz name to have the version and arch did fix the problem, but I'm not sure the best solution for an installed / prod application?

Do you have an example of the tauri-action updating the updater name? Thank you!

[FabianLars]

Do you have an example of the tauri-action updating the updater name?

It automatically adds the arch here so that the x64 and arm artifacts don't overwrite each other. -> If you use the action for your own project and need it to rename the assets to include the version then you'll have to use a custom upload action until tauri-apps/tauri-action#215 lands.

Also i just checked again, and i've seen both, the .gz without arch/version and the one with just the app name, working fine so i'm really confused what's going on here 😅

P.S. Did you ever try updating the Tauri packages to the latest versions? (though i'm fairly sure there are no relevant changes but who knows)

[cosi-conda]

@FabianLars If you don't use a tauri-action and just use the tauri build, I think that's where we might see the discrepancy?

I did not update the packages, but I'm thinking it might have breaking changes if it's on v2 right now.

[FabianLars]

If you don't use a tauri-action and just use the tauri build, I think that's where we might see the discrepancy?

Like i said, i saw both working somewhat recently. And the action didn't include the arch until fairly recently (v0.4) too. I just checked again and the updater indeed doesn't actually see the name of the tar, afaik it extracts it directly from the download without saving it to disk. That said, i wonder if this somehow could be a similar problem to 4500 since its fix was only applied to Linux (though i don't see how a different package name would affect that)
-> On that note, do you use multiple disks or something?

Edit: I should probably stop talking at this point since i don't have access to a macOS system to actually look into it...

I did not update the packages, but I'm thinking it might have breaking changes if it's on v2 right now.

I'm only talking about 1.3, there shouldn't be breaking changes between 1.2 and 1.3. v2 is still highly unstable (alpha name checks out)

[ultamatt]

Good/Bad news. I'm also seeing this error in a similar situation. Just sorted out how to get files served to my updater (dev code), it downloads fine and then can't restart. Same exact err

thread 'tokio-runtime-worker' panicked at 'application failed to start: Os { code: 2, kind: NotFound, message: "No such file or directory" }', /Users/ultamatt/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tauri-1.5.1/src/api/process.rs:88:8

EDIT: I went ahead and built my application and it works on the built version of it, but not on the dev version. 🤷

[aramrw]

It only works in production 🤷🏼‍♂️