Copyng a file to a NTFS drive change the date and the time of the file

Bug #157396 reported by Carmelo Viavattene on 2007-10-26
16
Affects Status Importance Assigned to Milestone
ntfs-config
Undecided
Unassigned
nautilus (Ubuntu)
Wishlist
Unassigned
Nominated for Hardy by Forrest Samuels
ntfs-3g (Ubuntu)
Wishlist
Unassigned
Nominated for Hardy by Forrest Samuels

Bug Description

Ubuntu 7.10
I'am a hard disk with NTFS partition.
I use Nautilus to copy files or directory, and the problem appear.
If I copy a file to the NTFS partition, the date and the time of the copyed file is changed to the time of the end of copy.
The same problem in a USB hard disk NTFS.

This not appear if I copy a file in my home ubuntu (ext3) or in my key USB (fat32).

If I move the file in the NTFS partition, the date/time is not changed.

This is bug is very annoyng:
I'am some OpenOffice files created in Windows, and I want save in my external hard disk. I MUST know when my file is created.

Please correct.

Regards,

Carmelo Viavattene

Szabolcs Szakacsits (szaka) wrote :

When you /bin/cp a file then it gets new timestamps by default whatever is the file system. Nautilus maybe redefines this behaviour but not consistently.

If I copy my files from a disk to another or to another directory, I want know when my files are created.

Can You help me?

Regards,
Carmelo Viavattene

Please, change my comment of the original report from
"I MUST know when my file is writed."
to
"I MUST know when my file is created."

Regards,
Carmelo Viavattene

Changed in ntfs-3g:
importance: Undecided → Wishlist
Siegfried Gevatter (rainct) wrote :

@ Carmelo: For the case you want to change something on further reports, notice that there's a «Edit description/tags» option at the left (section «Actions»). Cheers!

Changed in nautilus:
importance: Undecided → Wishlist
Szabolcs Szakacsits (szaka) wrote :

We've check it out now and NTFS-3G indeed doesn't update the "creation" time correctly sometimes (originally you commented the "modification" time).

Thank you for the bug report, this is planned to be fixed in the next NTFS-3G release.

          Szaka

==
NTFS-3G Lead Developer: http://ntfs-3g.org

description: updated

@ Siegfried: Thank You,
Then, I have changed the description of my first report with «Edit description/tags» at the left.

At this point, i know a best way to report a bug to Ubuntu team, and to change a my not perfect description.

@ Szabolcs:
Moreover, I am happy to have guessed to address the error message to the group ntfs-3g.

However, the important thing is that the error has been identified and is soon resolved.
When will the release of the next version of NTFS-3G?

Also, I'am marked as duplicated of this bug my report 157585.
I thought that when it is not a mistake of NTFS-3G, I had to report it as a mistake of NAUTILUS.
Then I realized that I can change the group to which the error is reported (is my first report of a bug),
So, reporting 157585 is unnecessary.

Regards,
Carmelo Viavattene

Szabolcs Szakacsits (szaka) wrote :

Just to clarify: do you want the file "change" timestamp to be the start time of the copy, not the end time of the copy? If the driver doesn't do things this way then that will be fixed (one unrelated ctime update problem is already fixed).

If you're interested in the "creation" time then unfortunately I must say that Linux/Unix doesn't have the concept of "creation" time as NTFS does. When you copy a file from NTFS to any other volume (ext3, fat, ntfs, etc) then the NTFS "creation" timestamp will be lost because no utility and Unix API can handle it.

I not want the start time of the copy. I not want the end time of the copy. I want the same time of the file origin of the copy:
An example: if I'am a file of 2005-10-24 8.34.56, and I copy this file to a NTFS drive, the copyed file MUST have the same time of 2005-10-24 8.34.56. So, if I see in the drive origin and in the drive destination, i want the same file, with the same name, length, and ... SAME TIME.

