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

feature suggestion: implementation of a try/escape clause #5

Closed
nbehrnd opened this issue Sep 15, 2022 · 3 comments
Closed

feature suggestion: implementation of a try/escape clause #5

nbehrnd opened this issue Sep 15, 2022 · 3 comments
Assignees

Comments

@nbehrnd
Copy link
Contributor

nbehrnd commented Sep 15, 2022

Similar to a physical archive, I had to re-use some data of yesterday already stashed by move2archive and intended to clear the space again (now) by move2archvie. While this didn't work for that there already is a file of same name in the current working directory and the archive, there were two other files so far never deposit into the archive:

2022-09-15T17 38 32 -- screenshots

Asking what if: what if move2archive's action would include a try/escape clause to the effect:

  • To prevent accidental lost, files of same name/same hash string in the current working directory and in the archive folder are not moved into the archive. They however
  • allow other files in the same working directory (without match in the archive folder) to be moved into the archive folder.

Maybe to check files to contain the same content based on a hash is safer than a check based on file name if file tags assigned and annotations (appendfilename) of different days differ.

@novoid novoid self-assigned this Sep 16, 2022
@novoid novoid closed this as completed in 2b6bc27 Sep 16, 2022
@novoid
Copy link
Owner

novoid commented Sep 16, 2022

Hi @nbehrnd, please do test the most recent version. I added a check for skipping existing files at the destination. The user needs to handle the clash after she gets notified.

@nbehrnd
Copy link
Contributor Author

nbehrnd commented Sep 20, 2022

@novoid Working with the revised current version (i.e., 063fe06 by Saturday 2022-09-18) indeed nicely provides the sought improved functionality. Merci.

@novoid
Copy link
Owner

novoid commented Sep 20, 2022

:-)

Yes, I was too convinced to have fixed the issue with the small change so that I didn't test it. That was - once again - a reality-check to me.

Thanks for the idea, it will help myself as well although I don't think that I've overwritten data so far. Maybe I archived the same file again, that can be the case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants