Ubuntu Karmic (version 9.10) does not preserve the date stamp when copying a file to an NTFS volume when the disk is mounted with the gid=46 option. The time is erroneously reset to the current time. Apparently all copy methods show this error, specifically the Nautilus file manager, or the cp or cp -a command. Either of the following statements in the fstab file initiates the problem:

/dev/sdb1 /media/DataB ntfs-3g defaults,nls=utf8,umask=007,gid=46 0 0
/dev/sdb1 /media/DataB ntfs-3g gid=46 0 0

This is discussed here:
http://ubuntuforums.org/showthread.php?t=1330407

This thread appears closely related:
viewtopic.ph...7efcce57216236

Hi,

Which ntfs-3g version and configuration are you using ? type :


Also, what is the owner of the process doing the copy, and the owner of the parent directory ? With these mount options, the file is created as owned by root (you did not indicate a uid), and you prevent access by anybody by the umask=007 option, so you may have a permission issue.

Regards

Jean-Pierre

Version:
ntfs-3g 2009.4.4 external FUSE 27 - Third Generation NTFS Driver

I don't have answers for the other questions. I can try to answer them if you still want. But I assume the owner of the copy process would be the logged on user, wouldn't it? I don't know how to check, since the copy process would probably be terminated before I could check it, unless I copy something huge. It is my understanding that ntfs-3g does not support file ownership. But even if it is owned by root, what does that have to do with resetting the time stamp?

I can tell you this, though.
device mountpoint ntfs defaults 0 0
or
device mountpoint ntfs defaults, noexec 0 0

works just fine. The interesting thing is that I am informed that the offending line in fstab was put there by the Ubuntu installer.

Hi,


No time stamp problem has been identified so far on this version, which has been released 8 months ago.


True for this version, the ownership defined on the mount command (or fstab) is used instead. In your case the file is owned by root.

The utime(2) manual says : "Changing timestamps is permitted when: either the process has appropriate privileges, or the effective user ID equals the user ID of the file, or times is NULL and the process has write permission for the file."

Regards

Jean-Pierre

But
cp -a
does not preserve the file stamp. There's a problem somewhere. Take a look at the following.



Me@Comp:~/Documents$ ls Bug* -l
-rw-r--r-- 1 Me Me 1940 2009-10-20 21:47 Bug311567Demo.gnumeric

Me@Comp:~/Documents$ cp -a Bug311567Demo.gnumeric /mnt/Windisk/Me
cp: preserving times for `/mnt/Windisk/Me/Bug311567Demo.gnumeric': Operation not permitted

[error!]

Me@Comp:~/Documents$ ls /mnt/Windisk/Me/Bug311567Demo.gnumeric -l
-rwxrwx--- 1 root plugdev 1940 2009-12-05 12:26 /mnt/Windisk/Me/Bug311567Demo.gnumeric

[oops, date has been reset by cp -a ]

Me@Comp:~/Documents$ cat /etc/fstab
/dev/sda2 /mnt/Windisk ntfs-3g defaults,umask=007,gid=46 0 0

[edited to remove extraneous info]

Hi,



You have used an ownership option such as the file is created as owned by root. Hence the user Me does not have not the right to set the time stamps (see my previous post).

On the mount option you should define the uid for the user Me.

Better still, create a user mapping so that you benefit from the normal Linux ownership and permission features ("man ntfs-3g").

Regards

Jean-Pierre

But the "cp -a" command DID reset the time stamp, even though you and "man cp" say it's not supposed to. Look again at the output I posted.


I KNOW how to set my personal fstab file so this doesn't happen. This is not a user support question.

The fstab entry is a minimalized example. I didn't make it up. The same problem happens with a default configuration on Ubuntu.

The way I read the man page, cp -a is NEVER supposed to do this, regardless of mount options. I don't know for sure if it's an ntfs-3g bug, a Ubuntu bug, or a Linux kernel bug. Can you either convince me that there is no bug or help me pinpoint the error and file a bug report where it will actually get seen and fixed? Thanks.

Hi,



"cp -a" could not set the original time stamp, so you ended with the time when the copy was made (is this what you call reset the time stamp ?). You got the error message telling you that preserving the original time stamp was not permitted :

The reason why this is not permitted is apparent in your result :

The current user is Me and the owner of the file is root. They do not match, consequently the setting the time stamp to the same value as the original is not allowed, and the copy still mentions the time the copy was made.
Was there something else which I was supposed to notice ?

So what is the purpose of your post ?

"cp -a" is supposed to be used on a file system which is Posix compliant, but you are using an old version of ntfs-3g (2009.4.4) which does not support ownership and protection. The special mount options (uid, gid, etc.) are just workarounds for what may appear to you as a bug, but is just a partial development.
If you want full support for ownership and protections, and preserving ownership and timestamps when using "cp -a", you have to upgrade to the latest ntfs-g version (2009.11.14) and define a user mapping.

Just hope I am answering the right question....

Regards

Jean-Pierre

Ah, yes, it is clear that I didn't read the error message correctly. But surely something is still broken here. Is it not an error (either a design error or a bug) to require privilege to preserve the date stamp instead of requiring privilege to reset the date stamp?

Thank you. That is EXACTLY what I needed to know. Can I assume this problem is solved, then? So that if and when Ubuntu uses a more recent version of ntfs-3g, cat -a will actually preserve the date stamp?

As far as you know, will the most recent version of ntfs-3g solve the problem, then? It's not for me. There are various bug reports and support requests open on this, and I would like to report back and clean them up a little. Thanks.

Hi,


The most recent version (ntfs-3g-2009.11.14) fully implements the Posix ownership and permission features and behaves like ext2/ext3/ext4. A user mapping is however needed, see http://www.tuxera.com/community/ntfs-3g ... rmissions/

If you only want to solve the time stamp problem, you may be satisfied with a proper definition of uid and gid as mount options, but this obviously limits to a single user.

Regards

Jean-Pierre

Thanks. Comment on bug posted here: https://bugs.launchpad.net/ubuntu/+sour ... bug/314860 .

Hi,

Why are these reports coming back only now ? ntfs-3g-2009.4.4 has been released 8 months ago, and has been used by a lot of people and distributions.

Has somebody recently posted somewhere a recommendation for defining a gid and not defining a uid ? I cannot accept this has been valid any time in the past.

Regards

Jean-Pierre

I don't know. Why haven't 40 years of *nix users complained that cp is an alias for cp + touch, and that the man page doesn't correctly describe the behavior? These problems aren't just coming up now, so I don't think there is something new going on. This bug was triggered by the Ubuntu installer, however, so the problem probably fairly widespread.

I think the release of Ubuntu Karmic probably caused quite a few mount and timestamp problems. In the discussion we identified at least 5 open problems (counting this one) that I regard as bugs. If you look through support requests, you will see quite a lot of problems, but the system is so complex that I think they are spread among many causes. The system is way to complex, or at least poorly documented for such a complicated system. For some Ubuntu users ntfs-config probably solved some of those problems without triggering this bug.

Some bugs get ignored or invalidated because they are filed under the wrong package. Launchpad is not very helpful here. Instead of offering a list and description of packages, it offers an unhelpful search field, with no list and no descriptions. I worked long and hard to find this problem and trace it to ntfs-3g.

Anyway, thanks very much for your help. I couldn't have figured it out on my own.