Nautilus not preserving timestamps

[gervin23]

Timestamps are not preserved when copying files/directories via Nautilus. Reproducible by mounting an ext3 partition and copying to local home directory. This behavior worked as expected in 7.10 by preserving timestamps, whether cross-partition or the same partition.

[gervin23 (gervin23)]

Oops, this is 8.04 beta up-to-date as of April 10

[Psy[H[] (vovik-wfa)]

Confirming!!!
Hardy, fully up to date, relative to this message.
generic and rt kernels

Not only Nautilus looses timestamps, cp command also does.

can't fully use my laptop because of this, usual file sync with desktop totally wrecked.

[Mana$_ubu (vadfad)]

Confirmed.
Fix this, please.

[Psy[H[] (vovik-wfa)]

Just tested gnome-commander... works OK. so, problem is in nautilus & cp

! Until this bug is fixed, I recommend to use gnome-commander instead of nautilus in order to save timestamps !

[Sebastien Bacher (seb128)]

Thank you for your bug report. That's not really a bug, the standard cp behaviour is the same, having an option to select that would be nice though

[Psy[H[] (vovik-wfa)]

wishlist? well... i wish not to loose my time based files&folders structure

is there a way to manually tweak gvfs to safe behavior for now?

[Sebastien Bacher (seb128)]

not right now, that's an upstream request, not sure if the current behaviour is a design decision or not

[Sebastien Bacher (seb128)]

That is being discussed upstream on http://bugzilla.gnome.org/show_bug.cgi?id=515777

[gervin23 (gervin23)]

Thanks Sebastian, I didn't think to look over there. I can't believe the discussion has been dragging on for over 2 months now.

[taj (othertaj)]

Gnome-bugzilla is too high-level for the average ubuntu user (like me)
Therefore I truly hope that the resolution of this bug will be used for an updated package in ubuntu 8.04 LTS given its LTS status.

Nautilus should preserve timestamp by default wherever possible, in local system file copying (Ext3, fat32, NTFS, all FS where possible, workaround: gnome commander) and (s)ftp (workaround: gftp). If other gnome programs and command line can do it, Nautilus should be able to do it as well. If there were no workarounds available I would have to switch to windows for file copying, because I do not want to lose timestamp info.

I don't see the the advantage of NOT preserving the timestamp, but if there would be an advantage this should only be possible as an option, and certainly not by default.

[Psy[H[] (vovik-wfa)]

Good news: in Gnome Bugzilla this bug was reassigned to GIO, and work on the patch has started. Hope an upgrade for Ubuntu will be packaged as soon as possible.

offtopic: please, do not think in the ways of paper bureaucracy. This is really bad way of thinking. I live in Russia, so I know what I'm talking about.
Identical digital copies are not the documents (plural), they are the document (single). So timestamps must be also identical, until file changed.

[Vitaliy (vitalx)]

Confirmed.
Fix this, please.

[oscar (garcia-unbc)]

Maybe it is not a Nautilus bug? Please look at http://ubuntuforums.org/showthread.php?t=805095

[over 5000 (over5000-deactivatedaccount)]

The upstream progress and patch (see http://bugzilla.gnome.org/show_bug.cgi?id=515777) seem to be pretty nautilus-centered, though.

[Pedro Villavicencio (pedro)]

it's a glib one. re assigning.

[Pedro Villavicencio (pedro)]

kbit, yes there's a couple of patches upstream but they need to be accepted first.

[oss_test_launchpad (oss-test-launchpad)]

Will this be fixed after the patches have been accepted?

[Sebastien Bacher (seb128)]

we will consider a backport once upstream agree on the changes

[over 5000 (over5000-deactivatedaccount)]

That's great! Thank you!

[Psy[H[] (vovik-wfa)]

...tired to fireup gnome-commander or grsync every time I need to copy something important. Hope fix will be delivered soon.
It is the only problem that prevents me from enjoying Hardy. Fix it, and the system will be close to perfectness!

[Sebastien Bacher (seb128)]

that's not a nautilus bug

[oss_test_launchpad (oss-test-launchpad)]

No one said it is. I only marked that it *affects* Nautilus.

[Sebastien Bacher (seb128)]

don't open a nautilus bug if that's not a bug in the nautilus code, having the glib one is enough

[Tormod Volden (tormodvolden)]

Looking at the upstream "progress" doesn't really reassure me. There was a patch in April, a few developers commented on it middle of May. Isn't this a case where we just have to fix it in Ubuntu as soon as possible, and rather reharmonize with upstream whenever they will reach consensus on their ideal fix? Changing this behaviour from one release to another and refer to it as "design decision" would be quite arrogant towards normal users using Ubuntu for real work.

The upstream gio-access-time.diff patch applies on Hardy glib2.0. I'll try it out on my PPA.

[Tormod Volden (tormodvolden)]

glib2.0 packages with this patch applied are available in my PPA.

[over 5000 (over5000-deactivatedaccount)]

So how can I use the modified package until ubuntu finally choses to take the patch over?

I agree about the bad signs of those (non-)happenings upstream.

[Psy[H[] (vovik-wfa)]

THANK YOU!
downloaded and installed. Copies perfectly now!
At last 8.04 is fully operational! )))))) now I can upgrade it on all my computers from 7.10....

[Sebastien Bacher (seb128)]

could you not abuse the official versionning otherwise the next ubuntu update will not be installed for user installing your version? also you should better wait for an official fix rather than push random changes to users

[Tormod Volden (tormodvolden)]

> could you not abuse the official versionning otherwise the next ubuntu update will not be installed for user installing your version?

If you check better you'll see that the PPA version has ~tormod tagged to it so it will indeed be updated at next Ubuntu update. The attached debdiff has not, since I posted it as a candidate for hardy-proposed.

> also you should better wait for an official fix rather than push random changes to users

I am not "pushing", not even recommending or explaining anyone to install them :) It's not "random", it's the best shot so far from upstream. They are not totally happy with it since they are concerned with ACL and more exotic filesystems etc which is not so important for normal desktop users. Actually, when copying from a removable drive, I never want to copy ACL, only the time stamps. Can't be much worse than the current behaviour IMHO.

