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. – user414777 Oct 25 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. – Paul_Pedant Oct 25 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 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 at 15:57
  • 4
    If you edit someone's name in your phone contacts, does that person change? – Jörg W Mittag Oct 26 at 19:16

The name of a file is a string in a directory entry, together with a number of other meta data (file type, permissions, ownership, timestamps etc.). 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.

| improve this answer | |
  • 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. – Stéphane Chazelas Oct 25 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

| improve this answer | |
  • 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 at 2:42
  • @jamesqf is it possible to store file name in a file? – Amir reza Riahi Oct 26 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. – Volker Siegel Oct 26 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. – rexkogitans Oct 26 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. – Amir reza Riahi Oct 26 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 file contents 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 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 - 
| improve this answer | |
  • 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 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.

| improve this answer | |
  • 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. – Thorbjørn Ravn Andersen Oct 27 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. – David Conrad Oct 28 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).

| improve this answer | |
  • 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. – Stéphane Chazelas Oct 25 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, – Henrik supports the community Oct 26 at 22:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.