-
Notifications
You must be signed in to change notification settings - Fork 38
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
UN_FOLDER_0_DELETE_AFTER not respecting default value if unset #484
Comments
Not a bug; working as designed "delete_after:0s" thus you've disabled delete. https://unpackerr.zip/docs/install/configuration#watch-folders |
What baker meant to say is that you should unmount |
No offence taken @bakerboy448 and thanks @davidnewhall. I've removed the configuration file, but itt seems that unless I explicitly specify something for However, the documentation says that the default is 10m - am I missing something again? As what I was seeing is the intended logic, but there's understandable confusion, could I please suggest clarifying the documentation? Expanding the note next to I know I interpreted it wrong, but just to share that I saw "delete after" as being a "delay" option and therefore disabling this delay meant there wouldn't be one, not that the file wouldn't be deleted at all, but that it'd be deleted immediately. |
Confirmed there is a bug where 10m is not being properly set when the variable is not explicit. |
I can't seem to get DELETE_ORIGINAL to work, unless I'm misunderstanding its functionality. Should the original .zip be deleted once extraction is successful?
docker-compose.yml - I've just set it to normal folder and as a path within config folder on host for testing:
Log showing delete original set to 'true' - note, I've also tried the golift/unpackerr image with the same results:
The result:
The text was updated successfully, but these errors were encountered: