ntfs hard links not working

[hopla]

I can not seem to create hard links on ntfs partitions (either on internal or external hd).

Repeat with:

X@X:/media/sda5 % ls -la A B
ls: cannot access A: No such file or directory
ls: cannot access B: No such file or directory
X@X:/media/sda5 % echo 'file A' > A
X@X:/media/sda5 % cat A
file A
X@X:/media/sda5 % cp -al A B
X@X:/media/sda5 % cat A
file A
X@X:/media/sda5 % cat B
file A
X@X:/media/sda5 % echo 'file B' > B

Expected results:

X@X:/media/sda5 % cat A B
file B
file B

Actual results:

X@X:/media/sda5 % cat A B
file A
file B

Mount status (to prove this is an ntfs partition and to show it's mount options):

X@X:~ % mount | grep /media/sda5
/dev/sda5 on /media/sda5 type fuseblk (rw,nosuid,nodev,allow_other,default_permissions,blksize=4096)

I'm running Ubuntu 8.10

[hopla (hopla)]

I would be happy already if anyone could just confirm this...

NTFS and NTFS-3G should support hardlinks...

[Scott James Remnant (Canonical) (canonical-scott)]

On Fri, 2009-03-06 at 10:30 +0000, hopla wrote:

> NTFS and NTFS-3G should support hardlinks...
>
This is not entirely clear.

Scott
--
Scott James Remnant
<email address hidden>

[hopla (hopla)]

Is my statement not clear or is it not exactly known if NTFS and NTFS-3G support hard links?

I hope this clarifies it... man ntfs-3g says:

"ntfs-3g is an NTFS driver, which can create, remove, rename, move
files, directories, hard links, and streams; ..."

So I expect that it actually does what it says and that it is somehow broken on Ubuntu (as demonstrated above). Unless the above demonstration only fails on my system and I somehow messed something up. However unlikely it is that it would only fail on my system...

So, could you (or anyone else reading this) at least please confirm or deny the above erroneous behavior regarding hard links on ntfs partitions? Just to make it even more clear: I do get the expected behavior (well, at least the behavior I expect from hard links) when running the commands on an ext3 partition.

[Szabolcs Szakacsits (szaka)]

Hard links work fine (you can confirm by ls -i after cp -al) but probably the 'echo B > B' case doesn't because apparently the '>' creates a new file for some reason.

Do you have any specific software which doesn't work correctly with NTFS-3G?

[hopla (hopla)]

I suspected that '>' might create a new file too. So to be absolutely sure, I replaced '>' by '>>'. I got the same, wrong, results, file B was changed, while file A wasn't.

So I still say: hard links do not work on ntfs on my computer. And there is still no one here who has given me proof that they do work on their computer! So, please, everyone who wants to contribute to this bug report: please, if you have an ntfs partition, verify if ntfs hard links work or not on your computer (replace '>' by '>>' in the examples above if you want to be 100% certain) before posting any comments.

I need that hard links to work correctly for rsnapshot. Rsnapshot is a backup solution relying heavily on hard links. Backing up with rsnapshot to an ntfs partition (I do it on ntfs since it's an external HD that I also want use on Windows) now takes a really long time, since the first step in the process is to make a complete hard linked 'copy' of the previous snapshot. Normally this should be pretty quick, since creating a hard link is an atomic operation (right?). But I'm getting the impression that, on ntfs, the cp -al step of rsnapshot silently failes and creates a full copy instead of creating a proper hard link, which takes a whole lot longer than creating a simple link... Not to mention the waste of storage...

[Szabolcs Szakacsits (szaka)]

The problem can not be reproduced with NTFS-3G 2009.2.1, internal FUSE and kernel 2.6.26.

NTFS-3G and/or the kernel is too old in Ubuntu 8.10. Upstream NTFS-3G has closed this issue report as INVALID and Ubuntu specific.

[hopla (hopla)]

Thank you for checking with upstream!

Does this mean now that this bug is confirmed on Ubuntu? What steps can be taking to further investigate this issue and possibly have a fix in 8.10 or future Ubuntu release?

[AmenophisIII (amenophisiii)]

i did try the jaunty package in intrepid for other reasons and it worked fine.
you have to fetch two (architecture dependant, mine are for amd64 as the name implies) packages:
libntfs-3g49_2009.2.1-0ubuntu1_amd64.deb
ntfs-3g_2009.2.1-0ubuntu1_amd64.deb
and install it with dpkg -i <filenames>

dont blame me if it fries anything :)

[hopla (hopla)]

Well, if this is going to be fixed in Jaunty, then I think I can wait a month to get the official update and be less at a risk to fry stuff :)

Would be nice though if any of the devs could finally confirm that this bug is real (or not) and that it is fixed in Jaunty (or not).

[hopla (hopla)]

Ok, I updated to Jaunty but I still get the same, wrong, results (compared to the results on an ext3 partition).

So this means on my computer, I CAN reproduce the bug, contradicting with Szabolcs Szakacsits statement. My ntfs-3g man page says version 2009.2.1, I think Ubuntu uses 'internal FUSE' and kernel is even newer: 2.6.28-11-generic.

I'm a bit at a loss here...

[Szabolcs Szakacsits (szaka)]

Ubuntu doesn't compile with the internal FUSE library which is used to ensure and certify NTFS-3G quality. The external FUSE library has several issues which are fixed only in the FUSE CVS.

[hopla (hopla)]

Hmm... Is there a roadmap for getting internal FUSE library in Ubuntu? What is the outlook on this problem?

(thanks for the quick reply btw :) )

[Chris Coulson (chrisccoulson)]

Ubuntu won't be using the internal FUSE library anytime soon, as there are already quite a few things on the live CD that use the external libfuse library.

Is it possible for you to test this with a Karmic live CD, which uses ntfs-3g 2009.4.4? If it is still an issue with that version, I have a Karmic build in my PPA which is using the internal FUSE library for you to test too.

My PPA (and instructions for installing packages from it) can be found here: https://edge.launchpad.net/~chrisccoulson/+archive/ppa

I only have Karmic builds at the moment. If you require builds for Jaunty, then I can do those, but you might have to wait a few days for me to do them.

*** Disclaimer: This package is completely untested by me, so please use with caution ***

[shemgp (shemgp)]

cat >> b and cat > a works both for me in Jaunty

[Bart de Koning (bratdaking)]

Hey,

Hard links are supported as the test works for me (ubuntu 9.04, ntfs-3g 2009.2.1 external FUSE 27), HOWEVER:

$ echo 'file A' > A
$ cat A
file A
$ ln A B
$ cat A
file A
$ cat B
file A
$ ls -als
totaal 9
0 drwxrwxrwx 1 root root 0 2009-09-17 14:06 .
8 drwxrwxrwx 1 root root 8192 2009-09-17 14:04 ..
1 -rwxrwxrwx 2 root root 7 2009-09-17 14:06 A
1 -rwxrwxrwx 2 root root 7 2009-09-17 14:06 B
(Checked using nautilus the size of the dir: contents were 2 files total size: 7 bytes -> ah hard links)
The test:

$ echo 'file B' > B
$ cat A B
file A
file B
First conclusion was that the test failed, however I used BackinTime (combination of rsync and cp -al) to make some snapshots here that clearly showed support of hard links, and the dir was still 7 bytes in nautilus i.s.o. 14 ?!?

More tests:
$ echo "Test A" >> A
$ cat A B
file A
Test A
file B
Test A

OK now things are getting messy here, why is Test A written to both files, but the file A not changed ?!?
One more test

$ echo "File 3" >> B
$ cat A B
file B
Test A
File 3
file B
Test A
File 3

Do you get it, I do not: it not only introduced File 3 in both files, it also changed the File A to File B
Could it be an after effect of some caching event?

oh btw:
$ mount | grep /media/D0111055_SYS
/dev/sda1 on /media/D0111055_SYS type fuseblk (rw,nosuid,nodev,allow_other,blksize=4096)

[Launchpad Janitor (janitor)]

[Expired for ntfs-3g (Ubuntu) because there has been no activity for 60 days.]