Export has scary overwrite behaviour.

[will-ca]

Describe the bug

• Apparently -e always saves to the user home? So if you cd to a subdirectory hoping to contain everything, then it still writes to your top-level user home.
• When the output file $HOME/<PROFILENAME>.knsv already exists, then Konsave just straight-up overwrites it.
• When the seemingly unrelated path $HOME/<PROFILENAME>.zip exists, then Konsave also just straight-up overwrites (and then removes) that too.
• Konsave does not give you the opportunity to specify output filename either.
• So the default behaviour of konsave -e is apparently to immediately overwrite two seemingly unrelated filepaths that the user didn't specify, in a location that the user also didn't specify, which also happens to be the top-level user home.
• When the output already exists and is a directory, Konsave creates the file <PROFILENAME>.zip inside it instead.
• When the output already exists and <PROFILENAME>.zip also already exists in it, then Konsave finally fails instead of overwriting (but I think not deliberately?).
• If the profile name includes capitals, the "Successfully exported" message printed at the end switches them to lower-case instead, meaning the path reported to the user is wrong.

To reproduce
Use the konsave -e feature.

Expected behavior
Tools should never overwrite user data unless explicitly instructed to do so.

E.G.:

• Do mktemp (Python: probably import tempfile) for the scratch file instead of putting it next to the output.
• Write to os.getcwd() instead of user home.
• Check for existing file before rename, and either fail or prompt (possibly depending on -f flag) instead of overwriting.
• Possibly allow/require user to explicitly specify output filename/path.

[Prayag2]

This actually sounds scary now that I think about it. I'll definitely consider all of your suggestions to improve Konsave but unfortunately, I have an exam that I have to prepare for (and it's a tough exam). I'll make sure to fix this issue as soon as I get time after my exams. Thanks for reporting :)

[gadgieOps]

Hi @Prayag2 ,

I've been finding great use for this project, thank you for making the code publicly available. I share @will-ca 's concerns. I have made some changes in a fork and will submit a pull request for you to review. I'll explain the changes in the PR, they're not fool proof, but have marked improvements on handling of exports.

[Prayag2]

Fixed in #72 by @gadgieOps :)