`vcs_relative_path` is broken when using blackbox_edit_start

[Remco de Man]

This morning I thought I was going crazy because of a bug in the vcs_relative_path function, introduced as part of a7fd514.

The new abs function, when passed an unencrypted file path, assumes that the unencryped file already exists in order for it to work correctly. This breaks when blackbox_edit_start calls fail_if_not_on_cryptlist "$unencrypted_file", because it results in the following call stack:

• fail_if_not_on_cryptlist "$unencrypted_file"
• is_on_cryptlist "$name" ($name being $unencrypted_file)
• vcs_relative_path "$1" ($1 being $unencrypted_file)
• abs "$1" ($1 being $unencrypted_file)

The abs function splits the path on basename and dirname only if the file in $1 exists. When called from blackbox_edit_start, $1 contains the unencrypted file path. Obviously, the unecrypted file does not exist yet as we are trying to check if the unencrypted file path is on the cryptlist. Only the encrypted file exists at this point.

Before a7fd514, a Python solution was used that did not depend on the existance of any file, which worked correctly. Now the new abs function breaks the correctness of vcs_relative_path. I had to move back to an older commit to work around this bug.

I think it could be fixed by also checking for the existance of $1.gpg in abs, but this might have other unwanted side effects as a result...

[Remco de Man]

Just noticed that the commit I am writing about was reverted earlier as 6c83f60, but was then applied again... Not sure why, just mentioning it 🙂

[Tom Limoncelli]

Dang it! I fail at Git. The change I reverted got re-introduced by... whatever I did wrong.

Anyway... I think I got it right this time. Please take another look.

[Remco de Man]

Yep, with the most recent commit, it works for me. Thank you for solving it.