You can try this: create a new file, in your Home (ext3 drive); if you copy this file in the same directory, or in Examples directory, you have the original time (and this is correct). If You copy in a NTFS drive, the time change at the time of the end of the copy (wrong). Expected: the time is the same of the original file.
The "creation" time is not the concept of NTFS: simply, I'am interested at the time i see in a standard view of Nautilus (after the installation of Ubuntu 7.10).

Try to extract some or all the files of a compressed file (.zip, .tar, ...): in the compressed file You see the date and the time of the file, and if You extract in a NTFS drive, at this moment You see the date of the copy. Expected is the original date (and time), and this is OK if you extract in a ext3 drive (example your Home).

Regards,
Carmelo Viavattene

Szabolcs Szakacsits (szaka) wrote :

Ntfs-3g updates the times the same way as other file systems.

ext3:
# stat test1
  File: `test1'
  Size: 0 Blocks: 0 IO Block: 4096 regular empty file
Device: 805h/2053d Inode: 2275396 Links: 1
Access: (0664/-rw-rw-r--) Uid: ( 1004/ szaka) Gid: ( 100/ users)
Access: 2007-11-01 16:41:52.000000000 +0200
Modify: 2007-11-01 16:41:52.000000000 +0200
Change: 2007-11-01 16:41:52.000000000 +0200

# /bin/cp -p test1 test2
# stat test2
  File: `test2'
  Size: 0 Blocks: 0 IO Block: 4096 regular empty file
Device: 805h/2053d Inode: 3023826 Links: 1
Access: (0664/-rw-rw-r--) Uid: ( 1004/ szaka) Gid: ( 100/ users)
Access: 2007-11-01 16:41:52.000000000 +0200
Modify: 2007-11-01 16:41:52.000000000 +0200
Change: 2007-11-01 16:42:05.000000000 +0200

ntfs-3g:
# stat test1
   File: `test1'
  Size: 0 Blocks: 0 IO Block: 4096 regular empty file
Device: 806h/2054d Inode: 60 Links: 1
Access: (0664/-rw-rw-r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2007-11-01 16:41:01.000000000 +0200
Modify: 2007-11-01 16:41:01.000000000 +0200
Change: 2007-11-01 16:41:01.000000000 +0200

# /bin/cp -p test1 test2
# stat test2
  File: `test2'
  Size: 0 Blocks: 0 IO Block: 4096 regular empty file
