New timestamp when copying to NTFS partition

Bug #314860 reported by Toontje
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
ntfs-3g (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

When copying files to a NTFS partition, Nautilus does not preserve the timestamp (the new timestamp will be the current time and date). When copying to an Ext3 partition it does.
GNOME Commander has the same behaviour.

My NTFS partition is created by fstab: # /dev/sda3 UUID=84C88DAEC88D9F54 /data ntfs defaults,umask=007,gid=46 0 1

I use Ubuntu 8.10 64bit, updated until today.

I am aware of https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/254016 but I opened a new bug because the proposed solution (use ntfs-3g instead of ntfs) does not solve the problem.
Besides bug 254016 was in Ubuntu 8.04 and it's still present in 8.10 by default.

Revision history for this message
Toontje (antoonr) wrote :
Revision history for this message
Sebastien Bacher (seb128) wrote :

you get the bug in GNOME commander so that's clearly not a nautilus issue

Revision history for this message
Toontje (antoonr) wrote :

I get the bug in BOTH Nautilus and GNOME Commander. As Nautilus is the native Ubuntu file manager, I filed the bug under Nautilus.

When you can tell me which package is causing the problem, please let me know and I will change that.

Revision history for this message
Toontje (antoonr) wrote :

I re-linked this bug with Nautilus because this problem (also) shows up in Nautilus.

When Nautilus uses another package to copy files, then maybe the problem is caused by that other package, but as I'm just a simple Ubuntu desktop user who is trying very hard to stop using XP, I have no idea what packages Nautilus uses for copying files.

I do understand that Ubuntu is free software and that I therefore cannot demand help, but I hoped for a little more cooperation than just the remark "you get the bug in GNOME commander so that's clearly not a nautilus issue" because I attach a screenshot from GNOME Commander.
If it helps, I can open a new bug in which I only mention Nautilus and attach screenshots from the same operation in Nautilus.

Revision history for this message
A. Walton (awalton) wrote :

If it's happening in GNOME commander it means that it's happening in something below both file managers (which traverses from GLib down to the kernel). Where the bug exists below is a good question, but it's not one we can answer without a lot more information about how this change occurs. Your best bet is to run strace and watch for filesystem events against the NTFS file system to see where the timestamp is changing.

In the meantime, this is not a Nautilus (or GNOME commander) bug.

Revision history for this message
Toontje (antoonr) wrote :

I followed the advice of Mr.Walton and let strace monitor the copying of a file to a NTFS partition.
The log is attached.

I did the following:
I opened gnome-commander with /data/Antoon/Temp/Test on the left (this is a folder on a NTFS partition) and /home/antoon/Backup/home/antoon/Pictures/Seville on the right.
I checked the PID of gnome-commander: 7154
From a terminal window I gave the command: strace -Ff -tt -p 7154 2>&1 | tee strace-gc-ntfs.log
In gnome-commander I selected the file 1979_Cadillac_Seville_Elegante1.6.jpg and copied this file with F5 to the NTFS partition.
After that CTRL-C in the terminal window to stop strace.

What I notice when I try to analyze the log file:

At 11:04:43.416287, a new PID appears: 8752
At 11:04:43.437215 PID 8752 checks if the target folder is OK
At 11:04:43.442787 PID 8752 if the destination file already exists
At 11:04:43.444902 PID 8752 opens the source file
At 11:04:43.445088 PID 8752 opens the destination file
Then I see read / write operations until 11:04:43.479351
At 11:04:43.480918 PID 8752 tries to chmod and ´utime´ the destination file (which I understand is not allowed)
[pid 8752] 11:04:43.480918 chmod("/data/Antoon/Temp/Test/1979_Cadillac_Seville_Elegante1.6.jpg", 0770) = -1 EPERM (Operation not permitted)

[pid 8752] 11:04:43.481267 utime("/data/Antoon/Temp/Test/1979_Cadillac_Seville_Elegante1.6.jpg", [2008/12/25-12:03:21, 2007/11/21-22:19:40]) = -1 EPERM (Operation not permitted)

Please note that 2007/11/21-22:19:40 was the original timestamp (of the source file). So here something goes wrong.

I also logged the same copy operation when copying the same file to an Ext3 partition, then I see that (PID 9053) successfully ends the chmod, chown and utime commands:
[pid 9053] 11:56:38.624436 chmod("/home/antoon/Pictures/Test/1979_Cadillac_Seville_Elegante1.6.jpg", 0770) = 0

[pid 9053] 11:56:38.624543 chown("/home/antoon/Pictures/Test/1979_Cadillac_Seville_Elegante1.6.jpg", 1000, 1000) = 0

[pid 9053] 11:56:38.624608 utime("/home/antoon/Pictures/Test/1979_Cadillac_Seville_Elegante1.6.jpg", [2009/01/11-11:04:43, 2007/11/21-22:19:40]) = 0

Revision history for this message
Coffeecat (coffeecat) wrote :

I can add something to this.

This is happening in Jaunty as of today. If you rely on the fstab entry as set up by the Jaunty installer for an internal partition (device mountpoint ntfs defaults,nls=utf8,umask=007,gid=46 0 1), you get:

Nautilus file copy ext3 partition -> NTFS partition - date/time changed to current.
Nautilus file copy NTFS partition -> ext3 partition - date/time preserved.

But if you change the fstab entry to a simple:

device mountpoint ntfs defaults 0 0

...date and time stamps are preserved both ways. In fact that's what I've been using (or with filesystem field = ntfs-3g) for quite some and I have yet to have a problem with it.

Also to add: date/time is preserved copying both ways with an automounted external NTFS drive. No problem there.

Changed in linux (Ubuntu):
status: New → Confirmed
Revision history for this message
VanillaMozilla (vanillamozilla) wrote :

This is not a Nautilus bug, since it also applies to the cp -a command, with an error message: "cp: preserving times for `/mnt/Windisk/Me/Bug311567Demo.gnumeric': Operation not permitted". See http://tuxera.com/forum/viewtopic.php?f=2&t=2405 for details, especially my reply of Sat Dec 05, 2009 20:47.

This appears to be an ntfs-3g bug, caused by the gid=46 option. Root privilege is required to PRESERVE the time stamp! According to the reply from jpa on Tue Dec 08, 2009 18:34 this problem is fixed in the most recent version (ntfs-3g-2009.11.14) of ntfs-3g, although I did not verify that.

There are many workarounds. The easiest is probably just to use the "default" option
device mountpoint ntfs-3g defaults 0 0
or if restricted access is required, just omit the line from fstab.

There is (at least) one other bug here. The Ubuntu installer writes the gid=46 option, and thus leads to data loss by losing time stamps. (See http://ubuntuforums.org/showthread.php?t=1330407&page=2 , message #12.) For now this is not reported.

It's a pity about the yo-yo-ing Package assignment. I didn't reassign it to ntfs-3g because I can't be sure. I would set the Importance to "major" (i.e., data loss) if I could. This seems to be a pretty old bug that has slipped through the cracks or been "fixed" before. For now, can we leave it open until someone can verify that it's fixed?

Revision history for this message
André Heynatz (ombatar) wrote :

This bug only occurs with NTFS partitions, so I change the package accordingly. The Ubuntu installers need to be fixed too, because the fstab options are not complete (only gid is set). But if I understand the issue correctly, a new version of ntfs-3g, "2009.11.14", would help tremendously in finding useful options for the ntfs-3g mount and resolve this issue completely from a joe user's point of view.

affects: linux (Ubuntu) → ntfs-3g (Ubuntu)
Revision history for this message
André Heynatz (ombatar) wrote :

I have a multiboot system with three operating systems:

A) Windows XP SP3
B) Windows 7
C) Ubuntu 9.10

On every OS I have created a user. These three users have to be mapped to one *identity* (me), so that the security features work flawlessly. If, for example, I restrict read access to one directory in any operating system to "me" only, this change shall be reflected in all operating systems.

System A and B use Session Identifiers (SIDs), whereas system C uses a User ID (UID). I do not know if it is possible from Linux side to determine the usernames of all SIDs which exist on all WIndows system partitions. The Ubuntu installer knows the username of the user who installs the OS. This username can then be compared to all usernames existing on Windows partitions so that a mapping file can be created automatically. So Ubuntu "just works" (see Bug #1).

We need a new User Interface for creating this mapping later on, so that the user can edit it easily.

The first step would be full POSIX compliance of the ntfs-3g filesystem. This can be achieved by providing an update of ntfs-3g to 2009.11.14. For testing, a user mapping can then be created in a file:

/etc/ntfs3g-usermapping:

1000::S-1-5-21-4120741282-3245112264-2965135236-1000

The User ID 1000 is created for the first user by the Ubuntu installer. The SID needs to be read out, I have given an example only. Windows regedit shows the SIDs in the registry key HKEY_USERS. Normally, after installation of Windows - if given exactly one username during installation - only one full SID exists which has a pattern like the one above.

The options line in /etc/fstab needs to be expanded, I am not sure about how to do that. My suggestion:

/dev/mapper/isw_bfacafefej_Volume07 /data ntfs defaults,nls=utf8,umask=007,gid=46,usermapping=/etc/ntfs3g-usermapping 0 0

/dev/mapper/... is a virtual device, because I use a RAID 0 system (Intel fakeraid). The option line which is important here begins with 'defaults'.

Andre

Revision history for this message
André Heynatz (ombatar) wrote :

Maybe this is too much to ask for at the moment. Even the Windows systems do not allow to connect the users of different Windows installations to one identity. A SID change would be necessary to have exactly the same SID on all Windows systems, but this can have security implications in an Active Directory domain.

If a file can be written to by the user, the date should be changeable by that user. I read that the new version of ntfs-3g, 2009.11.14, allows this. Please provide an update.

Revision history for this message
André Heynatz (ombatar) wrote :

With root privileges the timestamp is preserved, this can be achieved by using 'sudo':

sudo cp -a srcdir targetdir

sudo nautilus

I have written a Python script to correct the timestamps. The files need not be copied again! I have appended the script.

Revision history for this message
André Heynatz (ombatar) wrote :

I have enhanced the script so that the base directory is corrected as well, and dangling symlinks are tolerated now.

Revision history for this message
jefferson159 (flanello) wrote :

Also after a clean installation of ubuntu 10.4 I have the same problem.
However, when I remove the uid and gid tag of the fstab line it seems the problem is solved.
And it seems that USB NTFS harddisks work fine.

Revision history for this message
Jean-Pierre (jean-pierre-andre) wrote :

Please note that on Linux, only the owner of a file and root are allowed to set the timestamps of a file to a value different from the current time. So there are three options :
1) disabling permissions checks (no uid, gid, dmask, fmask and umask options)
2) make the user appear as the owner (uid options matches the user)
3) use standard Linux permissions (read and apply the user mapping section of the ntfs-3g manual).

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.