I think this is caused by the same issue described in bug #514084.

This is by design. cp does the same. We do copy the mtime on move though, even when move is implemented as copy + delete.

OK, You're right, but previous nautilus used to copy the mtime too. I mean in sftp connections.

*** Bug 525622 has been marked as a duplicate of this bug. ***

please bring back the old behavior. *Losing data* (that is, the modification time) makes no sense. This is stupid windows-like behavior in my opinion, I was so delighted when I switched a few years ago and discovered that nautilus preserved modification times!

Consider the following use cases:
- a webmaster updates his website by copying files from a folder to another. This website has some php function that prints the last modified time of the webpage. The reported time will be wrong.
- the data itself has never changed (just try md5suming it and see), why the heck should it marked as changed on the filesystem?
- someone backups his file by copying them. All the modification times are lost.
- the "sort by last modified" option in nautilus is now USELESS after copying files
- a photographer offloads pictures from his camera. There was no exif data, or it was wrong, or the software/script he uses to rename the files does not care about exif. His photos are now in chaos.

Please, bring it back! Losing information such as the modification time is not good design, no matter which way I look at it!

I second Jean here. As a web developer too, the 'order by date' stuff is useless and lead to confusion.

Any chance to get old behavior back?

i agree with Jean-François and jonh
It's hard to believe that this drawback actually is a functionnality

*** Bug 526390 has been marked as a duplicate of this bug. ***

People, I would like you to name a SINGLE file manager that has the same behavior as nautilus-2.22

Windows Explorer (at least on XP) preserves attributes on copy.
So does Konqueror.
So does did nautiuls-2.20.
So does Total Commander, mc, etc.

