Why is find(ing) by -atime not printing expected files? [on hold]
I'm trying to recursively find files that have not been accessed for over 365 days. I can use stat and verify that the file has not been accessed for over 365 days. It is odd that the file shows that it has been changed about 6 months ago, but again stat shows last access was over a year ago.
Then I try using the find command and searching for files that have not been accessed for over a year, but the file I verified is not listed:
skunkbad:/var/www/htdocs/newera$ stat ./index.html
File: './index.html'
Size: 31 Blocks: 8 IO Block: 4096 regular file
Device: 802h/2050d Inode: 3279283 Links: 1
Access: (0664/-rw-rw-r--) Uid: ( 1000/skunkbad) Gid: ( 1001/ webdevs)
Access: 2018-01-08 16:22:58.271143975 -0800
Modify: 2017-09-21 14:01:36.950307771 -0700
Change: 2018-06-04 09:00:36.801632639 -0700
Birth: -
skunkbad:/var/www/htdocs/newera$ find . -atime +365 -type f -print
skunkbad:/var/www/htdocs/newera$
So, in this case, why isn't this index.html file listed by find? How can I recursively find files that haven't been accessed in over 365 days?
I'm asking because I intend to issue a command that touches these files, but I need to know that it's going to work. Example for 90 days:
find -type f -atime +90 -exec touch -a {} +
find atime
New contributor
put on hold as off-topic by Stephen Harris, Sparhawk, thrig, msp9011, nwildner 2 days ago
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Questions describing a problem that can't be reproduced and seemingly went away on its own (or went away when a typo was fixed) are off-topic as they are unlikely to help future readers." – Stephen Harris, Sparhawk, thrig, msp9011, nwildner
If this question can be reworded to fit the rules in the help center, please edit the question.
add a comment |
I'm trying to recursively find files that have not been accessed for over 365 days. I can use stat and verify that the file has not been accessed for over 365 days. It is odd that the file shows that it has been changed about 6 months ago, but again stat shows last access was over a year ago.
Then I try using the find command and searching for files that have not been accessed for over a year, but the file I verified is not listed:
skunkbad:/var/www/htdocs/newera$ stat ./index.html
File: './index.html'
Size: 31 Blocks: 8 IO Block: 4096 regular file
Device: 802h/2050d Inode: 3279283 Links: 1
Access: (0664/-rw-rw-r--) Uid: ( 1000/skunkbad) Gid: ( 1001/ webdevs)
Access: 2018-01-08 16:22:58.271143975 -0800
Modify: 2017-09-21 14:01:36.950307771 -0700
Change: 2018-06-04 09:00:36.801632639 -0700
Birth: -
skunkbad:/var/www/htdocs/newera$ find . -atime +365 -type f -print
skunkbad:/var/www/htdocs/newera$
So, in this case, why isn't this index.html file listed by find? How can I recursively find files that haven't been accessed in over 365 days?
I'm asking because I intend to issue a command that touches these files, but I need to know that it's going to work. Example for 90 days:
find -type f -atime +90 -exec touch -a {} +
find atime
New contributor
put on hold as off-topic by Stephen Harris, Sparhawk, thrig, msp9011, nwildner 2 days ago
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Questions describing a problem that can't be reproduced and seemingly went away on its own (or went away when a typo was fixed) are off-topic as they are unlikely to help future readers." – Stephen Harris, Sparhawk, thrig, msp9011, nwildner
If this question can be reworded to fit the rules in the help center, please edit the question.
6
Looks like thestat
information shows the last access date as2018-01-08
; it's only been 364 days since then. I would expect your command to work on 2019-01-09 at 16:23.
– edaemon
Jan 7 at 23:16
4
+365 means "366 or more", so you'll need to wait 2 more days.
– Mark Plotnick
Jan 7 at 23:17
@adaemon, thank you. I feel dumb for overlooking that.
– Brian Gottier
Jan 7 at 23:24
That proofs you are not a robot :-)
– nst0022
Jan 8 at 0:48
@edaemon It seems that you have answered the question. You could place it as an answer to receive reputation.
– Crypteya
Jan 8 at 3:43
add a comment |
I'm trying to recursively find files that have not been accessed for over 365 days. I can use stat and verify that the file has not been accessed for over 365 days. It is odd that the file shows that it has been changed about 6 months ago, but again stat shows last access was over a year ago.
Then I try using the find command and searching for files that have not been accessed for over a year, but the file I verified is not listed:
skunkbad:/var/www/htdocs/newera$ stat ./index.html
File: './index.html'
Size: 31 Blocks: 8 IO Block: 4096 regular file
Device: 802h/2050d Inode: 3279283 Links: 1
Access: (0664/-rw-rw-r--) Uid: ( 1000/skunkbad) Gid: ( 1001/ webdevs)
Access: 2018-01-08 16:22:58.271143975 -0800
Modify: 2017-09-21 14:01:36.950307771 -0700
Change: 2018-06-04 09:00:36.801632639 -0700
Birth: -
skunkbad:/var/www/htdocs/newera$ find . -atime +365 -type f -print
skunkbad:/var/www/htdocs/newera$
So, in this case, why isn't this index.html file listed by find? How can I recursively find files that haven't been accessed in over 365 days?
I'm asking because I intend to issue a command that touches these files, but I need to know that it's going to work. Example for 90 days:
find -type f -atime +90 -exec touch -a {} +
find atime
New contributor
I'm trying to recursively find files that have not been accessed for over 365 days. I can use stat and verify that the file has not been accessed for over 365 days. It is odd that the file shows that it has been changed about 6 months ago, but again stat shows last access was over a year ago.
Then I try using the find command and searching for files that have not been accessed for over a year, but the file I verified is not listed:
skunkbad:/var/www/htdocs/newera$ stat ./index.html
File: './index.html'
Size: 31 Blocks: 8 IO Block: 4096 regular file
Device: 802h/2050d Inode: 3279283 Links: 1
Access: (0664/-rw-rw-r--) Uid: ( 1000/skunkbad) Gid: ( 1001/ webdevs)
Access: 2018-01-08 16:22:58.271143975 -0800
Modify: 2017-09-21 14:01:36.950307771 -0700
Change: 2018-06-04 09:00:36.801632639 -0700
Birth: -
skunkbad:/var/www/htdocs/newera$ find . -atime +365 -type f -print
skunkbad:/var/www/htdocs/newera$
So, in this case, why isn't this index.html file listed by find? How can I recursively find files that haven't been accessed in over 365 days?
I'm asking because I intend to issue a command that touches these files, but I need to know that it's going to work. Example for 90 days:
find -type f -atime +90 -exec touch -a {} +
find atime
find atime
New contributor
New contributor
New contributor
asked Jan 7 at 23:02
Brian GottierBrian Gottier
1184
1184
New contributor
New contributor
put on hold as off-topic by Stephen Harris, Sparhawk, thrig, msp9011, nwildner 2 days ago
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Questions describing a problem that can't be reproduced and seemingly went away on its own (or went away when a typo was fixed) are off-topic as they are unlikely to help future readers." – Stephen Harris, Sparhawk, thrig, msp9011, nwildner
If this question can be reworded to fit the rules in the help center, please edit the question.
put on hold as off-topic by Stephen Harris, Sparhawk, thrig, msp9011, nwildner 2 days ago
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Questions describing a problem that can't be reproduced and seemingly went away on its own (or went away when a typo was fixed) are off-topic as they are unlikely to help future readers." – Stephen Harris, Sparhawk, thrig, msp9011, nwildner
If this question can be reworded to fit the rules in the help center, please edit the question.
6
Looks like thestat
information shows the last access date as2018-01-08
; it's only been 364 days since then. I would expect your command to work on 2019-01-09 at 16:23.
– edaemon
Jan 7 at 23:16
4
+365 means "366 or more", so you'll need to wait 2 more days.
– Mark Plotnick
Jan 7 at 23:17
@adaemon, thank you. I feel dumb for overlooking that.
– Brian Gottier
Jan 7 at 23:24
That proofs you are not a robot :-)
– nst0022
Jan 8 at 0:48
@edaemon It seems that you have answered the question. You could place it as an answer to receive reputation.
– Crypteya
Jan 8 at 3:43
add a comment |
6
Looks like thestat
information shows the last access date as2018-01-08
; it's only been 364 days since then. I would expect your command to work on 2019-01-09 at 16:23.
– edaemon
Jan 7 at 23:16
4
+365 means "366 or more", so you'll need to wait 2 more days.
– Mark Plotnick
Jan 7 at 23:17
@adaemon, thank you. I feel dumb for overlooking that.
– Brian Gottier
Jan 7 at 23:24
That proofs you are not a robot :-)
– nst0022
Jan 8 at 0:48
@edaemon It seems that you have answered the question. You could place it as an answer to receive reputation.
– Crypteya
Jan 8 at 3:43
6
6
Looks like the
stat
information shows the last access date as 2018-01-08
; it's only been 364 days since then. I would expect your command to work on 2019-01-09 at 16:23.– edaemon
Jan 7 at 23:16
Looks like the
stat
information shows the last access date as 2018-01-08
; it's only been 364 days since then. I would expect your command to work on 2019-01-09 at 16:23.– edaemon
Jan 7 at 23:16
4
4
+365 means "366 or more", so you'll need to wait 2 more days.
– Mark Plotnick
Jan 7 at 23:17
+365 means "366 or more", so you'll need to wait 2 more days.
– Mark Plotnick
Jan 7 at 23:17
@adaemon, thank you. I feel dumb for overlooking that.
– Brian Gottier
Jan 7 at 23:24
@adaemon, thank you. I feel dumb for overlooking that.
– Brian Gottier
Jan 7 at 23:24
That proofs you are not a robot :-)
– nst0022
Jan 8 at 0:48
That proofs you are not a robot :-)
– nst0022
Jan 8 at 0:48
@edaemon It seems that you have answered the question. You could place it as an answer to receive reputation.
– Crypteya
Jan 8 at 3:43
@edaemon It seems that you have answered the question. You could place it as an answer to receive reputation.
– Crypteya
Jan 8 at 3:43
add a comment |
1 Answer
1
active
oldest
votes
The manual for find
explains how the time calculations work for the -atime
, -ctime
and -mtime
tests:
-atime n
File was last accessed n*24 hours ago. When find figures out how many
24-hour periods ago the file was last accessed, any fractional part is
ignored, so to match-atime +1
, a file has to have been accessed at
least two days ago.
The second part of this is how the numerical argument has been specified:
Numeric arguments can be specified as
+n for greater than n,
-n for less than n,
n for exactly n.
So when you specify -atime +365
, find
will retrieve the files accessed more than 365 days ago. Because the calculation does not account for fractions, that means a file will only be matched if it has been accessed at least 366 days ago (days, as in 366*24 hours instead of calendar days).
So in your case, find . -atime +365
will match the shown file only after 366*24 hours from the date of access. This condition becomes true after 2019-01-09 16:22:58.
@ilkkachu Thanks for the edit, but I have a slightly different opinion. I had considered adding an emphasis on that quote as well, but I felt that the entire quoted text was equally important. Namely, 1) the n*24 hours part, the 2) the part about fractions being ignored, and 3) the example with 'atime +1'. Do you think the emphasis is still necessary, in this case?
– Haxiel
2 days ago
ok, I removed the emphasis. I only started editing to format the literal commands, the emphasis was a random thought, though I think the example there nicely shows the 'gotcha' part.
– ilkkachu
2 days ago
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
The manual for find
explains how the time calculations work for the -atime
, -ctime
and -mtime
tests:
-atime n
File was last accessed n*24 hours ago. When find figures out how many
24-hour periods ago the file was last accessed, any fractional part is
ignored, so to match-atime +1
, a file has to have been accessed at
least two days ago.
The second part of this is how the numerical argument has been specified:
Numeric arguments can be specified as
+n for greater than n,
-n for less than n,
n for exactly n.
So when you specify -atime +365
, find
will retrieve the files accessed more than 365 days ago. Because the calculation does not account for fractions, that means a file will only be matched if it has been accessed at least 366 days ago (days, as in 366*24 hours instead of calendar days).
So in your case, find . -atime +365
will match the shown file only after 366*24 hours from the date of access. This condition becomes true after 2019-01-09 16:22:58.
@ilkkachu Thanks for the edit, but I have a slightly different opinion. I had considered adding an emphasis on that quote as well, but I felt that the entire quoted text was equally important. Namely, 1) the n*24 hours part, the 2) the part about fractions being ignored, and 3) the example with 'atime +1'. Do you think the emphasis is still necessary, in this case?
– Haxiel
2 days ago
ok, I removed the emphasis. I only started editing to format the literal commands, the emphasis was a random thought, though I think the example there nicely shows the 'gotcha' part.
– ilkkachu
2 days ago
add a comment |
The manual for find
explains how the time calculations work for the -atime
, -ctime
and -mtime
tests:
-atime n
File was last accessed n*24 hours ago. When find figures out how many
24-hour periods ago the file was last accessed, any fractional part is
ignored, so to match-atime +1
, a file has to have been accessed at
least two days ago.
The second part of this is how the numerical argument has been specified:
Numeric arguments can be specified as
+n for greater than n,
-n for less than n,
n for exactly n.
So when you specify -atime +365
, find
will retrieve the files accessed more than 365 days ago. Because the calculation does not account for fractions, that means a file will only be matched if it has been accessed at least 366 days ago (days, as in 366*24 hours instead of calendar days).
So in your case, find . -atime +365
will match the shown file only after 366*24 hours from the date of access. This condition becomes true after 2019-01-09 16:22:58.
@ilkkachu Thanks for the edit, but I have a slightly different opinion. I had considered adding an emphasis on that quote as well, but I felt that the entire quoted text was equally important. Namely, 1) the n*24 hours part, the 2) the part about fractions being ignored, and 3) the example with 'atime +1'. Do you think the emphasis is still necessary, in this case?
– Haxiel
2 days ago
ok, I removed the emphasis. I only started editing to format the literal commands, the emphasis was a random thought, though I think the example there nicely shows the 'gotcha' part.
– ilkkachu
2 days ago
add a comment |
The manual for find
explains how the time calculations work for the -atime
, -ctime
and -mtime
tests:
-atime n
File was last accessed n*24 hours ago. When find figures out how many
24-hour periods ago the file was last accessed, any fractional part is
ignored, so to match-atime +1
, a file has to have been accessed at
least two days ago.
The second part of this is how the numerical argument has been specified:
Numeric arguments can be specified as
+n for greater than n,
-n for less than n,
n for exactly n.
So when you specify -atime +365
, find
will retrieve the files accessed more than 365 days ago. Because the calculation does not account for fractions, that means a file will only be matched if it has been accessed at least 366 days ago (days, as in 366*24 hours instead of calendar days).
So in your case, find . -atime +365
will match the shown file only after 366*24 hours from the date of access. This condition becomes true after 2019-01-09 16:22:58.
The manual for find
explains how the time calculations work for the -atime
, -ctime
and -mtime
tests:
-atime n
File was last accessed n*24 hours ago. When find figures out how many
24-hour periods ago the file was last accessed, any fractional part is
ignored, so to match-atime +1
, a file has to have been accessed at
least two days ago.
The second part of this is how the numerical argument has been specified:
Numeric arguments can be specified as
+n for greater than n,
-n for less than n,
n for exactly n.
So when you specify -atime +365
, find
will retrieve the files accessed more than 365 days ago. Because the calculation does not account for fractions, that means a file will only be matched if it has been accessed at least 366 days ago (days, as in 366*24 hours instead of calendar days).
So in your case, find . -atime +365
will match the shown file only after 366*24 hours from the date of access. This condition becomes true after 2019-01-09 16:22:58.
edited 2 days ago
ilkkachu
56.4k784156
56.4k784156
answered 2 days ago
HaxielHaxiel
1,552410
1,552410
@ilkkachu Thanks for the edit, but I have a slightly different opinion. I had considered adding an emphasis on that quote as well, but I felt that the entire quoted text was equally important. Namely, 1) the n*24 hours part, the 2) the part about fractions being ignored, and 3) the example with 'atime +1'. Do you think the emphasis is still necessary, in this case?
– Haxiel
2 days ago
ok, I removed the emphasis. I only started editing to format the literal commands, the emphasis was a random thought, though I think the example there nicely shows the 'gotcha' part.
– ilkkachu
2 days ago
add a comment |
@ilkkachu Thanks for the edit, but I have a slightly different opinion. I had considered adding an emphasis on that quote as well, but I felt that the entire quoted text was equally important. Namely, 1) the n*24 hours part, the 2) the part about fractions being ignored, and 3) the example with 'atime +1'. Do you think the emphasis is still necessary, in this case?
– Haxiel
2 days ago
ok, I removed the emphasis. I only started editing to format the literal commands, the emphasis was a random thought, though I think the example there nicely shows the 'gotcha' part.
– ilkkachu
2 days ago
@ilkkachu Thanks for the edit, but I have a slightly different opinion. I had considered adding an emphasis on that quote as well, but I felt that the entire quoted text was equally important. Namely, 1) the n*24 hours part, the 2) the part about fractions being ignored, and 3) the example with 'atime +1'. Do you think the emphasis is still necessary, in this case?
– Haxiel
2 days ago
@ilkkachu Thanks for the edit, but I have a slightly different opinion. I had considered adding an emphasis on that quote as well, but I felt that the entire quoted text was equally important. Namely, 1) the n*24 hours part, the 2) the part about fractions being ignored, and 3) the example with 'atime +1'. Do you think the emphasis is still necessary, in this case?
– Haxiel
2 days ago
ok, I removed the emphasis. I only started editing to format the literal commands, the emphasis was a random thought, though I think the example there nicely shows the 'gotcha' part.
– ilkkachu
2 days ago
ok, I removed the emphasis. I only started editing to format the literal commands, the emphasis was a random thought, though I think the example there nicely shows the 'gotcha' part.
– ilkkachu
2 days ago
add a comment |
6
Looks like the
stat
information shows the last access date as2018-01-08
; it's only been 364 days since then. I would expect your command to work on 2019-01-09 at 16:23.– edaemon
Jan 7 at 23:16
4
+365 means "366 or more", so you'll need to wait 2 more days.
– Mark Plotnick
Jan 7 at 23:17
@adaemon, thank you. I feel dumb for overlooking that.
– Brian Gottier
Jan 7 at 23:24
That proofs you are not a robot :-)
– nst0022
Jan 8 at 0:48
@edaemon It seems that you have answered the question. You could place it as an answer to receive reputation.
– Crypteya
Jan 8 at 3:43