Why is find(ing) by -atime not printing expected files? [on hold]












3














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 {} +









share|improve this question







New contributor




Brian Gottier is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











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 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




    +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
















3














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 {} +









share|improve this question







New contributor




Brian Gottier is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











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 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




    +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














3












3








3







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 {} +









share|improve this question







New contributor




Brian Gottier is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











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






share|improve this question







New contributor




Brian Gottier is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











share|improve this question







New contributor




Brian Gottier is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









share|improve this question




share|improve this question






New contributor




Brian Gottier is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









asked Jan 7 at 23:02









Brian GottierBrian Gottier

1184




1184




New contributor




Brian Gottier is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





New contributor





Brian Gottier is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






Brian Gottier is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.




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 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




    +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




    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




    +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










1 Answer
1






active

oldest

votes


















2














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.






share|improve this answer























  • @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


















1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









2














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.






share|improve this answer























  • @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
















2














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.






share|improve this answer























  • @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














2












2








2






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.






share|improve this answer














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.







share|improve this answer














share|improve this answer



share|improve this answer








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


















  • @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



Popular posts from this blog

How to reconfigure Docker Trusted Registry 2.x.x to use CEPH FS mount instead of NFS and other traditional...

is 'sed' thread safe

How to make a Squid Proxy server?