(In reply to comment #2)
> This is by design. cp does the same.

Then your design is wrong. The expected behavior for graphical file managers is `cp --preserve`, as can be seen by using any modern file manager in the universe.

Reopening, the new behavior doesn't make any sense, in my opinion. That's like saying we can't copy directories in nautilus just because cp without -r can't copy directories, either. Copying files in nautilus should be like cp --archive, i.e. it should preserve symlinks, mtime, permissions, and copy directories recursively. If you want to close this bug again, please provide a reason from a desktop user point of view.

Created attachment 108968 [details] [review]
nautilus-2.22.1-preserve-metadata.patch

Patch from bug 526390. Makes nautilus act like 'gvfs-copy --preserve' (i.e. cp -p). Note that patching this in nautilus doesn't completely fix the problem, because some gvfs backends (e.g. sftp) do not currently support G_FILE_COPY_ALL_METADATA.

Setting patch as "needs-work" as I don't think we want to copy *all* the metadata.

(In reply to comment #12)
> Setting patch as "needs-work" as I don't think we want to copy *all* the
> metadata.

It does *not* copy all metadata. Have a look at gio source, for example at g_file_copy_attributes() and related functions. The G_FILE_COPY_ALL_METADATA flag only copies the metadata that is 
a. marked as G_FILE_ATTRIBUTE_INFO_COPY_WHEN_MOVED; and
b. marked as writable by the current backend.

Basically, it matches the semantics of "cp -p".

Sorry, I'm a bit confused there:
- the patch is reported as not working for all backends (sftp), as "those backends lack copy_all_thingies"
- it is said that we don't want to copy all metadata?
- ?

Is that patch good enough? I wish I had the skills/knowledge to look at it and figure it out myself.

(In reply to comment #14)
> Sorry, I'm a bit confused there:
> - the patch is reported as not working for all backends (sftp), as "those
> backends lack copy_all_thingies"

Correct. Most (all?) gio backends currently cannot write metadata. The sftp backend currently only writes Unix permissions, but cannot write any other metadata. My patch in bug 527339 adds support for writing date and time modifications to sftp (which is actually not trivial, because of the way the sftp protocol is designed).

> - it is said that we don't want to copy all metadata?

Also correct. For example: we do not want to copy uid/gid over an sftp connection (since the remote machine probably uses differnt uid/gid numbers). However, we do want to copy uid/gid for local copies. This is precisely why my patch uses the G_FILE_COPY_ALL_METADATA flag: that flag tells gio to only copy metadata that are marked as writable and G_FILE_ATTRIBUTE_INFO_COPY_WHEN_MOVED by the current backend.

Digital copying always meant to be lossless.
So current behavior IS THE BUG that leads to DATA LOSS!
And this is the most destructive bug I've ever encountered in Gnome
so, "unconfirmed" - is rather surprising status here.

If it is a designed feature - that is very bad design!

The best way to end this discussion is switchable timestamp preservation, that switched ON by default.

Reassigning to gio. The local file backend does not tell the GIO file operation machinery to copy the mtime file attributes on copies. This is done by passing the G_FILE_ATTRIBUTE_INFO_COPY_WITH_FILE flag for the mtime file attributes.

Created attachment 109997 [details] [review]
Proposed GIO patch

This seems to me the best approach to solve this bug. The patch looks good to me too, though I don't think I'm the right man to review GIO patches :)

(In reply to comment #17)
> Reassigning to gio. The local file backend does not tell the GIO file operation
> machinery to copy the mtime file attributes on copies. This is done by passing
> the G_FILE_ATTRIBUTE_INFO_COPY_WITH_FILE flag for the mtime file attributes.

Question 1.
Would this approach allow you to copy files without copying metadata? In other words, would it be possible (without going through lots of hoops) to replicate both the behavior of 'cp' and 'cp -p'?

Question 2.
What makes mtime so special? Nautilus copying needs to also preserve permissions, uid/gid, the acls, the selinux context, etc.

Question 3.
What is the precise semantic distinction between G_FILE_ATTRIBUTE_INFO_COPY_WITH_FILE G_FILE_ATTRIBUTE_INFO_COPY_WHEN_MOVED? If you add G_FILE_ATTRIBUTE_INFO_COPY_WITH_FILE to every metadata, the two flags will become synonyms.

I always interpreted _COPY_WITH_FILE as "do it like cp" and _COPY_WHEN_MOVED as "do it like mv", and G_FILE_COPY_ALL_METADATA as the switch from "cp-like" to "mv-like" (or "cp -p"-like) behavior.

My humble wish for questions 1 and 2:
Checkboxes in nautilus's properties would be very handy.
Or even hideable small panel next to toolbox in nautilus's window for more operative control of routine actions ;)

could, in case this bug takes longer to fix due to discussions over which metadata exactly to preserve, an additonal "Copy here (preserve attributes)" option in the drag&drop context menu, resulting in plain G_FILE_COPY_ALL_METADATA being |ed to flags (analogous to `gvfs-copy --preserve`) ease the pain for average users? (which are, in the meantime, given brutal workarounds in the web [1])

[1] http://www.linuxformat.co.uk/index.php?name=PNphpBB2&file=printview&t=7529&start=0

For now it would be nice to fix general problem, from which bugreport started, first: make Nautilus preserve timestamps. And then work on enhancements.

To me, the patch to make nautilus use G_FILE_COPY_ALL_METADATA makes more sense than the copy-mtime-by-default patch, if only because we have explicit documentation that says:

 * Normally only a subset of the file attributes are copied,
 * those that are copies in a normal file copy operation
 * (which for instance does not include e.g. mtime). However
 * if #G_FILE_COPY_ALL_METADATA is specified in @flags, then
 * all the metadata that is possible to copy is copied.

I can not really judge all of this because I do not understand what the rationale behind the metadata copy design is [i.e. why this distinction exists in the firs place].

Some weeks Alex suggested in a private email that the solution proposed in comment 18 is the right one, intead of copying of all file attributes (which I explicitly proposed in an email to him).

Maybe we should commit the proposed patch, and just leave this bug report open as a reminder to Alex when he returns from paternity leave.

(In reply to comment #25)
> Some weeks Alex suggested in a private email that the solution proposed in
> comment 18 is the right one, intead of copying of all file attributes (which I
> explicitly proposed in an email to him).

G_FILE_COPY_ALL_METADATA does not actually mean copy all metadata :)

> Maybe we should commit the proposed patch, and just leave this bug report open
> as a reminder to Alex when he returns from paternity leave.

I think the GIO-level patch, although better than nothing at all, is not a good solution.

1. It is bad API: without reading the GIO source, you can never know which metadata get copied on file copy; plus it weakens the distinction between G_FILE_ATTRIBUTE_INFO_COPY_WITH_FILE G_FILE_ATTRIBUTE_INFO_COPY_WHEN_MOVED. Again: with the GIO patch, how would you implement the standard POSIX-like cp?

2. It is too limited: at the very minimum, nautilus must also preserve permissions and ACLs on copy.

3. It doesn't do anything to solve the problem for network transfers (and I would say that preserving date/time on copy over SSH is more important than preserving it for local file operations).

> all the metadata that is possible to copy is copied.
sounds great :)

This is a bug, at least a bug in cp.  The cp man page says that the default is to preserve timestamps:

-p same as --preserve=mode,ownership,timestamps

--preserve[=ATTR_LIST]
preserve the specified attributes (default: mode,owner‐
ship,timestamps), if possible additional attributes: context,
links, all

@comment #28:
this does not mean that the default is to preserve timestamps, it just means that /if you specify -p (without options)/, then mode+owner+timestamps will be preserved. (without -p, nothin will.)

I can't believe it, that is bug is still only marked as Normal. It should be marked a show-stopper. Just have a look around, which operating system, modern or old have this behavior. And please imagine hundreds of thousands users copying the data without knowing that the date-time information is lost on their valuable historical data. 
I deal with photos a lot, and everyday when I want to copy the files from my CF card to ubuntu, I need to open a terminal then do the cp -a manually. 
Please, fix this, I beg you :)

Be sensible. 

The date/stamp we're talking about here is the "Last modification date" of a file.

The file is not modified when copied... just its location.

Why change it and create this mess?

This is a BIG ISSUE!

ramonv

Common sense is not so common... Voltaire

Please, could any member of the development team give us a clear statement whether this is a design decision (by whom?) or a bug that will be fixed as soon as possible?

The current behaviour of Nautilus is not only annoying but can lead to serious data loss as the modification date of a file is usually (in every other file manager I know) a reliable indicator whether a file was modified. 

Maybe someone could have a look at the discussion in https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/215499 additionally.

having this sorted out and maybe changed for 2.22.3 is something that we definitely want to achieve due to the number of complaints.

My comment 24 still stands, despite all the shouting...

> My comment 24 still stands, despite all the shouting...

To be honest I do not know whether it is better to modify GIO or Nautilus, because I still do not know how G_FILE_COPY_ALL_METADATA is supposed to work exactly. Both modifying GIO to use the flag differently, and modifying Nautilus to pass always the flag resolve this issue.

A Nautilus development release is imminent, and everybody wants us to preserve timestamps, so I just committed attachment 108968 [details] [review] to Nautilus, both to trunk and to the GNOME 2.22 branch:

http://svn.gnome.org/viewvc/nautilus?view=revision&revision=14266
http://svn.gnome.org/viewvc/nautilus?view=revision&revision=14267

Let's keep this bug report open until Alex returns. He may have some very distinct semantics in mind that are currently not documented or implemented, and thus reasons why he was against the G_FILE_COPY_ALL_METADATA approach.

http://www.nabble.com/New-nautilus-maintainer---Alex-on-parental-leave-td16158110.html

Christian, just to understand your proposal right: Do you want to leave this bug unfixed until 2009?

Maybe Alexander will be able to answer an e-mail about the meaning of this flag when the child is asleep for a while?

> Christian, just to understand your proposal right: Do you want to leave this
bug unfixed until 2009?

No, I fixed the user-visible bug: timestamps are preserved on copy.

Christian: Thanks for committing the patch! Removing blocker status.

a) I want to reinforce the importance of fixing this bug
b) the "fix" to libglib announced and released (status "proposed") through ubuntu does not completely fix the problem. 
(Reports say it works for some people. It does not work on my system with vfat files. At least one other post confirms lack of universal success.).

