Skip to content
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

Parameter --no-conversion deletes and overwrites files without warning or interaction #27

Closed
gennaios opened this issue Mar 3, 2019 · 5 comments
Labels
critical bug crititcal bug, that has to be fixed in the near future (security or data loss)

Comments

@gennaios
Copy link

gennaios commented Mar 3, 2019

Perhaps there could be more error checking. Sometimes I mistype the command, and by accident overwrite a file. In those cases, the file is overwritten without prompt, there's a warning about the chapter file already existing, and it aborts.

@sandreas
Copy link
Owner

sandreas commented Mar 3, 2019

Sometimes I mistype the command, and by accident overwrite a file.

Mmh this sounds strange. If you do not use the --force flag, nothing should be overwritten or deleted by accident.

Which full command did you execute?

@gennaios
Copy link
Author

gennaios commented Mar 4, 2019

ah yes after verifying, what happens is a bit different. There is a warning as you say with mention of --force. btw the warning text is a bit hard to read (maybe white w/red background or just bold red?). It's when I reuse a command from shell history and forget to change the output name that overwriting of files happens. I then delete the chapters file, and if the output audio file already exists, it is overwritten. Command is:

m4b-tool merge * --skip-cover --no-conversion --output-file="/Users/----/Desktop/temp/01.m4b"

--no-conversion is the important thing for me. Unsure if it's a necessary previous step, or if --skip-cover is needed, though I before run a command to remove covers.

for i in *.m4b ; do ; AtomicParsley "$i" --artwork REMOVE_ALL --overWrite ; done

As such, --no-conversion works for me without fail.

btw, upon successful merge, and it seems even if there's an error (at least sometimes), source files are deleted as with parent folder. Is this supposed to happen? I think a better way, if intended, is to leave source files and have a parameter to remove source files only upon successful processing.

@sandreas
Copy link
Owner

sandreas commented Mar 4, 2019

btw the warning text is a bit hard to read (maybe white w/red background or just bold red?)

For future releases it is planned to rework the output component to be more precise. Unfortunately this is a bit ungrateful work, because the time i need for this cannot be used for new features - but i know that there are some things, that could be improved.

It's when I reuse a command from shell history and forget to change the output name that overwriting of files happens

Ok, if i got this right, you say that running the command

m4b-tool merge * --skip-cover --no-conversion --output-file="/Users/----/Desktop/temp/01.m4b"

twice overwrites the audio file /Users/----/Desktop/temp/01.m4b without --force.

and it seems even if there's an error (at least sometimes), source files are deleted as with parent folder

Oh boy, this could be possible, since before the --no-conversion parameter was introduced, the merged files were temporary and m4b-tool deletes temporary files by default. If you are right, this is a critical issue and could lead to data loss.

I'll check these two things in the next days and try to fix it as soon as possible.

@sandreas sandreas added the critical bug crititcal bug, that has to be fixed in the near future (security or data loss) label Mar 4, 2019
@sandreas sandreas changed the title If *.chapters.txt file already exists, merge aborts without writing chapters Parameter --no-conversion deletes and overwrites files without warning or interaction Mar 4, 2019
sandreas pushed a commit that referenced this issue Mar 4, 2019
@sandreas
Copy link
Owner

sandreas commented Mar 4, 2019

Ok, should be all fixed in latest source code... I'll trigger a build with a new version in the next days...

@gennaios
Copy link
Author

gennaios commented Mar 5, 2019

Thank you. Will test with the next use.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
critical bug crititcal bug, that has to be fixed in the near future (security or data loss)
Projects
None yet
Development

No branches or pull requests

2 participants