I’ve copied several files from one drive to another by simply dragging and dropping. It didn’t really hit me that this will give the files on the second drive a different timestamp/modification date. This isn’t exactly a huge problem but it is when trying to make sure all files are present on both drives (when running a comparison) since it flags each timestamp/date difference as a different file.
I’ve read that one can copy the timestamp from one file to another but I can’t seem to find any info on how to copy the timestamp/modified date to many files in a batch. Is this even possible or is it just a pipe dream?
If it’s not possible and since I have far too many files to manually change one by one, is by best option simply coping the files again but this time, making sure to preserve the timestamp and mod date? Is there a way I can setup my file browser to preserve this data anytime I copy by dragging/dropping or is that simply not possible? Any help would be amazing! Thanks so much.
touch command accepts multiple files as arguments.
Is there a way I can setup my file browser
You never mentioned desktop environment you are using and even under single desktop environment multiple alternative “file browsers” are usually available.
–preserve=ATTR_LIST ]
preserve the specified attributes (default: mode,ownership,timestamps), if possible additional attributes: context, links, xattr, all
I find it easier to use/remember rsync, eg. to copy files and folders recursively:
rysnc -avcr source dest
There is a possibility that using this command to overwrite otherwise identical files will only update the ownership, permissions and timestamps without having to copy the files, but I haven’t tried it. Other than time you don’t have much to lose by trying it.
Well, when the contents before, after and the contents of the origin are all the same, you can not test it (and IMHO it does not matter at all (but for the resources not used to not copy physically).
In fact is what the OP wants not “correct”. He creates new files with the contents of existing files. Thus those new files have a ctime, atime and mtime of the time of creation. That is how it is defined.
Apparently he wants the new copies have the same ctime (I am not sure about the others) as the originals. That can be done (as several posts above show), but if such falsification is “correct”???
I don’t think of that as “falsification”. To me, the term “file” refers to an abstraction. The time should be that of the creation of the data, not that of the allocation of disk space.
Yes, of course it does. And that is why I think that “correct” is not the correct way of labeling. If the one, or the other is “coorect” depends on what you need or want, thus saying one way is correct without even explaining which one, apparently assuming that one’s own way of looking at it is the “correct” way of looking at it, is confusing.
But IMHO, when you see it from the abstract definition of the time stamps as part of the meta data of the file, not the data, there is in a Unix file system no meta data about the contents of a file.
It seems that from very early there was a need to copy and nevertheless preserve the metadata. Think of making backups. When root make backup copies, the copies will not only have new time stamps, but root:root will be owner and the permissions will be set according to the umask applicable at that moment.
Solutions:
Using tar, which, as an archiver will preserve all inside it’s archive and use -p on extraction (default for root)…
Using cp -a (which is the explained as the archiver option)
And later of course the backup tool par exellence: rsync, which has same features.
Maybe the word “falsifying” sounds as if I am against doing this. This is not so. I want to express that it is changing metadata from files from their intended (by design) values. Often with a good reason.
There is no way that I’m aware of. This is why I never use a GUI file browser/manager to copy or move a file. Instead I use mc or fcl. I’m very persnickety about preserving timestamps displayed by ls -l (mtime) when a file is copied or moved without change of its content.
That’s rather presumptuous when you do not even know what program you are talking about. I just tried Nautilus and it preserves mtime just fine (without me configuring it in any special way).
In post #6 I replied with a copy of post #5, replying to the inability to test, and adding a comment on my tests. Post #6, edited by hcvv, has been replaced entirely, and shows part of my comment being attributed to hcvv. This has resulted with a quote attributed to me in post #7, which was never made by me. Similarly I am quoted in post #8 but never made that statement either.
hvcc, did you edit my post#6 by accident instead of replying to it. I have no problem with being corrected or criticized, but I don’t appreciated being quoted for things that I never said.
I understand that you do not want to be credited with things you never did.
I am afraid that it is possible I made a mistake here. I do not remember, but what you tell is probably evidence that I did click the Edit button and not the Reply one.
You convinced me that I made an unwanted, but serious error here and I apologize for it. Maybe I should go to bed earlier. >:(
FWIW, copying a file to another internal drive or to a pendrive with Dolphin preserves both creation and modification time, at least as shown in Dolphin’s information panel. Leap 15.1 KDE Plasma.
Ten+ years ago it wasn’t so. This gave me a huge headache when I copied hundreds of photos from a pendrive to my brand new openSUSE install (v10 or 11, I think), and konqueror stamped all with the current time. since they had different naming conventions, most undated, I couldn’t sort by date anymore and have a time-ordered slideshow, for instance. I asked for help here, but the idea at the time was that this was the “right” way (with an implied STFU). Well, not for me. I almost went back to XP.
:\
We are going a bit off-topic and it won’t help you because it was some time ago. But when they were JPEGs, the date/time of taking the picture is still kept in the file. The tool jhead enables you to use that internal date to set the external one (like reading it from the file and doing a touch).
Astonishingly, that is true. Astonishing for me, as I could swear I recently faced the same issue as the OP drag - drop in dolphin and time stamp, even owner was changed. Now, I can’t reproduce it. Works perfectly fine (on a different machine - anyway). Hm.
However, I found
mrcp -rp /here /there
copied the full home directory including all the hidden things and sockets etc. from /here to /there keeping all properties as they were. Being the home directory apparently I had to do this as a different user (namely root) which got me into the “owner” issues in the first place.