To wait for the "official" fix from upstream is not a good option, that might end up very late and IMO it's already too late. I have unfortunately already copied much data without checking the timestamps since I installed 8.04. This patch fixes this 99% for me and probably many others. I am not saying that this is a perfect fix, but it's a step in the right direction and we can update again to the perfect fix later.

[Jeff Zheng (zhengzhe79)]

Can I ask what is a PPA version? :) and how do I download it? Thanks.

[Psy[H[] (vovik-wfa)]

apt line for Tormod Volden's PPA is:
deb http://ppa.launchpad.net/tormodvolden/ubuntu/ hardy main

but be careful!!! My nautilus just crashed. I will try to reproduce it and grab a terminal output...
That was in messages log:
nautilus[6925]: segfault at 00000000 eip b75bb307 esp bf8cb7f4 error

[Tormod Volden (tormodvolden)]

> but be careful!!! My nautilus just crashed.

I saw a similar crash _before_ I installed the patched packages, so I don't think it is related.

[Sebastien Bacher (seb128)]

nominating for hardy, I'll look at fixing that one

[Sebastien Bacher (seb128)]

that's not a nautilus issue

[Labyrinth (klaus-bitto)]

Great! Thanks for your commitment, Sebastien!

[Launchpad Janitor (janitor)]

This bug was fixed in the package nautilus - 1:2.23.4-0ubuntu1

---------------
nautilus (1:2.23.4-0ubuntu1) intrepid; urgency=low

  * New upstream version:
    - Fix background extension submenus for background context menus
    - Fix thumbnailing
    - Always re-thumbnail if a file without any thumbnail changes
    - Always re-thumbnail if a failed thumbnail is not up to date
    - Make zoom level specifications consistent (33% vs. 25%),
      round to 66% rather than 67%. (lp: #151811)
    - Never hide hidden or backup files in trash (lp: #127046)
    - Always copy file entire metadata when copying.
      Fixes timestamp preservation. (lp: #215499)
    - Remove desktop emblem from desktop directory,
      since the folder now uses a desktop icon

 -- Sebastien Bacher <email address hidden> Tue, 17 Jun 2008 09:53:48 +0200

[Sebastien Bacher (seb128)]

reading the upstream comments the glib and nautilus changes should be equivalent. the glib change has a clear behaviour though and is what alexander who wrote the code suggested so seems to be a good option for a stable update, gio is not used by many applications in hardy anyway and the change should not create other issues there

[Steve Langasek (vorlon)]

confirming for SRU because this is a regression from 7.10.

[Steve Langasek (vorlon)]

Accepted into -proposed, please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

[Jakob Unterwurzacher (jakobunt)]

Looks good! (tested ext3 -> ext3, ext3 <-> encfs)

Note for other testers: The fix is in package libglib2.0-0 .

[Pedro Villavicencio (pedro)]

Verification done:

- test with glib (2.16.3-1ubuntu2), created a file on another partition with date of last year, after copy it to my desktop folder the timestamp is not preserved.
- test with glib from proposed (2.16.3-1ubuntu3), same file from that partition with an old creation date, after copy it to my desktop folder the timestamp is preserved, also tested with replace/move and it works fine, bug is fixed, thanks.

[philinux (philcb)]

Just done all proposes update.

Connected 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)]

(I started in the duplicate bug page, for the same problem with ntfs partitions)

Really appreciate that someone(s) is/are attempting to fix this issue. But...

Have applied the supposed fix (2.16.3-1ubuntu3), rebooted etc.... Bug still active. Then applied all changes on the proposed list (relying on synaptic), just in case, rebooted. Still a problem.

So, the problem is NOT fixed - at least not for all systems - from the previous post, I'm not the only sufferer.

My copy problem is within fat32. Bug still presents for that filesystem.

[tberger (thilo-berger)]

Hi,
it works fine.

Thanks.

Regards

Obelix

[Graeme Harrison (prof-post)]

I think it is REALLY URGENT that a general fix get out there for all Ubuntu users. I (and everyone else) am wildly promoting 8.04 as the Vista alternative... and it strikes me as plain silly to not fix this problem pronto. It is so off-putting to use an OS that cannot keep file dates correct.... that I'd suggest fixing it in Nautilus if needs be, and if/when lower level modules are fixed to no longer cause the problem, THEN remove the workaround in Nautilus.
The suggestion that it has anything to do with 'design decisions' is a FURPHY... There is NO JUSTIFICATION for 'touching' (ie redating) a set of files simply because they are copied unaltered to another location (esp on same computer). The bug is presumably that, as permissions are added to files not in *nix file system, someone decided to 're-date' file, as if someone had edited something.... but it will always be just a bug. The Russian commentator was right - when you have two copies of a file (unaltered) you have two instances of the one file and NOT two files of different dates!
The fact that you can't 'reliably' copy photos from your camera, or files off a removable drive etc is a SEVERE error for any user. Yes, you can use Archive Manager to do a tar.gz zip file of them and then Extract them on the target drive... but it slows down a file copy 50x. The error is so severe as to prevent average users from using the OS... so it is critical that it be fixed FOR ALL USERS quickly.
Graeme (30 years IT experience, former Harvard Consultant to The White House on IT policy, on team of five which developed first electronic spreadsheet - Visicalc - at Harvard Business School in 1978, etc)

[Sebastien Bacher (seb128)]

did you read this bug before commenting? the fixed version has been uploaded some days ago already, if you still have an issue using it you likely have an another issue and should open a new bug describing it in details

[philinux (philcb)]

I have applied all the updates and I'm still getting the system date/time when the system imports files from my camera instead of the creation date.

It was copying files from a usb stick that initially got my attention.

[Sebastien Bacher (seb128)]

camera import is a different case, you should open a bug against the application you are using

[Martin Pitt (pitti)]

Copied to hardy-updates.

[Martin Pitt (pitti)]

Please fix this in intrepid ASAP.

[Sebastien Bacher (seb128)]

the bug has been fixed differently in nautilus in intrepid

[Zamiere Vonthokikkeiin (kikkeartworx)]

If it's not a nautilus bug, why fix it in itrepid?

[kpoole (ken-poole)]

I'll need some help getting this to the right group but it seems there is a larger problem here.

People have reported a "bug" or "feature" in that Nautilus was not preserving timestamps, in particular, the file modification date, when doing file copies. I see the comments that this has been fixed and I can confirm that in Nautilus I can copy a file from one folder to another and the modification dates are preserved but ... and this is where it gets sticky ... I can see that other are having troubles with camera import and I've noticed that this same loss of modification timestamp is happening when I copy an image from Firefox to a folder or to the Desktop. Does Nautilus handle copies from applications to the Desktop as well?

In 7.10 and previous and only where I could drag and drop an image from Firefox to a folder, the timestamp was also preserved and that behavior has changed as well in 8.04.

You may not consider this important but it says to me that something has changed deeper down than just Nautilus. You've changed Nautilus to preserve timestamps but the behavior continues with other applications and I doubt that each of these other applications have each decided to not preserve the modification date timestamp on their own at the same time. Unless, Nautilus is managing all these copies and the patch to preserve timestamps has only been written to correct the problem when copying between folders.

There are a few of us who use these timestamps to help keep order in our collections of images and when I moved to Ubuntu and found these were preserved in so many cases, it was like a Godsend. Please do find where this "bug" or "feature" can be correctly moved to preserve the dates across the applications.

Many Thanks.

[Sebastien Bacher (seb128)]

those camera import issue are an another issue, you should open a bug on the application you are using rather, this bug was about the new gio library that nautilus is using in hardy, neither of the photo managing applications in the standard hardy installation are using it so the issue is a different one and likely to just be a similar bug in an another software

[kpoole (ken-poole)]

My comment wasn't just about the camera issue. I'be found the same change in behavior when copying a file from Firefox to the desktop or a folder.

But, give me a suggestion then. Do I open a bug with the Firefox people or with the Gnome people or with the Ubuntu people? It just seems odd that several different applications all report the same problem, the same change of behavior at the same time as 8.04 comes out. Did they all decide not to preserve timestamps at the same time or is it something in the system? Who handles copying a file from an application window to the Desktop or a folder?

I notice that there is always a copy of Nautilus in the background and a new one will start up when the old one is killed. That prompts me to believe that, perhaps, Nautilus is overseeing the copying functions in the Gnome environment. Unfortunately, I'm running on empirical data so I can only work with what I see happening and telling me something isn't so doesn't change that.

[Marcelo Ramos (marcelor)]

On Sat, Jul 12, 2008 at 3:33 PM, kpoole <email address hidden> wrote:

> My comment wasn't just about the camera issue. I'be found the same
> change in behavior when copying a file from Firefox to the desktop or a
> folder.
>
> But, give me a suggestion then. Do I open a bug with the Firefox people
> or with the Gnome people or with the Ubuntu people? It just seems odd
> that several different applications all report the same problem, the
> same change of behavior at the same time as 8.04 comes out. Did they
> all decide not to preserve timestamps at the same time or is it
> something in the system? Who handles copying a file from an application
> window to the Desktop or a folder?
>
> I notice that there is always a copy of Nautilus in the background and a
> new one will start up when the old one is killed. That prompts me to
> believe that, perhaps, Nautilus is overseeing the copying functions in
> the Gnome environment. Unfortunately, I'm running on empirical data so
> I can only work with what I see happening and telling me something isn't
> so doesn't change that.
>

It would be interesting to know if the problem happens with KDE too. That
can give good
hints about the origin of the behaviour.

Regards.

--
Marcelo Ramos

[Sebastien Bacher (seb128)]

you should open a firefox bug upstream or on launchpad, as written before the issue described there is due to the new gio glib code but firefox is not using it so the bug you are having is a different issue

[kpoole (ken-poole)]

It's an easy thing to say when the person you're saying it to can't refute it. The combination of behavior changes is an odd coincidence, though. It speaks of multiple points of failure which is less likely than a single point of failure. (I know, you don't think anything has failed but we who have come to depend on a particular behavior do.)

As far as the test of dragging and dropping from Firefox to Konqueror in Kubuntu, for example, it doesn't work as it does in Ubuntu with Nautilus. The nice behavior in Gnome/Firefox/Nautilus was that you could drag and image from a webpage in Firefox to a folder in Nautilus or the Gnome desktop and the drag would pull in the filename and timestamps along with the file. I'm using Ubuntu with both Nautilus and Konqueror (there are features under each that the other doesn't do that I like.) and under Gnome/Konqueror you have to stop and type in a filename for the dragged file.

To be fair, I'll install a pure Kubuntu machine and see what happens. If the behavior on Kubuntu has changed so that a drag and drop from Firefox to a folder acts as I expected on Gnome/Nautilus then I'll likely just switch from Ubuntu to Kubuntu.

[Crossland (rvarela)]

Ubunto 8.04 with last update still has nautilus 2.22.3

How can I get nautilus 2.23.4 with the bug fixed?

This is a nasty bug!

[Tormod Volden (tormodvolden)]

Crossland, this bug was fixed in Ubuntu 8.04 with libglib2.0-0 2.16.3-1ubuntu3 in hardy-updates on 2008-06-25.

[Crossland (rvarela)]

Yes, permalink, thank you... but if the destination of a copy operation is NTFS, the date is lost. Both last modified date and last accessed date are set to the current date.

[Crossland (rvarela)]

Sorry, meant

Yes, Tormod, thank you... but if the destination of a copy operation is NTFS, the date is lost. Both last modified date and last accessed date are set to the current date.

[Sebastien Bacher (seb128)]

the ntfs case seems to be a different one and you should not comment on a closed bug about it

[Crossland (rvarela)]

This is a free world.

I'm sorry for breaking the rules of the establishment.

But how come I should know that it "seems" to be a different case. It may be or it may be not.

[Sebastien Bacher (seb128)]

because there is already some comments on the bug which state the issue described there has been fixed in the code and that if you still have something not working correctly you should open a new bug

[philinux (philcb)]

I've raised a bug for the camera issue. Bug 242647.

But it doesn't seem to have had any attention. I had to buy a card reader and use cp.

[kpoole (ken-poole)]

philinux wrote:
> I've raised a bug for the camera issue. Bug 242647.
>
> But it doesn't seem to have had any attention. I had to buy a card
> reader and use cp.
>
>
Yes, there's a core interest here and any thing outside of that core is
disregarded. I actually found a separate Firefox add-on that takes care
of the problem I was having. It's a shame that a behavior that seemed
to be part of Nautilus has to be taken over by add-ons to other programs.

[Sebastien Bacher (seb128)]

the issue is not a lack of interest but a lack of manpower, there is thousand bugs opened and only a small team to work on those, the photo issue is a different one and seems to be a libgphoto one, see bug #49906 for example, the issue is not new in hardy

[kpoole (ken-poole)]

Sebastien Bacher wrote:
> the issue is not a lack of interest but a lack of manpower, there is
> thousand bugs opened and only a small team to work on those, the photo
> issue is a different one and seems to be a libgphoto one, see bug #49906
> for example, the issue is not new in hardy
>
>
Again, you've tied this to a problem in a photo package, not me. The
problem I tried to report was that files dragged from Firefox to a
directory opened with Nautilus were no longer retaining the last
modified times available from the web site. You've always tied this to
someone else's problem with a camera/photo package.

As it turns out, I've found a workaround but it's not as elegant as the
simple drag and drop that was available and the problem as I saw it
still exists. I've reported it as a general problem and that I cannot
identify a particular package because some what to call it a Firefox
problem, others a Nautilus problem and others a photo package problem.

[kpoole (ken-poole)]

Sebastien Bacher wrote:
> the issue is not a lack of interest but a lack of manpower, there is
> thousand bugs opened and only a small team to work on those, the photo
> issue is a different one and seems to be a libgphoto one, see bug #49906
> for example, the issue is not new in hardy
>
>
Your referenced bug 49906 has nothing to do with my mentioned problem
with Firefox. You keep trying to re-direct my problem with Firefox as a
problem with some program that imports pictures from cameras.

As a test I've re-installed Ubuntu 7.10 on a machine and confirmed that
when a file is dragged and dropped from the Firefox window to a
directory in a Nautilus window the last modified time from the web site
is preserved. I then installed Firefox 3.0 on that Ubuntu 7.10 machine
and find that the last modified time stamp IS STILL PRESERVED in such a
drag and drop operation. Now I guess I'd have to see if they've
backported the version of Nautilus from Ubuntu 8.04 to 7.10 to see if
the time stamp preservation behavior is still preserved. Would that
indicate that the problem is not with Firefox?

And, please do not tell me this is something to do with camera photo
importing. I'm not using a camera, I'm not importing photos from a camera

[Sebastien Bacher (seb128)]

the bug you are commenting on was an issue about nautilus standard copies, no about photos, not about firefox, and it has been fixed. if you have an another issue open a new bug as it has been done for the photo copies timestamp issue

[kpoole (ken-poole)]

Sebastien Bacher wrote:
> the bug you are commenting on was an issue about nautilus standard
> copies, no about photos, not about firefox, and it has been fixed. if
> you have an another issue open a new bug as it has been done for the
> photo copies timestamp issue
>
>
And If I do open one it would be under Nautilus, Correct? As I don't
see it as a Firefox Problem.

But you don't see it as a Nautilus problem. So it would be ignored.

However, there is a bug open under 247980 and it seems to have been
ignored so far.

Of course, I'm new to reporting bugs because this is the first change in
behavior in a negative direction that I've run into so far since
starting with Ubuntu 6.6.

Anyway, you've convinced me that it's useless to pursue it here, maybe
period. I'll just have to get used to using wgets instead of drag and
drops.

[Sebastien Bacher (seb128)]

nautilus can have several issues, why do you insist to want to use this code issue which was a libglib bug and has been fixed now? bug #247980 seems to describe this one so you should rather comment on this one, not sure why the firefox maintainer didn't reply but I expect there is just too many bugs being open against firefox for him to work on everything

[kpoole (ken-poole)]

Sebastien Bacher wrote:
> nautilus can have several issues, why do you insist to want to use this
> code issue which was a libglib bug and has been fixed now? bug #247980
> seems to describe this one so you should rather comment on this one, not
> sure why the firefox maintainer didn't reply but I expect there is just
> too many bugs being open against firefox for him to work on everything
>
>
I expect the Firefox Maintainer hasn't responded to it because copying
files saves the last mtime stamp from the site when doing a copy with
Firefox 2 or Firefox 3 working with Nautilus 2.20.0 under Ubuntu 7.10
and the last mtime is lost when doing the same operation from either
Firefox 2 or Firefox 3 when copying to a folder in Nautilus 2.22.3 under
Ubuntu 8.04

To make sure this behavior is as reported I have two machines, one with
Ubuntu 7.10 and Firefox 2 and Firefox 3 and another separate machine
with Ubuntu 8.04 and Firefox 2 and Firefox 3.

Why should the Firefox maintainer think there is something wrong with
Firefox when the two versions do the job with Nautilus 2.20.0 under
Ubuntu 7.10 but not with Nautilus 2.22.3 under Ubuntu 8.04? What looks
like the common point of failure among these programs?

I'd love to have you explain it to me offside if you want. The
questions might be "In a drag and drop operation who ends up taking
charge of the copy function, the sender, Firefox 2 or 3, or the
receiver, Nautilus? If it's the sender, Firefox 2 or 3, then why do
they send different information to Nautilus 2.20.0 and Nautilus 2.22.3?
If it's the receiver, then when after 2.20.0 did Nautilus stop asking
for the complete information about the files coming from Firefox 2 or 3?"

No, sorry, I haven't tried backporting Nautilus 2.22.3 to Ubuntu 7.10 yet.

<email address hidden>.

[Michael Nagel (nailor)]

(i am using a up-to-date hardy system)

when displaying a site in firefox 3 and dragging a image to the desktop a link to this page is created automatically without any user interaction. (doesnt seem to be a good default for images to me, but i dont really care).

when dragging something other (i tried a apache dir listing and found some .Z-archives and used them) items: NAUTILUS himself spawns an untitled modal window (i am not a fan of these) looking like this:

<missing title>
Download location?
You can download it or make a link to it.
<make link> <cancel> <download>

[hint: one could carefully hint what location we are talking about.] however this clearly indicates to me that nautilus only got the URL from firefox and is now completely on its own.

and now... finally... if one clicks "download" at this point... the file is downloaded and stored with current time as atime and mtime.

this behavior seems to be a massive failure to some people and i agree that one might call this a bug. however it is most likely not the same bug as the bug discussed here what leads me to the conclusion that it should be discussed elsewhere. (elsewhere means here in launchpad, just in another bug report). should it turn out at some point that it IS the same bug we can unite them easily, then. but right now i do not think this is going to happen... but i might be mistaken, of course.

should this other bug report not gain as much attention could that be an indication that either most people simply dont care or that the problem is described poorly/not marked effecting the relevant packages (important point). but neither is a reason to conquer this bug report only because some people are paying attention here.

final point: i am well aware that some valid bugs are not getting much attention and are not fixed in a long time. but in a mainly (err, universally :) ) community-driven project like ubuntu there is simply not the manpower (and in some way, the money, probably) to change this - right now.

[Sebastien Bacher (seb128)]

why did you open the other bug on firefox if you think that's not a firefox issue?

[kpoole (ken-poole)]

Sebastien Bacher wrote:
> why did you open the other bug on firefox if you think that's not a
> firefox issue?
>
>
It can't be opened as a Nautilus problem. All your previous arguments
were that it must be something other than Nautilus. I'm unfamiliar with
the process of opening a new bug so if it became a Firefox problem that
might be because I put Firefox in the name.

At this point I'll just say that it's all a wash and cancel the bug
report and stick to using wget. It's a dang nuisance compared to what
was available before but less of a problem than trying to satisfy the
bug reporting process.

I had written a longer note about this but, really, there's no point.

[Tormod Volden (tormodvolden)]

kpoole, please let us take this in bug #247980. I think Sebastien just means that you should not discuss it in this bug report, since it is closed.

[philinux (philcb)]

Intrepid clean install. Just transferred files with gthumb and the timestamps are not preserved. However copying with nautilus, while painfully slow keeps the correct timestamps.
Canon G5 camera. And it gets mounted correclty.

[kpoole (ken-poole)]

philinux wrote:
> Intrepid clean install. Just transferred files with gthumb and the timestamps are not preserved. However copying with nautilus, while painfully slow keeps the correct timestamps.
> Canon G5 camera. And it gets mounted correclty.
>
>
Now I see why Sebastian was having such a time trying to keep the camera
related issues separate from the Nautilus related issues.

This was a bug report started for "Nautilus NOT preserving timestamps"
in Hardy Heron. Your comment about your troubles with gthumb indicates
that Nautilus IS preserving timestamps in Intrepid Ibex.

As was suggested to me so long ago. Look for a gthumb bug to append
your comment to or start a new gthumb bug.

[philinux (philcb)]

I added the comment to say that nautilus is indeed preserving timestamps. I've raised a gthumb bug.

[BassKozz (basskozz+ubuntu)]

Not working for me: http://ubuntuforums.org/showthread.php?t=1006997

[Bill Smith (bsmith1051)]

Fresh install of Intrepid, mounted old 8.04 hard drive (ext3) and copied a huge photo collection to the new drive (i.e., via Nautilus) -- ALL TIME STAMPS RESET. I still have the old drive (w proper time-stamps) but I've also done a lot of work on the 'new' photo collection so now I'm stuck, not sure what's the best way to fix this...

[BassKozz (basskozz+ubuntu)]

Hey Bill,

I had a similar issue (see the thread link above your post) and the fix for me was:
rsync -ta orig_dir/* new_dir/

HTH,
-BassKozz

[Sebastien Bacher (seb128)]

the bug has been fixed, don't reopen it if you have a similar issue but rather open a new bug

[BassKozz (basskozz+ubuntu)]

New bug filed: https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/315552

[david6 (andrew-dowden)]

New bug files: Bug #738462