#missing file error from mod.rs

1 messages · Page 1 of 1 (latest)

teal knoll
#

Very likely the result of the frequent killing/restarting of opendeck I'm doing as part of figuring out how to write a plugin, but I now have things in a state where attempting to start opendeck fails with:

[2026-01-12][00:06:06][panic][ERROR] thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: "No such file or directory" }': src/plugins/mod.rs:433```

even `apt remove` / `apt install` doesn't correct the issue. Any hints what this missing file that `mod.rs` is looking for or how I can get it back?
#

figured it out - looks like symlinks in ~/.config/opendeck/plugins cannot use relative paths

cursive glade
#

What Version of OpenDeck do you use?

#

What is your Distro?

#

How did you install OpenDeck?

teal knoll
# 
Listing... Done
opendeck/now 2.8.0 amd64 [installed,local]
$ lsb_release -a
No LSB modules are available.
Distributor ID:    Ubuntu
Description:    Ubuntu 24.04.3 LTS
Release:    24.04
Codename:    noble```
teal knoll
#

Even with absolute paths in the symlink I still see issues where the UI doesn't seem to find the icons correctly.

cursive glade
#

Thats something @summer tide needs to have a look at.

summer tide
teal knoll
#

Is the relative path returned by read_link interpreted relative to the process's current working directory or the location of the symlink?

#

And in most OS's & programming languages there's no need to read the contents of a symlink when opening a file. The filesystem and/or language libraries will automatically follow them for you. But not sure if things are different in rust and/or Windows?

summer tide
summer tide
teal knoll
#

I'm using an absolute path & it's mostly working. It appears to miss some icons, but the actions seem to work fine.

can't see a relative path ever being unambiguous
Symlinks to relative targets should always be interpreted relative to the location of the symlink. I don't think there's any ambiguity?

#

the call to metadata->is_dir on the line below won't report that the symlink is a directory, so that's why it's resolved manually
Would it be simpler to check if entry.path + "/manifest.json" is a file? That would shift responsibility for following the symlink to the OS.

summer tide
summer tide