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?

  • 38
    " file name is not a part of file data?" exactly, it's not part of the file. just like an entry in an address book is neither part of the house, nor of the person who lives there.
    – user313992
    Oct 25, 2020 at 16:48
  • 3
    When you download a file from a repository, you probably don't even know its actual original name, so you could never check its sha256 to verify it was received correctly. So just as well the checksum is independent of the name. Oct 25, 2020 at 21:35
  • 8
    try renaming some text file and compare the content before and after renaming. Do you see any changes? Absolutely no
    – phuclv
    Oct 26, 2020 at 1:54
  • 1
    Whatabout in something like ZFS, where checksums are inherit in the actual file, would the checksum change there if the file is renamed? Doesn't the answer to this question depends on which layer in the file system you are performing the checksum on?
    – d-b
    Oct 26, 2020 at 15:57
  • 4
    If you edit someone's name in your phone contacts, does that person change? Oct 26, 2020 at 19:16

5 Answers 5


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.

  • 8
    The type/permissions/ownership/timestamp, etc. belong with the file (the inode) not the entries in any directory that refer to it. The directory is a table of 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. 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.

If you want to checksum/hash both then some thing like this will work

(Probably not a good idea)

echo "$filename" | xargs -n1 -I{} bash -c 'echo "$1"; cat "$1"' x {} | shasum

  • 3
    If you stored the file name in the file (instead of in the directory), then to do something like a simple ls would require opening & reading every file.
    – jamesqf
    Oct 26, 2020 at 2:42
  • @jamesqf is it possible to store file name in a file? Oct 26, 2020 at 8:43
  • 10
    A file can have multiple different names at the same time. A name is technically a hard link. You could create more hard links using 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. Oct 26, 2020 at 9:06
  • @AmirrezaRiahi Yes, you can, e.g. echo filename > filename. But this does not have any meaning to generic tools or libc functions that deal with files. Oct 26, 2020 at 9:27
  • @rexkogitans It's so meaningless :) I thought there is a way to link the name of file to file's data. In this way we can not change file's name without changing checksum. Oct 26, 2020 at 9:31

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
for f in "$@"; do
        (printf "%s\0" "$f" ; cat "$f") | sha256sum - 
  • Yes, this is by far the best answer. The question says 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.
    – OJFord
    Oct 28, 2020 at 18:22

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.

  • nameless files are typically files opened by a program, and then deleted. The space is not reclaimed until the program closes the file again. This is often a problem with file systems running full because you cannot just delete the big file being written and expect the space to be available if the program is not killed or told to close the file. Oct 27, 2020 at 23:28
  • Note that with traditional UNIX filesystems the same file can be in the same directory more than once, with different names, too. Oct 28, 2020 at 17:19

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).

  • 2
    No, it's not data about the file, it's part of the contents of a directory or of a number of directories as a file can be referenced (even several times) in any number of directories. Oct 25, 2020 at 18:21
  • 3
    I think that's a matter of definitions. I see no problem in the data about the file including multiple names, and being spread across multiple locations, Oct 26, 2020 at 22:21

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .