Is there any way to use chown/chgrp without modifying the last modified date?












5














I'm recovering files from an old hard drive and I need to keep the last modified date from the drive. The reason they are updating is because I need to change the ownership of the files to a new user.










share|improve this question















migrated from stackoverflow.com Oct 1 '12 at 13:51


This question came from our site for professional and enthusiast programmers.















  • This would be suspicious. Imagine a hacker or a rootkit disguising its accesses.
    – nalply
    Oct 1 '12 at 13:37
















5














I'm recovering files from an old hard drive and I need to keep the last modified date from the drive. The reason they are updating is because I need to change the ownership of the files to a new user.










share|improve this question















migrated from stackoverflow.com Oct 1 '12 at 13:51


This question came from our site for professional and enthusiast programmers.















  • This would be suspicious. Imagine a hacker or a rootkit disguising its accesses.
    – nalply
    Oct 1 '12 at 13:37














5












5








5







I'm recovering files from an old hard drive and I need to keep the last modified date from the drive. The reason they are updating is because I need to change the ownership of the files to a new user.










share|improve this question















I'm recovering files from an old hard drive and I need to keep the last modified date from the drive. The reason they are updating is because I need to change the ownership of the files to a new user.







file-transfer chown






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Dec 20 '18 at 0:21









Rui F Ribeiro

39k1479130




39k1479130










asked Sep 12 '12 at 0:10







Alexandertyler











migrated from stackoverflow.com Oct 1 '12 at 13:51


This question came from our site for professional and enthusiast programmers.






migrated from stackoverflow.com Oct 1 '12 at 13:51


This question came from our site for professional and enthusiast programmers.














  • This would be suspicious. Imagine a hacker or a rootkit disguising its accesses.
    – nalply
    Oct 1 '12 at 13:37


















  • This would be suspicious. Imagine a hacker or a rootkit disguising its accesses.
    – nalply
    Oct 1 '12 at 13:37
















This would be suspicious. Imagine a hacker or a rootkit disguising its accesses.
– nalply
Oct 1 '12 at 13:37




This would be suspicious. Imagine a hacker or a rootkit disguising its accesses.
– nalply
Oct 1 '12 at 13:37










1 Answer
1






active

oldest

votes


















2














The mtime (file modification time) shouldn't change when the owner is changed (nor should the atime or access time). That would be a change in the inode information, reflected in the ctime field.



If you find that on your system, chown(2) (or chown(1) and chgrp(1)) do change the mtime or atime and you're concerned about preserving both mtime and atime, then you'll need to write code to collect the current times (using stat(2) or stat(1)), and reinstate them (using utimes(2) or touch(1)).



AFAIK, you cannot control the setting of the ctime. If the inode changes, the system records the time it changed and doesn't allow you to change that.






share|improve this answer





















  • Hmm, interesting. I assumed that the chown and chgrp commands would be the modifiers on the time. The only other action performed on the files was a transfer from a hard drive to a server using ftp via Filezilla. Would this cause the time change?
    – Alexandertyler
    Sep 12 '12 at 17:51






  • 1




    When I just used FTP to copy a file between machines (default options), the modification time of the file on the target machine was set to the current date, not to the original date. So FTP does not preserve mtime and atime timestamps by default. This isn't very surprising; FTP is more general than Unix with its mtime and atime. Put another way, FTP is not TAR. Maybe you should consider using TAR to package the files on the source machine, use FTP to transfer the (compressed) tar file, and then use TAR on the target to restore with the correct time stamps. You can then adjust ownership later.
    – Jonathan Leffler
    Sep 12 '12 at 18:17











Your Answer








StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f49587%2fis-there-any-way-to-use-chown-chgrp-without-modifying-the-last-modified-date%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown
























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









2














The mtime (file modification time) shouldn't change when the owner is changed (nor should the atime or access time). That would be a change in the inode information, reflected in the ctime field.



If you find that on your system, chown(2) (or chown(1) and chgrp(1)) do change the mtime or atime and you're concerned about preserving both mtime and atime, then you'll need to write code to collect the current times (using stat(2) or stat(1)), and reinstate them (using utimes(2) or touch(1)).



AFAIK, you cannot control the setting of the ctime. If the inode changes, the system records the time it changed and doesn't allow you to change that.






share|improve this answer





















  • Hmm, interesting. I assumed that the chown and chgrp commands would be the modifiers on the time. The only other action performed on the files was a transfer from a hard drive to a server using ftp via Filezilla. Would this cause the time change?
    – Alexandertyler
    Sep 12 '12 at 17:51






  • 1




    When I just used FTP to copy a file between machines (default options), the modification time of the file on the target machine was set to the current date, not to the original date. So FTP does not preserve mtime and atime timestamps by default. This isn't very surprising; FTP is more general than Unix with its mtime and atime. Put another way, FTP is not TAR. Maybe you should consider using TAR to package the files on the source machine, use FTP to transfer the (compressed) tar file, and then use TAR on the target to restore with the correct time stamps. You can then adjust ownership later.
    – Jonathan Leffler
    Sep 12 '12 at 18:17
















2














The mtime (file modification time) shouldn't change when the owner is changed (nor should the atime or access time). That would be a change in the inode information, reflected in the ctime field.



If you find that on your system, chown(2) (or chown(1) and chgrp(1)) do change the mtime or atime and you're concerned about preserving both mtime and atime, then you'll need to write code to collect the current times (using stat(2) or stat(1)), and reinstate them (using utimes(2) or touch(1)).



AFAIK, you cannot control the setting of the ctime. If the inode changes, the system records the time it changed and doesn't allow you to change that.






share|improve this answer





















  • Hmm, interesting. I assumed that the chown and chgrp commands would be the modifiers on the time. The only other action performed on the files was a transfer from a hard drive to a server using ftp via Filezilla. Would this cause the time change?
    – Alexandertyler
    Sep 12 '12 at 17:51






  • 1




    When I just used FTP to copy a file between machines (default options), the modification time of the file on the target machine was set to the current date, not to the original date. So FTP does not preserve mtime and atime timestamps by default. This isn't very surprising; FTP is more general than Unix with its mtime and atime. Put another way, FTP is not TAR. Maybe you should consider using TAR to package the files on the source machine, use FTP to transfer the (compressed) tar file, and then use TAR on the target to restore with the correct time stamps. You can then adjust ownership later.
    – Jonathan Leffler
    Sep 12 '12 at 18:17














2












2








2






The mtime (file modification time) shouldn't change when the owner is changed (nor should the atime or access time). That would be a change in the inode information, reflected in the ctime field.



If you find that on your system, chown(2) (or chown(1) and chgrp(1)) do change the mtime or atime and you're concerned about preserving both mtime and atime, then you'll need to write code to collect the current times (using stat(2) or stat(1)), and reinstate them (using utimes(2) or touch(1)).



AFAIK, you cannot control the setting of the ctime. If the inode changes, the system records the time it changed and doesn't allow you to change that.






share|improve this answer












The mtime (file modification time) shouldn't change when the owner is changed (nor should the atime or access time). That would be a change in the inode information, reflected in the ctime field.



If you find that on your system, chown(2) (or chown(1) and chgrp(1)) do change the mtime or atime and you're concerned about preserving both mtime and atime, then you'll need to write code to collect the current times (using stat(2) or stat(1)), and reinstate them (using utimes(2) or touch(1)).



AFAIK, you cannot control the setting of the ctime. If the inode changes, the system records the time it changed and doesn't allow you to change that.







share|improve this answer












share|improve this answer



share|improve this answer










answered Sep 12 '12 at 0:34









Jonathan Leffler

1,185813




1,185813












  • Hmm, interesting. I assumed that the chown and chgrp commands would be the modifiers on the time. The only other action performed on the files was a transfer from a hard drive to a server using ftp via Filezilla. Would this cause the time change?
    – Alexandertyler
    Sep 12 '12 at 17:51






  • 1




    When I just used FTP to copy a file between machines (default options), the modification time of the file on the target machine was set to the current date, not to the original date. So FTP does not preserve mtime and atime timestamps by default. This isn't very surprising; FTP is more general than Unix with its mtime and atime. Put another way, FTP is not TAR. Maybe you should consider using TAR to package the files on the source machine, use FTP to transfer the (compressed) tar file, and then use TAR on the target to restore with the correct time stamps. You can then adjust ownership later.
    – Jonathan Leffler
    Sep 12 '12 at 18:17


















  • Hmm, interesting. I assumed that the chown and chgrp commands would be the modifiers on the time. The only other action performed on the files was a transfer from a hard drive to a server using ftp via Filezilla. Would this cause the time change?
    – Alexandertyler
    Sep 12 '12 at 17:51






  • 1




    When I just used FTP to copy a file between machines (default options), the modification time of the file on the target machine was set to the current date, not to the original date. So FTP does not preserve mtime and atime timestamps by default. This isn't very surprising; FTP is more general than Unix with its mtime and atime. Put another way, FTP is not TAR. Maybe you should consider using TAR to package the files on the source machine, use FTP to transfer the (compressed) tar file, and then use TAR on the target to restore with the correct time stamps. You can then adjust ownership later.
    – Jonathan Leffler
    Sep 12 '12 at 18:17
















Hmm, interesting. I assumed that the chown and chgrp commands would be the modifiers on the time. The only other action performed on the files was a transfer from a hard drive to a server using ftp via Filezilla. Would this cause the time change?
– Alexandertyler
Sep 12 '12 at 17:51




Hmm, interesting. I assumed that the chown and chgrp commands would be the modifiers on the time. The only other action performed on the files was a transfer from a hard drive to a server using ftp via Filezilla. Would this cause the time change?
– Alexandertyler
Sep 12 '12 at 17:51




1




1




When I just used FTP to copy a file between machines (default options), the modification time of the file on the target machine was set to the current date, not to the original date. So FTP does not preserve mtime and atime timestamps by default. This isn't very surprising; FTP is more general than Unix with its mtime and atime. Put another way, FTP is not TAR. Maybe you should consider using TAR to package the files on the source machine, use FTP to transfer the (compressed) tar file, and then use TAR on the target to restore with the correct time stamps. You can then adjust ownership later.
– Jonathan Leffler
Sep 12 '12 at 18:17




When I just used FTP to copy a file between machines (default options), the modification time of the file on the target machine was set to the current date, not to the original date. So FTP does not preserve mtime and atime timestamps by default. This isn't very surprising; FTP is more general than Unix with its mtime and atime. Put another way, FTP is not TAR. Maybe you should consider using TAR to package the files on the source machine, use FTP to transfer the (compressed) tar file, and then use TAR on the target to restore with the correct time stamps. You can then adjust ownership later.
– Jonathan Leffler
Sep 12 '12 at 18:17


















draft saved

draft discarded




















































Thanks for contributing an answer to Unix & Linux Stack Exchange!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.





Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


Please pay close attention to the following guidance:


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f49587%2fis-there-any-way-to-use-chown-chgrp-without-modifying-the-last-modified-date%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Morgemoulin

Scott Moir

Souastre