35

For example, I have a file myold_file. Then I use ln to create a hard link as mylink:

ln myold_file mylink

Then, even by using ls -a, I cannot tell which is the old one.

Is there anyway to tell?

Braiam
  • 35,991
BufBills
  • 3,095
  • 2
    Counterquestion: If you do ls > a; ln a b; rm a; ln b c, which one is "more original" than the other? a is gone, you are left with b and c... – glglgl Apr 02 '14 at 05:38
  • 2
    What are you trying to achieve? What are you trying to achieve? There is no "original" as such. A file is an inode containing meta data and a collection of blocks containing data. A directory can contain a link to the file, and this link is the file name and the inode number. You can create any number of links to a file. Files may never have less than one link. – Johan Apr 02 '14 at 07:29
  • For a detailed explanation of the accepted answer of this question: See the accepted answer of that question. – Utku Oct 05 '15 at 14:51

6 Answers6

101

You can't, because they are literally the same file, only reached by different paths. The first one has no special status.

Jenny D
  • 13,172
  • 4
    This is clearly the right answer: the OP's question is based on a misunderstanding. – Daniel Earwicker Mar 31 '14 at 09:33
  • @JennyD One small correction to something that you have, two times, incorrectly stated. The hard links, in this case, they do indeed point to the same file. They are not the same file. They're two different entries in the filesystem pointing to the same physical location (the file). In that part, and that part only, Hauke Laging is correct and you're wrong. As for the rest of the answer, you're absolutely correct. – Adi Mar 31 '14 at 11:42
  • @Adnan - "They're two different entries in the filesystem pointing to the same physical location (the file)". When you say "(the file)", to which file are you referring? – Daniel Earwicker Mar 31 '14 at 12:42
  • 9
    @Adnan Actually, no: the two hard links are the same file. They're different directory entries. Jenny D's terminology is correct. – Gilles 'SO- stop being evil' Mar 31 '14 at 12:43
  • It depends on whether you use "link" as in "file containing a pointer to another file" - in which case my terminology is correct - or whether you use "link" as in "file system pointer to inode" - in which case @Adnan's is. – Jenny D Mar 31 '14 at 12:56
  • 1
    @Gilles I don't see how it can be correct. Two hard links aren't two files; hard links aren't files. They point, hence link, to the same file (which is the physical location on the disk). Saying that "two hard links are literally the same file" is wrong. – Adi Mar 31 '14 at 12:56
  • 1
    @JennyD And that's pretty much the only way I heard "hard link" being used; a filesystem pointer to an inode. Well, I guess we're all wrong and right. I will cease arguing this as it's pointless. You're answer seems correct to me, you have a +1 from me, and I'll leave it at that. – Adi Mar 31 '14 at 12:58
  • 6
    Saying that a hard link "is" a file is comparing things of different categories, which is technically incorrect. But given that we generally say, ".bashrc is a file containing..." when we mean, "the relative path .bashrc refers to a file containing...", this is a common conflation of categories and we should understand that whenever one refers to a path or a directory entry "being" a file, we mean the file to which it refers. With that understanding, two hard links can "be" the same file. Rejecting that convention in favour of formal language, they can't. Both stances have their place :-) – Steve Jessop Apr 01 '14 at 09:14
  • 1
    @SteveJessop - https://www.youtube.com/watch?v=j4XT-l-_3y0 – Daniel Earwicker Apr 01 '14 at 13:46
16

There is no direct, clean (reliable) way to do that. But under appropriate circumstances this can be possible (or at least probable). The problem is that there are two hard links but just one file. Change, modification and (maybe) creation time are stored for files (inodes) only but not for directory entries (the hard links). Thus the information you want can be taken from secondary effects only which can be easily destroyed by operations which are not related to the file. And you cannot even see whether it has been destroyed. You can only know that from the operational circumstances if you are precisely aware of them.

The creation of a hard link is a write operation to the directory which contains the link. Thus it updates the directory's mtime. So if

  1. the links are in different directories

  2. and you know that none of these directories has been changed (file added, deleted, renamed or file metadata change) after the second hard link has been created then you can simply compare the mtimes of the directories.

Special case: If one of the directories has an mtime before the file's (inode's) mtime and you can be reasonably sure that the file has not been written later than a short moment after its creation then this directory's link is the older one.

If the links are in the same directory (which seems to be the case in your question) then it gets worse. Then you can use

ls -lU

in order to get an impression of the order in which the entries have been created. That need not be the correct order as entries may be deleted so that new entries are made in the middle of the directory list. And as Gilles pointed out it doesn't work at all with newer filesystems.

