8000 --cache-path Option Being Ignored? · Issue #1135 · emmercm/igir · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

--cache-path Option Being Ignored? #1135

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
PhasecoreX opened this issue May 21, 2024 · 2 comments · Fixed by #1145
Closed

--cache-path Option Being Ignored? #1135

PhasecoreX opened this issue May 21, 2024 · 2 comments · Fixed by #1145
Assignees
Labels
bug A confirmed issues that needs fixing

Comments

@PhasecoreX
Copy link
Contributor

Paste the command

npx --yes igir@latest move zip test --dat "https://raw.githubusercontent.com/libretro/FBNeo/master/dats/FinalBurn%20Neo%20(ClrMame%20Pro%20XML%2C%20Arcade%20only).dat" --input . --output . --no-bios --no-device --cache-path . -vvv

Describe the bug

I could just be doing something wrong, but when I try to use the new --cache-path option, the trace log says

TRACE: setting the file cache path to '.'

Or

TRACE: setting the file cache path to './cachetest.cache'

But then the cache file still ends up in my home directory instead of where I want it.

Expected behavior

For the cache file to be created where --cache-path points to.

Debug logs

output.log

DAT(s) used

No response

igir version

2.7.0

Node.js version

v22.2.0

Operating system

Arch Linux

Additional context

The super weird part is that if I run the exact same command a second time, it puts the cache file in the working directory (--cache-path .), as I would expect it to.

Also if I give it a name (--cache-path ./cachetest.cache) it will always on first run put a igir.cache file in my home directory, and then a second run it will put a igir.cache in the working directory. Which is to say, it's ignoring the filename I am specifying. But maybe that's expected, not sure.

Actually, I just deleted both cache files (home directory and in my working directory of /home/pcx/Desktop/test) and then ran this command:

npx --yes igir@latest move zip test --dat "https://raw.githubusercontent.com/libretro/FBNeo/master/dats/FinalBurn%20Neo%20(ClrMame%20Pro%20XML%2C%20Arcade%20only).dat" --input . --output . --no-bios --no-device --cache-path /home/pcx/Desktop/cachetest.cache -vvv

First time running it, it makes igir.cache in my home directory, second time it's created in my working directory (???), third time and more it doesn't make any other files. The /home/pcx/Desktop/cachetest.cache is never created. I am very confused on how it made one in my working directory when I never specified it in the command...

Any help would be appreciated!

@PhasecoreX PhasecoreX added the potential-bug A potential issue that needs confirmation and/or triage label May 21, 2024
@emmercm emmercm self-assigned this May 22, 2024
@emmercm emmercm added bug A confirmed issues that needs fixing and removed potential-bug A potential issue that needs confirmation and/or triage labels May 22, 2024
@emmercm
Copy link
Owner
emmercm commented May 22, 2024

Definitely a bug. It's still writing zero-byte cache files to the old directories even if a custom path is provided. It's how I was testing what path is writable (#1060).

Separately, the path provided should be a file rather than a directory, so . doesn't make sense, but I can add detection for that.

Copy link
github-actions bot commented Jul 1, 2024

🔒 Inactive issue lock

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

Comment generated by the GitHub Lock Issues workflow.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jul 1, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug A confirmed issues that needs fixing
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants
0