Device: 806h/2054d Inode: 61 Links: 1
Access: (0664/-rw-rw-r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2007-11-01 16:41:01.000000000 +0200
Modify: 2007-11-01 16:41:01.000000000 +0200
Change: 2007-11-01 16:41:15.000000000 +0200

In both cases the modification time is unchanged and the change time is the last inode modification time as the Single Unix Specification requires.

Szabolcs Szakacsits (szaka) wrote :

> Try to extract some or all the files of a compressed file (.zip, .tar, ...): in the compressed file You see
> the date and the time of the file, and if You extract in a NTFS drive, at this moment You see the date of
> the copy. Expected is the original date (and time), and this is OK if you extract in a ext3 drive (example
> your Home).

This also works with ntfs-3g 1.1030:

# tar xzvpf fstest_20070718.tgz
# ls -l fstest_20070718
total 50
-rw-r--r-- 1 root root 646 Jan 28 2007 README
-rw-r--r-- 1 root root 1451 Jan 28 2007 LICENSE
-rw-r--r-- 1 root root 19923 Jul 18 18:40 fstest.c
-rw-r--r-- 1 root root 296 Oct 31 19:04 Makefile
drwxr-xr-x 1 root root 4096 Oct 31 19:04 tests/
-rwxrwxr-x 1 root root 18901 Oct 31 19:04 fstest*

As you see, all times are in the past, they are the original file creation times. So you indeed seem to have a Nautilus problem after all.

Download full text (5.2 KiB)

Is not a Nautilus problem.
To search the problem, i go to a complete re-install of my Ubuntu 7.10.
Now, i check all.
The ntfs-3g installed in my computer is version 1:1.913-2ubuntu1.
My computer have only a hard disk:
sda1 is a Windows XP C: drive, filesystem NTFS
sda2 is a Windows D: drive, filesystem NTFS
sda3 is swap linux
sda4 is / linux, filesystem ext3.

Then, I go to copy a test file not in Nautilus (then, is not a Nautilus problem).
I use the terminal.
The file is test.txt
I copy from terminal and paste in this comment.

carmelo@ubuntu-laptop:~$ cp -p test.txt test2.txt
carmelo@ubuntu-laptop:~$ stat test*
  File: `test2.txt'
  Size: 17 Blocks: 8 IO Block: 4096 file normale
Device: 804h/2052d Inode: 66960 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1000/ carmelo) Gid: ( 1000/ carmelo)
Access: 2007-11-01 20:04:59.000000000 +0100
Modify: 2007-11-01 20:04:58.000000000 +0100
Change: 2007-11-01 20:05:58.000000000 +0100
  File: `test.txt'
  Size: 17 Blocks: 8 IO Block: 4096 file normale
Device: 804h/2052d Inode: 66956 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1000/ carmelo) Gid: ( 1000/ carmelo)
Access: 2007-11-01 20:05:58.000000000 +0100
Modify: 2007-11-01 20:04:58.000000000 +0100
Change: 2007-11-01 20:04:58.000000000 +0100
  File: `test.txt~'
  Size: 0 Blocks: 0 IO Block: 4096 file normale vuoto
Device: 804h/2052d Inode: 66948 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1000/ carmelo) Gid: ( 1000/ carmelo)
Access: 2007-11-01 20:04:44.000000000 +0100
Modify: 2007-11-01 20:04:37.000000000 +0100
Change: 2007-11-01 20:04:58.000000000 +0100

The modify time of test.txt (origin) and of test2.txt (destination) is the same, and is OK.
In a view of Nautilus, i see the modify time, and is OK.
And now, copy in NTFS drive:

carmelo@ubuntu-laptop:~$ cp -p test.txt /media/sda2/test3.txt
cp: preservato l'orario di `/media/sda2/test3.txt': Funzione non permessa
carmelo@ubuntu-laptop:~$ cp -p /media/sda2/test3.txt /media/sda2/test4.txt
cp: preservato l'orario di `/media/sda2/test4.txt': Funzione non permessa
carmelo@ubuntu-laptop:~$ stat /media/sda2/test*
  File: `/media/sda2/test3.txt'
  Size: 17 Blocks: 1 IO Block: 4096 file normale
Device: 802h/2050d Inode: 6299 Links: 1
Access: (0770/-rwxrwx---) Uid: ( 0/ root) Gid: ( 46/ plugdev)
Access: 2007-11-01 20:08:19.000000000 +0100
Modify: 2007-11-01 20:08:19.000000000 +0100
Change: 2007-11-01 20:08:19.000000000 +0100
  File: `/media/sda2/test4.txt'
  Size: 17 Blocks: 1 IO Block: 4096 file normale
Device: 802h/2050d Inode: 6300 Links: 1
Access: (0770/-rwxrwx---) Uid: ( 0/ root) Gid: ( 46/ plugdev)
Access: 2007-11-01 20:09:58.000000000 +0100
Modify: 2007-11-01 20:09:58.000000000 +0100
Change: 2007-11-01 20:09:58.000000000 +0100