Hauke Laging
  • 90,279
  • 2
    No mention of selinux, audit trails, or spying on the filesystem journal??? smirk Without an audit trail, there's no way to know -- anything else is a calculated guess – Ricky Mar 31 '14 at 05:57
  • There's no direct clean way to do what? There's only one file - how it can it be anything but the original? – mikeserv Mar 31 '14 at 08:17
  • @mikeserv But that is not the question. What is your point? – Hauke Laging Mar 31 '14 at 09:30
  • How to tell which file is original is the question - and the answer is very simple - the file is original. There is but one file. – mikeserv Mar 31 '14 at 09:41
  • 1
    @mikeserv If you want to teach others this way then you should at least learn to quote correctly. It does not say "which file" in the question. And even if it did then this would be just a wording problem and throwing some brain at understanding the question would easily reveal what it is really about. – Hauke Laging Mar 31 '14 at 09:48
  • How to tell which file is original if hard link is created – mikeserv Mar 31 '14 at 09:58
  • My brain's been beaten enough - I prefer to gently lob it. – mikeserv Mar 31 '14 at 09:59
  • 4
    The directory mtime trick will work if the circumstances are right (which is rare). However, the way you're presenting it, you'll sometimes come to the opposite conclusion. The directory mtime is only a worthwhile indication if it's equal to the file's ctime. But the ls -lU trick won't work on modern filesystems (ext4, btrfs, zfs), there entries don't show up in creation order at all. – Gilles 'SO- stop being evil' Mar 31 '14 at 12:42
  • 2
    @mikeserv - the OP's question is based on a misunderstanding. If they did rm myold_file then mylink would still exist and work perfectly, as it is an equally good entry referring to the same underlying inode. Only when both have been deleted can the system discard the inode. Once hard linking has been used to create two file system entries referring to the same file, they are equivalent. (Note that "file" here means "an inode that holds the data for a file, as opposed to a directory). See: http://en.wikipedia.org/wiki/Inode – Daniel Earwicker Mar 31 '14 at 12:47
  • @DanielEarwicker - ok, i get that, of course, i stated it above. But i dont get what the difficulty is - why would you care how old a link is - either it is or isnt there and thats all that matters. Mtime is for tracking modification - it has no relevance to any other file than the original, and there only ever was one file. So what are we trying to find out in the first place? – mikeserv Mar 31 '14 at 14:47
  • 1
    -1 because, although the info about how the directory changes in some file systems when updating the tables, this answer fails to clear up the miss-understanding present in the question that "original file" is not a property in the case of multiple hardlinks to a single inode. In that sense while is in anecdotally interesting it is not what most people landing on this question should learn about the fundamental concept of hardlinks. This issue is not a lack of a "direct clean way to do it", the issue is that there is no "it" in the first place. – Caleb Apr 02 '14 at 10:34
  • @HaukeLaging - there is no old file. There is one file. – mikeserv Apr 02 '14 at 13:05
  • @mikeserv You guess you have to explain the basic technical situation to me? That's ridiculous. – Hauke Laging Apr 02 '14 at 13:13
  • @HaukeLaging - What happened to that comment you just made? And what's so special about you? – mikeserv Apr 02 '14 at 13:17
  • @mikeserv The comment was deleted because it referred to the question text only. I finally noticed the headline. "Special" about me is that noone who has not understood the concept of hard links would have written an answer like mine. And where are the 10K users who have not understood that? Let alone how crazy the assumption is that I was not aware of that after the discussion of that other answer which I started and still needed such most simple clarification. – Hauke Laging Apr 02 '14 at 13:26
  • 1
    But you just said you weren't aware of it - "I finally noticed the headline..." Anyway, I don't know where anybody is, and I don't really care to look. I don't mean any harm here, man, and I don't mean any insult - I come here to learn and I value the notion of accurate answers. It seems to me that if I had posted an answer like the above - and I certainly might have, I screw up a lot - I would have deleted it as soon as I knew. So, I'm sorry to harp on the mistake man, but can you please fix it? – mikeserv Apr 02 '14 at 13:46
  • @hauke The issue here is not having to explain to you the technical situation --I have no concerns that you don't have a general grasp of things-- the issue is that you skipped explaining the technical situation to the visitors here on an issue they are likely confused on. If they got here by searching (or just read the title) they probably need the nature of hard links explained. – Caleb Apr 02 '14 at 21:29
10

If you rely on the last modification time of the directories and you don't have knowledge of how and when those directories are changed, relying on mtime is going to lead you to be wrong some percentage of the time. The issue here is that the file is represented in the filesystem by an inode, not by a directory entry. The directory entry (filename) points to the inode, not the file.

I think I'd be doing some navel gazing about why I need to know which directory entry is older and how to avoid needing to know that.

Melinda
  • 211
8

I think this question is (quite reasonably) misguided as to what a hard link really is. I think however the most correct direct answer is 'They both are'.

Unix file systems normally store actual file contents and data in i-nodes, these do not have a path whatsoever, paths then have a many to one relationship to these i-nodes. Take as an analogy a person who goes by two names, Bob and Joe. One could not say that Bob is older than Joe or vice versa, they are just names for the same person.

If you want to retain the concept of an 'original' file and a new one you are likely looking for a symbolic link instead, these are more of an alias, just an instruction to the OS that it should operations to one path as if they were to another without changing the file structure underneath. (you can make these with "ln -s file link".

Rui F Ribeiro
  • 56,709
  • 26
  • 150
  • 232
Vality
  • 489
  • You know, Bob/Joe can get really sensitive about his age... The hard/soft link comparison is a good one - especially when you consider that a hard-link will just get an entry added into a directory file - an already existing inode - but a soft-link is a file in its own right, and is thus assigned its very own inode. Still, in both cases, the modification time is only relevant for the linked file, as the only modifications that can be done to a link of any significance would just be creation/deletion. – mikeserv Apr 02 '14 at 15:59
2

The crux of the answer given by several others above is that the every file name is a hard link to a file. There is no real original, just possibly a first one.

Think of a directory as a table that lists file names and inode-numbers.

Every hard link, including the first one, is an entry in a directory which assigns a "file name" to the inode number, so that you can access the file by that name.

The file is a collection of blocks on disk, managed and tracked by meta data stored in an inode. A file have one inode number.

Accessing a file's data via the file name is a three step process: The file name is looked up in the directory to obtain the inode number. The inode is then referred to to find the relevant disk block (or blocks) containing the data. Then finally those blocks are read/written.

So the take-home from all that is basically this: There is absolutely no difference between accessing file contents using the first ("original") or any subsequently created hard links.

Johan
  • 4,148
0

If you foresee that you will need to differentiate between the earlier created (original) file and the one created by ln - you may do that when you create the link... by prefixing the name with an indicator, such as "myln".

Paul Krauss
  • 1