Something else that would be nice to have: in older versions of Nautilus, the date/times were preserved for directories as well as files. Now, it's only files which have the dates and times preserved.

Possible to do also for directories?

Hmmm... I agree with most people that we should save mtime on copy. 

The original difference between G_FILE_ATTRIBUTE_INFO_COPY_WITH_FILE and G_FILE_ATTRIBUTE_INFO_COPY_WHEN_MOVED is that the later is meant to be used when emulating a move by using copy and then delete of the original. 

For instance, say you are copying a file that someone else owns. You generally want the copy to be owned by you, so you don't want to copy the uid/gid. When trying to figure out what attributes to copy on a normal copy i looked at the cp default behaviour to select that, which lead me to not copy mtime. However, I can see that this was not a good choice.

However, using COPY_ALL_METADATA in nautilus doesn't sound good either, because that means when you run nautilus as root and copy a file to your homedir it will preserve the old owner, which is not expected.

So, i think the right approach is to tag mtime as COPY_WITH_FILE and drop the nautilus change.

2008-12-09  Alexander Larsson  <alexl@redhat.com>

	Bug 515777 - incorrect date&time on copy
	
        * glocalfile.c:
        (g_local_file_class_init):
	Copy mtime by default
	
        * gfile.c:
	Change docs about G_FILE_COPY_ALL_METADATA to not mention
	mtime as an example.

