Is there any way to use chown/chgrp without modifying the last modified date?
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
migrated from stackoverflow.com Oct 1 '12 at 13:51
This question came from our site for professional and enthusiast programmers.
add a comment |
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
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
add a comment |
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
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
file-transfer chown
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
add a comment |
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
add a comment |
1 Answer
1
active
oldest
votes
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.
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
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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.
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
add a comment |
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.
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
add a comment |
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.
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.
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
add a comment |
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
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
This would be suspicious. Imagine a hacker or a rootkit disguising its accesses.
– nalply
Oct 1 '12 at 13:37