Nautilus STILL not preserving timestamps

[BassKozz]

Binary package hint: nautilus

Ubuntu 8.10 (64bit)
$ apt-cache policy nautilus
nautilus:
  Installed: 1:2.24.1-0ubuntu1
  Candidate: 1:2.24.1-0ubuntu1
  Version table:
 *** 1:2.24.1-0ubuntu1 0
        500 http://us.archive.ubuntu.com intrepid/main Packages
        100 /var/lib/dpkg/status

Nautilus is STILL not preserving timestamps even after a fix has been released: https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/215499
See also: http://ubuntuforums.org/showthread.php?t=1006997

[Sebastien Bacher (seb128)]

thank you for your bug report, could you give details on what you copy between what disks and how? does using cp or gvfs-copy on a command line has the same issue?

[Bill Smith (bsmith1051)]

I had this problem, too, though on the 32-bit Ubuntu 8.10.

PROCEDURE
- fresh install of 8.10 on RAID-1 pair (ext3)
- reconnect old 8.04.1 drive (one of previous RAID1 pair)
- I don't think I did a 'proper' mount, e.g. from command-line or through /etc/fstab. Instead, I think I was able to access the drive through Ubuntu's Places > "160GB hard-drive" entry
- I copied a large folder of Photos to the new drive
- I may have tweaked the file ACLs on the source-drive to allow me access?

RESULT
All files on new drive have the timestamp of the copy.

Also, I copied the folder to /home/Photos rather than my own home-dir because my wife and I share the computer. Could there have been an issue with the file ACLs on the newly-written files, i.e., that prevented the original timestamp from being copied?

[Sebastien Bacher (seb128)]

how did you copy the photo exactly? could you try using the command line tools?

[Chris Cheney (ccheney)]

I can't reproduce this on Ubuntu 8.10 with current updates when copying to local filesystems. However when copying to remote filesystems (eg writing to a samba share) I still see this problem and filed bug #319063 about it. This is fixed upstream and is fixed in Jaunty but hasn't been fixed in intrepid-updates yet.

[BassKozz (basskozz+ubuntu)]

I've been trying to reproduce this as well, and I've come to the conclusion that the reason I was experiencing this issue is because I was also (like Chris) copying files to a samba share I had mounted.
So this bug can probably be closed or added as a dupe to Chris's bug #319063

[Graham Inggs (ginggs)]

I still see this on a local ext3 filesystem in Intrepid.

[Stuart (stuartneilson)]

Copying a file to any destination except an smb share preserves the file modification dates. Files copied to an smb share (whether copied through Nautilus or command line) have the date and time at which the copy was performed. The --preserve option in cp has no effect. Copying to NTFS, ext3, FAT and usb-attached storage always preserves the date, copying from smb preserves the date, just writing to smb is faulty. This applies to Ubuntu 8.10 with all updates applied at the date of writing.

This bug is a real downer when trying to share a set of resources in a single smb directory because Ubuntu writes an incorrect (more recent) file modification date. Windows and Mac systems on the same network preserve the original file modification date when copying to smb.

[Stuart (stuartneilson)]

Workaround:

If the foreign filesystem is mounted with uid=<your username> then cp and Nautilus preserve the file timestamps and permissions. Ubuntu is automounting with a userid other than that of the current user and the file is "owned" by this other userid at the time that permissions and timestamps are set, before ownership reverts to the logged in user.

I.e. the following DOES preserve times:

  sudo mount -t cifs -o username=server_user,password=<password>,uid=stuart server:data data

I found the explanation at http://www.linuxquestions.org/questions/debian-26/preserving-time-operation-not-permitted-on-fat32-on-debian-135951/?s=6b0781eb3ccc5236bcb1077e7e183809

[david6 (andrew-dowden)]

New bug files: Bug #738462