I copy paste files from one place to other. Now, I'm in a doubt as when the time stamp (modification) is retained.

See, I tested in my laptop internal hdd. Here the time stamp is getting retained even if I copy paste from one partition to other!

I tested it with tablet. I connected the tablet with usb cable. Now if I copy & paste a file from tablet to laptop, the time stamp (modification) is not getting retained.

So, when is the time stamp retained & when it is not?

Hi there,

as a rule of thumb: In strictly file-based operations, the file timestamp is retained if all file systems and handlers involved in the action support timestamps.

That's what I would expect.

How is the tablet being accessed? As a USB storage device mounted to the host file system? Probably not, because that would require the host to read and write the tablet's memory directly on sector level. I rather guess the tablet has some kind of server running (FTP or something like Samba), and the USB link is treated like a network connection.

And yes, by copying files from one machine to another, you sometimes lose timestamps, the copy gets timestamped with the moment of copying. I'm experiencing this here, too: Two Linux-based machines, say A and B, both running Samba with a few shares. If I copy from A to B, timestamps are preserved; if I copy from B to A, timestamps are refreshed to the moment of copying. I still haven't found out what the reason is, but maybe someone else can supply additional information.

[X] Doc CPU

1 members found this post helpful.

Copying from one physical disk or partition to another will change the timestamp. And clearly copying to another entire system matches this criteria.

Copying a file within the scope of an existing disk, typically will retain the timestamp.

I believe that if you have one disk but with two or more data partitions, if you copy/paste from one partition to another, it will change the timestamp.

Hi there,

that's against experience: If I copy to or from a USB storage (HDD, pen drive, SD card), the timestamp is copied "as is". Which makes sense, because the file contents isn't modified, so why would the modification date change?

You believe wrong. I'm not denying that there may be circumstances where you're right. But usually, timestamps are preserved in a copy/move operation (which is what C&P in a file manager actually does).

Only copying "through Samba" across different machines sometimes changes the modification timestamp. But even then, not always. Probably a side effect of a particular Samba configuration option.

[X] Doc CPU

1 members found this post helpful.

You posted what is (essentially), this same question twice; your other thread was reported. Since you don't tell us what kind of tablet you're using, it's hard to offer options. Some tablets have microsd cards, and there are MANY Android utilities that will let you copy files from internal memory to the SD card. From there, put the card into your laptop, and you may have more options for copying.

That said, have you tried reading the man page on the cp command? Pay particular attention to the "-p" and "-a" flags:
Did you try that?

That is entirely up to the application doing the copy/move operation. The only time that the timestamp would be retained by default is a simple rename operation within the same filesystem. That operation does not create a new inode, and the mtime and atime fields in the inode would not be changed. For every other case, a new inode is created, and it will initially have all its timestamps set to the current time. To preserve the original timestamps, the application would need to use one of the utime(2) system calls to set those times.

You can see this in action by running the mv command under strace and move a file to a different filesystem. The mv command tries to preserve the semantics of a simple rename operation, so one of the last things it does is a utimensat() call to set the timestamps on the destination to match those of the source.

O.K., SD card ! That may be a way. I've to check.

No, I havent checked cp command. The reason is I feel command line won't work in case of my tablet. See I've a thread here. There I've written that tar command isn't working. The tablet is mounted via mtp (using USB cable) or something like that & not as USB mass storage like pen drive or external hdd. So I feel command line won't work.

My tablet is Asus fonepad7 (android).

Yes, that's the duplicate thread that was reported. And if all you have is the MTP, then you have two choices:

• Manually change dates/times after you copy
• Learn to live with it

There is a difference depending on HOW you copy files.

If you use "cp" to copy, the modification date is preserved. The creation date (which is misnamed) is actually an "inode modification date" and that always gets the current date.

If you copy with a GUI, then all dates may be lost.

If you are "copying" via a network style connection you also lose the dates.

If you "copy/paste" you are going through something other than the systems copying function.

Hi there,

to clear things up a little, I made a few tests myself, and to my surprise I found that I partly have to correct my own statements.

Yes, definitely. I considered the two methods a) cp from the command line and b) drag&drop from a GUI file manager, which is Caja in my system (much like Gnome's Nautilus). I copied a few files from a USB HDD to the internal drive.

Actually, it's exactly the other way round. All files copied with 'cp' got a fresh modification date, except with the -p switch.
The files copied with Caja, however, retained their modification date. But you can see that while copying is still in progress, the partial file also has a new timestamp, which is adjusted to the original's at the end.

Sometimes, but not always. And I still haven't found the time to take the Samba configuration apart on the two machines showing different behavior depending on the direction of the copying action.

I don't think so. C&P in a GUI file manager is nothing else than a copy/move operation delayed until the 'paste' action.

[X] Doc CPU

1 members found this post helpful.

It depends on weather the date is set after the copy.

Yes TBOne, that issue of copying photos from tablet to laptop by retaining the time stamp is solved. As this point doesn't go well with this thread, please have a look at that thread.

You thought in a right direction by mentioning MTP. Yes it worked not with MTP but with gphoto2.

No thanks, because again you should not post the same question more than once. Read the LQ rules.
...and since gphoto2 uses MTP, and if you had read the man pages to start with, you'd have had the solution earlier.