As far as I know changing even a bit of a file, will change the whole checksum result, but when I change a file's name this does not affect its checksum (I've tried SHA-1, SHA-256 and MD5).
Why? file name is not a part of file data? does it depend on file system?
The name of a file is a string in a directory entry, and a number of other meta data (file type, permissions, ownership, timestamps etc.) is stored in the inode. The filename is therefore not part of what constitutes the actual data of the file. In fact, a single file may have any number of names (hard links) in the filesystem, and may additionally be accessible through any number of arbitrarily named symbolic links.
Since the filename is not part of the file's data, it will not be included automatically when you calculate e.g. the MD5 checksum with md5 or md5sum or some similar utility.
Changing the file's name (or ownership or timestamps or permission etc.) or accessing it via one of its other names or symbolic links, if it has any, will therefore not have any effect on the file's MD5 checksum.
name <-> inode entries. These days the type of files is often copied to the directory entry as that's used to speed up look-ups, but generally not the rest of the file's metadata. Also note that there can be any number of entries for the same single file in any number of directories. Duplicating all that information in all directories would be a waste.
Commented
Oct 25, 2020 at 18:19
Yes as you said "file name is not a part of file data"
The file name can not be stored in the file. If it were then it would change the file. However it could be valid to check-sum the filename, other meta data, and file data, but this is usually a bad idea.
The file-name is part of its containing directory. Not part of the file.
(Probably not a good idea)
echo "$filename" | xargs -n1 -I{} bash -c 'echo "$1"; cat "$1"' x {} | shasum
ln, as long as it is on the same file system. If you add a second hard link, it has two names, both are equally real.
Commented
Oct 26, 2020 at 9:06
echo filename > filename. But this does not have any meaning to generic tools or libc functions that deal with files.
Commented
Oct 26, 2020 at 9:27
when I change a file's name this does not affect its checksum (I've tried SHA-1, SHA-256 and MD5).
Well, this is somewhat a false connection. SHA-1, SHA-256 and MD5 don't calculate hashes of files or file names, they calculate hashes of bit streams. So, the result you get depends entirely on what you choose to give as the input, and you didn't show that.
Now, you perhaps used the sha1sum, sha256sum and md5sum utilities, and indeed they only include the contents of the given file in the data to be hashed. Not the file name, not the permission bits, owner information, timestamps or other metadata.
But it doesn't have to be done like that. Here's the SHA-256 hashes of two files and their names:
$ echo hello > a.txt; cp a.txt b.txt
$ ./checksum.sh a.txt b.txt
aed49f7730ca0736fe1a021375d1ca9b509a4e72910b422578df8b4b1930aeca -
bad46702033923726add35ef8d97570f1aa40d93dad1d6ba63e7b051a34b9efc -
The script simply prepends the file names to the hashed data. Another application could include metadata in the hash input along with the file contents, or include hashes that only cover part of the data.
Obviously, including the file name has the disadvantage that even the very same file can be referenced to by different names and can hence have numerous distinct hashes:
/tmp/test$ ./checksum.sh a.txt ./a.txt /tmp/test/a.txt
aed49f7730ca0736fe1a021375d1ca9b509a4e72910b422578df8b4b1930aeca -
85ec58226886f4f853212b2d21bb2fb72447813ac13a59e9376b2e0c02074839 -
25c1c072481131e07c3fc20d16109472872233f658f4df3c4982fb195a048b96 -
Adding timestamps, owners and such to the equation would almost guarantee the hashes being different after the file was copied to another system, making the usefulness of the hash rather questionable. Even the file name might get lost or changed.
If you want to include the metadata in the hash, it's probably easiest to put the file(s) in a tar archive, or some other container that stores the metadata you find useful, and hash and copy that. After extracting the file (contents) from the archive, the metadata on the file system might be different, but you could still verify the archive the file came from.
The script above is:
$ cat checksum.sh
#!/bin/bash
for f in "$@"; do
(printf "%s\0" "$f" ; cat "$f") | sha256sum -
done
SHA-256 & MD5, but means sha256sum & md5sum (or similar). Whether or not the file name is part of the result is a detail of those tools and what they are trying to achieve; not of the hashing algorithm.
Why? file name is not a part of file data? does it depend on file system?
A file's name is a property of its attachment to a directory, not a property of the file itself. With traditional UNIX filesystems, the same file can be attached to more than one directory, with a different name in each. A file doesn't even have to have a name -- if it's not attached to any directories, it is nameless.
However, if it was desirable, programs that compute the hash of a file could take into account the name by which they accessed the file. This just wouldn't be a very useful thing to do. It wouldn't make sense with the way people typically use hashes.
For example, "foo.bak" would never have the same hash as "foo", even if it was a backup of it. And identical files with different names couldn't be detected for de-duplication purposes.
As you said yourself and as has now been highlighted in two answers: The file's name is not part of the data, it's data about the file (also known as meta data).
This is actually useable, because this way you can detect duplicates even when they have different names. Programs like fdupes and jdupes searches for duplicates and actually use checksums to speed up the process (a checksum is what is known as an invariant).
