The behaviour you've seen editing your text file is to be expected.

Hard links are not commonly used on Windows. (They're not even that common in Unix - soft links seem to be more usual.) Thus some Windows software might not expect to be dealing with linked files and accidentally end up breaking the link - I'm guessing that's what's happening with your image editor.

Example scenario:

1. You link x.jpeg and y.jpeg.
2. You open y.jpeg in your image editor and make some changes.
3. You click the save button.
4. Internally, your image editor does the following:
   1. Saves the image as y.tmp
   2. Deletes y.jpeg
   3. Renames y.tmp to y.jpeg

Step 4b results in y.jpeg no longer being a link to x.jpeg.

This saving via a temp file is quite common in software that deals with potentially large files. There's a good reason for it - consider what happens if the software crashes part way through the saving process. If it did a straight overwrite of y.jpeg and crashed part way through, all you'd have is a corrupt image. But using the temp file, if it crashes during saving, you've at least still got your original version to go back to.

Anyway, answers to your questions:

1. a.txt/b.txt is the expected result. However, you are misunderstanding what's going on underneath. The files are not being kept in sync. There is only one file! You've just given the one file two different names, so it can be accessed as a.txt or b.txt. Whichever one you edit, you're dealing with the same underlying data on the disk. If you have a 100MB file, and you create a thousand links for it, the data still only uses 100MB of your disk. (Well, maybe 101MB - the filesystem needs to use some space to keep track of file names.)
2. Both - the contents of the file are irrelevant.
3. Hard links only work on the same volume. This is roughly equivalent to Windows' notion of a "drive". It is possible (via RAID for example) to have a drive that spans multiple physical disks; and also possible (via partitions) to have multiple drives on the same physical disk. On Windows, hard links are only supported on NTFS volumes.

(ObPedantry: before anyone points it out, obviously when I say that hard links are not often used, I am ignoring the fact that the "original name" of the file is itself technically a hardlink. And that because directories have hardlinks to their parents and themselves, most directories end up with multiple hard links pointing to them.)

Thank you very much =) I replied to BrowserUk in this thread and I got what I expected now.

Though, your explanation helps me to clear the doubts about the link()'s behavior, which is working as expected as the mechanism of hard links. Suggest to put your explanation into the perldoc, about the edit-saveTemp-del-rename steps as reminder.

Thanks again!

the link() function, as it has not much description on perldoc -f

So, then I googled "perl link", and I found this http://www.tutorialspoint.com/perl/perl_link.htm, which mentions perldoc -f symlink. I realize this does not directly answer any of your questions, but maybe it is of some use.

I edit either x.jpg or y.jpg, they wont sync like a-b.txt did.

This also works with jpgs on my system. (Vista/5.10.1)

So that means the expected result should be "synced" ?
If so, is that a bug ? as the return value is 1. My perl is 5.10.0

It means that if I create a.jpg; link it to b.jpg; then edit it, b.jpg also changes as expected.

I see no bug here.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

The start of some sanity?