[Bug] When creating a hash file in a child folder, bad relative path

[a-raccoon]

When you right-click on any file in Windows Explorer, select Create Checksum File..., and then save it to a child folder, the relative path is inaccurate and the hash file verification fails because it cannot locate the file.

X:\MyFile.doc
X:\SomeFolder\MyFile.doc.sha256

FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF *\MyFile.doc

should be one of the following

FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF *..\MyFile.doc
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF *X:\MyFile.doc
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF X:\MyFile.doc

[tERyceNzAchE]

I disagree that this is a bug. File paths should be relative to the folder (root) you are in when you create the hash, not some arbitrary folder you decide to save the file in.

An enhancement may be to store absolute paths, but that should not be the default behavior.

[a-raccoon]

I'm not sure what you mean by "The folder (root) you are in when you create the hash". The folder you save the file in absolutely is the "folder you are in" (not root).

That is to say, all paths contained inside of a checksum file must be relative to the location of the checksum file itself. The location that the checksum file is saved in is more important than anything else in the world. The files that you are verifying can be all hither dither and yon, and the paths must reflect that. There's no need for them to be absolute paths unless they are on different drive volumes.

This all works out fine if the checksum file is saved to a parent folder, or a parent parent folder, but not child folders.

[tERyceNzAchE]

When you right-click on a file to run a command, the directory that file is in is the current working directory. All paths should be relative to that. It's no different than if you were to use a command line, the paths would be relative to the folder you are in when you run a command.

I don't know of any hashing software that behaves as you describe. Unless the file was created using a command line utility, run from the folder you are saving the checksum file in.

[a-raccoon]

@tERyceNzAchE if you used HashCheck, then you would know that a Save dialog prompting for filename and location is presented to the user. The current working directory is of no concern or use anywhere in this software. Only the path and filename that is specified by the user from that Common Dialog.

https://github.com/idrassi/HashCheck/blob/master/HashCalc.c#L327

[tERyceNzAchE]

@a-raccoon can you give an example of one GUI hashing app that behaves as you describe?

The current behavior is not a bug, it is the expected behavior when launching a program from a right-click menu. The folder you are in is set as the current working directory, and all paths should be either relative to that directory or absolute paths. Storing absolute paths by default brings a whole host of other issues so having relative paths is preferred.

[a-raccoon]

I'm done talking to you and only wish to address the maintainer of this fork. The code in question is located here and here.

https://github.com/idrassi/HashCheck/blob/master/HashCalc.c#L327

https://github.com/idrassi/HashCheck/blob/master/HashCalc.c#L537

[timea-techgirl]

My issue is similar. The original version works fine. The absolute paths are saved to the checksum file instead of relative paths. This makes the program unable to find the files.
As a workaround, I used notepad++ to delete the absolute path like,
*D:\Data\Games\Game.iso
to
*Game.iso

and now it works fine.