(In reply to comment #41)
> However, using COPY_ALL_METADATA in nautilus doesn't sound good either, because
> that means when you run nautilus as root and copy a file to your homedir it
> will preserve the old owner, which is not expected.
> 
> So, i think the right approach is to tag mtime as COPY_WITH_FILE and drop the
> nautilus change.

Fair enough, but you need to be careful about Nautilus.

You are right that copying owner or group by default is probably bad.

But what about permissions? Selinux context? ACLs? Are you sure that atime and mtime are the only two attributes worth copying by default? A brief example - say you copy a file with mode 0600 from a remote server, edit it, and then upload the modified version; are you sure that process should (by default) change the file's permissions to 0644?

In any case, nautilus needs to provide some GUI way of copying with all attributes preserved (necessary for system administration on the local machine).

mtime and atime are not the only attributes copied, for instance, wrt your example, the unix permissions *are* copied. Now, this is a bit weird, for instance we're copying the exact group permissions, but its applied to another group! However we need to do this or things like exec permissions will just break, and anyway cp has the same issues.

However, I'm not at all sure we should copy things like selinux context (that should most likely be decided by the target dir, i.e. if you copy a system file into your homedir it should become a "homedir" file), or ACLs (if a user can read some system file does that really mean you want him to be able to read your copy of it? Even if you later add your own data to it?).

What matters wrt this bug is that we want to make a distinction about the fact that there are two possible sets of attributes that we want to copy, depending on what kind of operation we're doing (regular copy, or copy to emulate move). If there are some details wrt what to copy that we deem are wrong we can fix that.

*WHEN* was this supposedly fixed?  I've just suffered the same problem and with a fresh install of Ubuntu 8.10 (Intrepid) and with Gnome 2.24. I had an existing 8.04 install, bought a new hard drive and fresh-installed 8.10, then copied all my files from the old drive.  A month later I now discover I've lost all the original time-stamps.

Both drives are ext3, and actually the new drive is a pair of drives setup as sw RAID-1 mirror (if that matters).

(In reply to comment #45)
> *WHEN* was this supposedly fixed?

See comment 42.
Also note that there has not been a glib 2.18 release since that date.