Firefox/Nautilus losing mtime stamp on file copy to folder

Sorry, Steve, don't know how this got here. I marked it invalid for you.

Why did you close the bug by marking it invalid? And do not assign it to yourself unless you intend to fix it yourself.

I can confirm the bug, the timestamp is lost when dragging and dropping from Firefox to the Desktop, but is preserved when I use wget. Not sure it is a Firefox bug, but the Firefox crowd might know who's to blame.

Tormod Volden wrote:
> Why did you close the bug by marking it invalid? And do not assign it to
> yourself unless you intend to fix it yourself.
>
> ** Changed in: firefox (Ubuntu)
> Assignee: kpoole (ken-poole) => (unassigned)
> Status: Invalid => New
>
>
Just for the record and because I really hate to leave questions
unanswered, having given up on the bug and being unfamiliar with the
system I hoped that I'd find an option to simply close a bug that was
assigned to me, likening the bug tracking system to the trouble tracking
systems I was used to. It's not.

Making it invalid was the last hope that the system would then clear it
out. I wouldn't expect the system to hang onto invalid bugs.

Thanks for confirming the bug.

the issue is a gvfs one, see http://bugzilla.gnome.org/show_bug.cgi?id=547133 which has some details

the bug has been fixed upstream now

This bug was fixed in the package gvfs - 0.99.6-0ubuntu1

---------------
gvfs (0.99.6-0ubuntu1) intrepid; urgency=low

  * New upstream version:
   - Better cross-backend copy/move logic. Now will perform an actual file
     system move if possible, even when the source and target are handled
     by different backends
    - Now requires libsoup >= 2.23.91.
    - Bug fixes
    548841 - Incorrect usage of plural forms in gphoto backend
    547133 - Getting mtime over http backend is broken (lp: #247980)
    538573 - lastmodified uses ISO 8601 date/time where it should use http-date
    549253 - error path leaks
    549553 - gvfs mangles uri for unhandled schemes
    550100 - gio uses 10^3 base (SI) for volume names
    529971 - Restore from trash appears to do a file copy (lp: #222150)
    RH 460223 - gnome-mount no longer automatically opens LUKS-encrypted
    partitions

 -- Sebastien Bacher <email address hidden> Tue, 02 Sep 2008 11:49:45 +0200

Launchpad Bug Tracker wrote:
> This bug was fixed in the package gvfs - 0.99.6-0ubuntu1
>
> ---------------
> gvfs (0.99.6-0ubuntu1) intrepid; urgency=low
>
> * New upstream version:
> - Better cross-backend copy/move logic. Now will perform an actual file
> system move if possible, even when the source and target are handled
> by different backends
> - Now requires libsoup >= 2.23.91.
> - Bug fixes
> 548841 - Incorrect usage of plural forms in gphoto backend
> 547133 - Getting mtime over http backend is broken (lp: #247980)
> 538573 - lastmodified uses ISO 8601 date/time where it should use http-date
> 549253 - error path leaks
> 549553 - gvfs mangles uri for unhandled schemes
> 550100 - gio uses 10^3 base (SI) for volume names
> 529971 - Restore from trash appears to do a file copy (lp: #222150)
> RH 460223 - gnome-mount no longer automatically opens LUKS-encrypted
> partitions
>
> -- Sebastien Bacher <email address hidden> Tue, 02 Sep 2008 11:49:45
> +0200
>
> ** Changed in: gvfs (Ubuntu)
> Status: Fix Committed => Fix Released
>
>
I notice this is fixed in Intrepid. I'm running Heron and had planned
to for a while yet. Is there any hope that this will be backported to
Heron?

I'm going to download the Intrepid beta to see if this is really fixed
as expected and decide from there if this is enough to switch from heron
earlier than planned. I have found an inelegant workaround in a Firefox
add-on while I'm in Heron.

I've had problems with Beta 2, similar to this.

When I copy files from my windows machine via SCP or SFTP files to my server, or drag and drop via windows explorer, most of the time the file names have preserved timestamps. The odd occasion, the time stamps change to the current time.

What is really bothersome is that the timestamp on my file folders change to the current time, even if they were created years ago. The creation date and the modification date become the same (i.e. the current date).

This is quite the bug, and is really bad for trying to archive things or find things by date.

Okay, this has gotten silly. The problem was reported, a fix released for Intrepid but not backported to Hardy two years ago. The last previous update before it was just upgraded to medium was over a year ago and I think all of us LTS types have probably upgraded from Hardy to Lucid by now. I actually just did last weekend after waiting for the point release. I've tested the behaviour I was reporting as a bug and find that it works as expected in Lucid.

Let's just call this fixed and close it in such a way that it can't be updated again.