I think this is the problem is at the cp command.
cp: preservato l'orario di `/media/sda2/test3.txt': Funzione non permessa
Transaltion from my italian language is:
cp: preserved the time of `/media/sda2/test3.txt': function not permitted

I see You have access different from my acces...

Read more...

Sorry, a correction:

I think I must change:
UUID=567ECDF67ECDCF45 /media/sda2 ntfs defaults,umask=007,gid=46 0 1
in:
UUID=567ECDF67ECDCF45 /media/sda2 ntfs defaults,locale=it_IT.utf8 0 1

and can be I solve the problem of preserving the modify time?
(In this way I set the permissions of NTFS drive equal to ext3 drive)

1) Please, reply me if this is correct.

2) Another question: if I insert a external USB NTFS drive, i must change the permission?

3) At the end, i think a bug is present: Ubuntu must set by default correctly the permission of NTFS drive, internal and external.

Is not a problem of NTFS-3G, and I not know the correct project must correct this bug.

Regards,
Carmelo Viavattene

Auto-reply.
Sorry, another correction:

I'am changed:
UUID=567ECDF67ECDCF45 /media/sda2 ntfs defaults,umask=007,gid=46 0 1
in:
UUID=567ECDF67ECDCF45 /media/sda2 ntfs-3g defaults,locale=it_IT.utf8 0 1

and all is OK.
Then, changing the permission, my problem is solved (the modify time is preserved).

For my external USB NTFS drive, i'am not problems (the modify time is preserved).

The bug is auto-SOLVED partially.

@ Szabolcs:
Remain a portion of the bug:
Ubuntu must set by default the /etc/fstab for existing NTFS drive, using ntfs-3g, and without umask.
Please, can You search the correct project to solve this?

Regards,
Carmelo Viavattene

Szabolcs Szakacsits (szaka) wrote :

ntfs-config

added ntfs-config project

Carmelo Viavattene

It looks like this is fixed in release 1.1120 of NTFS-3G which is also the package currently in the Hardy (8.04) repository http://packages.ubuntu.com/hardy/ntfs-3g so this bug may be resolved in 8.04.

Urs (urs-naege) wrote :

I am sorry, but this bug is NOT solved with 8.04 - in contrary it appears again with all folders, while this problem didn't show up in 7.04.

I also defintiely need the creation date of a file to be copied in the target folder and not the copy date! Especially with images from a camera!

This urgently has to be fixed. I thought there would be somewhere a an change option in Nautilus but I do not find it.

Thanks, Urs

This particular bug IS fixed in 8.04 (and in 7.10 in the backports repository). There is a new bug in GNOME with the new GVFS that is causing modified dates to get changed for file copy/move across ALL file systems. That is bug 215499 (https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/215499). Using 'cp -p' on the command line or gnome-commander both preserve the modified date if you are looking for a work around. They are not the best but they do work.

1.) Am I getting this right: The problem is still the same as described by the bug filer but now for another reason, which is described in https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/215499?

2.) Does anyone know whether a proper file copying system will be available with 8.10?

Try using gnome commander or a different file manager also as a work around in 8.10.

You mean "you are trying" or "you are advising me to try this"?

Why is this classified as "wishlist" anyway? From my limited knowledge I would say this clearly adresses a bug.

Sebastien Bacher (seb128) wrote :

the standard unix copy does the same, the behaviour might be different from what you expect but that doesn't make it really a bug

Depends upon whether you see the behaviour of standard Unix as the measure.

Personally, I would say that if I wanted Unix I would buy Unix, and the only question important here is whether current defaults make sense or might be dangerous for the average Ubuntu user.

Cf. Wikipedia, s.v. "Software bug": "A software bug (or just "bug") is an error, flaw, mistake, failure, fault or "undocumented feature" in a computer program that prevents it from behaving as intended ... ." IMHO this applies here: If you copy a file, you expect your file creation date not to be destroyed. Current defaults prevents the software from behaving as intended by the bug filer.

Current defaults have massive destructive potential. Imagine the bug filer doing a backup and then formatting his main hard disk drive because he wants to install a new system. It will probably be only when he copies back his data that he will notice that all his creation dates have been destroyed, which will make it impossible to have his data sorted by creation date in the future.

Having your data intact, this goes far beyond a mere "wish".

Sebastien Bacher (seb128) wrote :

> this applies here: If you copy a file, you expect your file creation date not to be destroyed. Current defaults prevents the software from behaving as intended by the bug filer.

not really, a copy is writting the content in a different directory, having the creation date being the copy one somewhat makes sense since that's when the new file has been created

I agree that from a purely technical point of view, there is some inherent logic in that. From the user's point of view, this is, however, not understandable.

You can ask yourself which information a user would expect to have: The birthdate of the file or the date of some copying process. Secondly, you can ask yourself whether you ever wondered about the COPYING DATE of a file.

And, once again:

Cf. Wikipedia, s.v. "Software bug": "A software bug (or just "bug") is an error, flaw, mistake, failure, fault or "undocumented feature" in a computer program that prevents it from behaving as intended ... ." IMHO this applies here: If you copy a file, you expect your file creation date not to be destroyed. Current defaults prevents the software from behaving as intended by the bug filer.

Sebastien Bacher (seb128) wrote :

did you read the previous comment? different users might have different expectation about the modification date there, technically the new file has been created when you did the copy so changing the date for this one is correct, anyway discussing the settings is not constructive and will not make the bug fixed faster quite the contrary so I'll stop this discussion there

> did you read the previous comment?

Yes, and I answered to it. Please read.

> different users might have different expectation about the modification date there

Actually, when you read this thread carefully, you will notice that all users writing here have the same expectation as the bug filer. The only one who has a different expectation here is you.

> anyway discussing the settings is not constructive and will not make the bug fixed faster quite the contrary so I'll stop this discussion there

Sorry, I don't get it. First you keep telling us that this is a feature, not a bug, and now you are telling us that you have no time discussing with us because you need it to fix "the bug"? Sorry to say that, but that's quite illogical. No offence intended of course.

Sebastien Bacher (seb128) wrote :

> you will notice that all users writing here have the same expectation as the bug filer.

sure, why users who don't consider the current behaviour as buggy would go to the bug tracker, search for this bug and comment there?

> this is a feature, not a bug

no, I'm saying that feature of bug is a matter of perception in this case and that you should stop spamming people by adding comments to discuss the settings there that's not constructive

> because you need it to fix "the bug"

where did I write I was going to work on this issue? I just say that discussion about settings are not interesting, it'll make people unsubscribe from the bug to stop receiving those comments spams and the time spent commenting and reading those comments is not used to do useful thingq

Sebastien Bacher (seb128) wrote :

the bug should also likely be marked duplicate of bug #215499 now

Due to this BUG, I switch from Ubuntu to Mandriva.
In Mandriva all work perfectly, I found a greater number of programs, the installation of GoogleEarth (and other programs) is simpler, I can connect and syncronize with my Htc Touch in a very simply way.

Bye, Bye Ubuntu

Sebastien Bacher (seb128) wrote :

> Due to this BUG, I switch from Ubuntu to Mandriva.

you are free to use the system you want but such comments are not really useful on a bug, you should rather send your comments to an user forum or mailing list, note that the gvfs issue is an upstream one so the current mandriva will have it too

Urs (urs-naege) wrote :

>> Due to this BUG, I switch from Ubuntu to Mandriva.

> you are free to use the system you want but such comments are not really useful on a bug

Who cares - this story about this wrong copying has now going on for X months, we all are fed up with the responsible people not caring about it. So we place our signs of discontentment where we want.

By the way, with GNOME Commander or Thunar the copying of files including the original change date is working fine. so let's forget about Nautilus...

Sorry.
My first installation of a Linux is Mandrake (today Mandriva), used only 15 day, some years ago.
Then, in 2007, I have used Linux next Year, from ubuntu 7.04 to 8.04, and I liked Ubuntu, and Linux.

The BUG, found in Ubuntu 7.10, is present in Ubuntu 8.04
I switch to Mandriva to try if this BUG is not present.
Due to my new experience in Linux systems from Ubuntu, I like the Mandriva, and the features of syncronize with Windows Mobile, simpler install of programs, simpler install of driver for Broadcom Wifi (my wifi Broadcom, perfectly working in 7.10, not work in 8.04), simpler install of ATI drivers.
I'am satisfied: my system work perfectly, and the datetime problem of my NTFS files is not present.

At this moment, I use Mandriva (I'am free to use the system I want).

I must write: I use Mandriva Kde and not Gnome; for files management I use Konqueror (Kde) and not Nautilus (Gnome).

Can be the BUG is also presente in Mandriva Gnome, I don't know.

I hope Ubuntu (or Gnome, or Nautilus,or gvfs) team solve this problem, and I go to try also Ubuntu 8.10 to see if this problem (and the others for Broadcom Wifi) is solved.

At this moment, I'am happy with my system.

Sorry, and Thank You for this useful experience.

Regards,
Carmelo Viavattene

Dave Vree (hdave) wrote :

I think the idea that this is not a bug is totally wrong. This bug OP does not want Linux to work differently than the UNIX spec. He wants Linux to work according to the NTFS spec when writing to an NTFS file system. NTFS tracks a creation date and a modified date. We all understand that ext3 doesn't work this way. However NTFS does and since the problem is with NTFS it IS a bug.

The "wishlist" priority on this issue is not appropriate. It should be "critical".

As a photographer I can tell you this makes Ubuntu nearly worthless to me. I had to spend all last night in Windows just to get some work out. I am absolutely stunned at this regression from 7.10.

The only question that I am unclear on (because I see this in Hardy 8.04) is what is the source of the bug -- dvfs? ntfs-3g? nautilus?

Dick Dunbar (redunbar) wrote :

No question this is a bug, one that should be addressed as urgent if not critical. Creation and modification dates, and other attributes have always been preserved in Linux copy and move, and to state otherwise is ridiculous. Changing this behavior is disasterous, and it did change from 7.10 to 8.04. The debating should stop, and the fixing begin.

Florent Mertens (givre) on 2008-06-22
Changed in ntfs-config:
status: New → Invalid
Changed in ntfs-3g:
status: New → Invalid

The bug has been fixed now. The latest version of the library libglib2.0-0 (2.16.3-1ubuntu3) is already available if you allow "proposed" updates in the list of software sources. I believe it will soon be included in the next standard update.

philinux (philcb) wrote :

Just done all proposed update.

Connected digital camera via usb. Imported photo's via F-spot and Gthumb only to fine that the date modified was todays date, ie the creation date on my pc, and not the date the picture was taken. Previously files imported in gutsy had the date taken as the modified date.
Within the properties window under the image tab is the correct taken date.

Drew (dkrix) wrote :

Can anyone please advise what else to do besides installing libglib2.0-0 (2.16.3-1ubuntu3), to make the fix work.

(I installed the new package and nautilus copy still alters the date).

I'd also like to add my comment as to the importance of the above fix:

Like most commenters above, I agree (redoubled in spades!!!) that any file management system that claims to copy a file without copying arguably the most important piece if information associated with it (the modification date), has rocks in its head (if the "standards" say it should, then the standards are inconsistent with usability).

If people want to record the copy date, then attach a new date - but the term "modification date" and "date changed" etc are associated with the logical change to the content, not to the physical placement. (inot just by long usage with wi*&%ws, but by the common meaning of the terms).

eg, if I move a book from the dining room to the loungeroom, do I expect the date published to alter???? if I claim to have modified a report, I do not mean just run it through the photocopier. If you say you have changed your statement, I take you to mean the content has altered, not that you have moved it to another bookcase (hard copy) or disk drive (soft copy), etc, etc, ad nauseam.

  • unnamed Edit (738 bytes, text/html; charset=ISO-8859-1)

2008/6/22 Drew <email address hidden>:

> *** This bug is a duplicate of bug 215499 ***
> https://bugs.launchpad.net/bugs/215499
>
> Can anyone please advise what else to do besides installing libglib2.0-0
> (2.16.3-1ubuntu3), to make the fix work.
>

Try restarting Nautilus with the command "killall nautilus" (alt+f2 or in a
gnome-terminal).

--
Marcelo Ramos

Drew (dkrix) wrote :

Thanks, Ramos for trying, but problem persists.

Tried as you say -- no fix. Tried rebooting ubuntu -- no fix.
Noticed another package libglib2.0-data - installed new vrsion of that as well - still no change to nautilus.
Synaptic reports these packages now have versions ending in ...ubuntu3.

note: just realised - I am copying files within fat32 partition. (only just really realised this page is headed ... ntfs ...)!

Dave Vree (hdave) wrote :

Confirming that this bug is fixed in Hardy Proposed repo. My many thanks to those addressed this!!

@Drew -- Did you enabled the "proposed" repository? In synaptic pick Settings|Repositories then go to the "Updates" tab and and check "Pre-released updates". Click OK then hit the "reload" button on the toolbar.

Beware that this is going to upgrade your kernel and 100 other things...though i can say I have been running this way for months with very little negative side effects.

Drew (dkrix) wrote :

Thanks, HDave, for your comment. Especially that there is hope at the end of all this...

However, I already did that. I only allowed the upgrade to the libglib packages, though - but no dependencies showed...

Anyway, my synaptic reports that the package was upgraded, and the problem persists.

Perhaps the fix does not work on fat32?

Maybe I have to upgrade everything? I'll try that, since HDave did that & reports a fix with "very little" side effect.

Drew (dkrix) wrote :

That doesn't work, either. :(

I'd say, thanks for those who have made progress on this issue, but am worried by the optimism above:

** .. this bug is fixed***

in several posts. ==== PLEASE don't stop the good work yet! ====

Drew (dkrix) wrote :

ps: Sorry to dampen anyones spirits, but the latest version (installed 1/2 hr ago) of gnome commander also does not preserve dates on copy (at least, not all the time - only tried it on one file - but working only sometimes isn't working).

I just tested with a FAT32 USB MP3 player. Timestamps are preserved here, please see the screenshot.
Please post the output of apt-cache policy libglib2.0-0.
Mine:
$ apt-cache policy libglib2.0-0
libglib2.0-0:
  Installiert:2.16.3-1ubuntu3
  Mögliche Pakete:2.16.3-1ubuntu3
  Versions-Tabelle:
 *** 2.16.3-1ubuntu3 0
        400 http://archive.ubuntu.com hardy-proposed/main Packages
        100 /var/lib/dpkg/status
     2.16.3-1ubuntu2 0
        900 http://archive.ubuntu.com hardy-updates/main Packages
     2.16.3-1 0
        500 http://archive.ubuntu.com hardy/main Packages

Drew (dkrix) wrote :

Thank you for taking this seriously.
here's my versions:
drew@cthulhu:~$ apt-cache policy libglib2.0-0
libglib2.0-0:
  Installed: 2.16.3-1ubuntu3
  Candidate: 2.16.3-1ubuntu3
  Version table:
 *** 2.16.3-1ubuntu3 0
        500 http://us.archive.ubuntu.com hardy-proposed/main Packages
        100 /var/lib/dpkg/status
     2.16.3-1ubuntu2 0
        500 http://us.archive.ubuntu.com hardy-updates/main Packages
     2.16.3-1 0
        500 http://us.archive.ubuntu.com hardy/main Packages
And here's the original of a folder contents (see next post for copy)

Drew (dkrix) wrote :

continued: attached is a copy of the same folder.
Note all the date/times have been altered.
Copied using copy/paste in Nautilus.
Folder and copy are both in the same fat32 drive (not a USB).

Thanks.

The ntfs-3g bug is fixed - see Comment 18. Marking as fix released.
The nautilus/gvfs/glib problems are tracked in Bug #215499.

Changed in nautilus:
status: New → Invalid
Changed in ntfs-3g:
status: Invalid → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers