It needs to check and handle all libc return values instead of assuming I/O succeeds.
I would make BUF_SIZE larger than 4096.
If it's writing files with the name being the sha256 of the original file name and not using the key then that's a problem because it essentially leaks file names.
If this is a real thing, it needs a lot of work. Lots of failure modes, errors that are not being handled, sometimes exceptions, sometimes swallowing and printing to stdout, very inconsistent style, mixing and matching all kinds of C and C++ conventions, the fallback hard coded path of your specific user name + deep path ...
I would recommend not using this for any data that you actually care about.
It needs to check and handle all libc return values instead of assuming I/O succeeds.
I would make BUF_SIZE larger than 4096.
If it's writing files with the name being the sha256 of the original file name and not using the key then that's a problem because it essentially leaks file names.
If this is a learning exercise, cool!
If this is a real thing, it needs a lot of work. Lots of failure modes, errors that are not being handled, sometimes exceptions, sometimes swallowing and printing to stdout, very inconsistent style, mixing and matching all kinds of C and C++ conventions, the fallback hard coded path of your specific user name + deep path ...
I would recommend not using this for any data that you actually care about.
> When loading a key, it looks for meta.sec on the detected USB drive.
I would not trust a thumbdrive with a key that wasn't backed up elsewhere. Those things are unreliable on a good day, and I don't like data loss.
Why?
What does this solve the that the other far more mature tools don’t?
https://www.cryfs.org/
For example, has been around for decades. Is widely supported and battle tested.