Bionus / imgbrd-grabber

Very customizable imageboard/booru downloader with powerful filenaming features.
https://www.bionus.org/imgbrd-grabber/
Apache License 2.0
2.55k stars 216 forks source link

'no source found' error with Grabber_v7.10.1-x86_64.AppImage when running in portable mode if 'sites' directory exists #2936

Closed aoibonzie closed 1 year ago

aoibonzie commented 1 year ago

Bug description

When started in portable mode 'Grabber_v7.10.1-x86_64.AppImage' will produce a 'no source found' error if the 'sites' directory exists.

Steps to reproduce

  1. Download 'Grabber_v7.10.1-x86_64.AppImage' to Desktop on clean Ubuntu 20.04 system with no previous imgbrd-grabber install or use
  2. Run 'Grabber_v7.10.1-x86_64.AppImage' for first time and follow basic initialization flow - 'sites' directory will get created with config for safebooru
  3. Close 'Grabber_v7.10.1-x86_64.AppImage'
  4. Open 'Grabber_v7.10.1-x86_64.AppImage' again and verify that it works, then close it again
  5. cp -r ~/.config/Bionus/Grabber ~/Desktop/
  6. mv ~/Desktop/Grabber_v7.10.1-x86_64.AppImage ~/Desktop/Grabber/
  7. Run ~/Desktop/Grabber/Grabber_v7.10.1-x86_64.AppImage and get 'no source found' error
  8. rm -r ~/Desktop/Grabber/sites/
  9. Run ~/Desktop/Grabber/Grabber_v7.10.1-x86_64.AppImage and 'no source found' error is gone - at least until 'sites' directory gets recreated

Expected behavior

It is expected that 'Grabber_v7.10.1-x86_64.AppImage' would not generate 'no source found' errors when run in portable mode simply because the 'sites' directory exists.

Context

Possibly valuable:

[12:51:20.602][Warning] Javascript 'model.js' file not found for 'Gelbooru (0.2)' in `/home/user/Desktop/Grabber/sites/Gelbooru (0.2)/model.js
[12:51:20.648][Error] JavaScript helper file could not be opened 

System information

Ubuntu 20.04

Thank you for creating and maintaining this software.

Bionus commented 1 year ago

Indeed, portable mode expects a fully portable application, while AppImages should still read from their embedded filesystem. I'll fix that so that AppImages prioritize their own filesystem for reads over the directory they're put in (that they should still use for read overrides and writes).