Unexpected behavior when specifying same input and output file

[marcobellaccini]

Hi!
Yesterday a programmer pointed out a corner case in pyAesCrypt usage:
marcobellaccini/pyAesCrypt#5
He was wondering whether specifying same input and output file is legit.
I don't think that's a valid use case, so I explicitly prevented the user from doing it.
For the sake of completeness, I've tested the same use case with the Linux command-line version of AESCrypt (v3.13) and I've got this error:

$ aescrypt -o foo.aes -d foo.aes
Enter password: ******
Error: Input file is too short.

after executing the command, foo.aes is deleted too.

Cheers

Marco

[paulej]

While that's true, I don't want to make an effort to prevent it. It might be possible to prevent some instances, it's possible that the same file has different names for to using symbolic links, hard links, etc.

[marcobellaccini]

Hi Paul!
Ok, I understand your point. It has been easy for me to avoid troubles with links using a nice Python standard library function, but, of course, in C everything is harder.

Cheers

Marco

[paulej]

I'll bet a normal link on Linux would fool even the python code. One option that might work is to lock the input file exclusively. But that's got other negative consequences, like background backup processes failing.

[marcobellaccini]

No, it works (I've tested it).
As reported in the "samefile" function documentation, it checks the i-node number.

[paulej]

Very nice. I didn't expect it to be that thorough.

[marcobellaccini]

Yeah, in fact I think the implementation is pretty complex...