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

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP












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













closed as off-topic by Stephen Harris, Sparhawk, thrig, msp9011, nwildner Jan 8 at 16:22


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













closed as off-topic by Stephen Harris, Sparhawk, thrig, msp9011, nwildner Jan 8 at 16:22


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














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













share|improve this question











share|improve this question




share|improve this question










asked Jan 7 at 23:02









Brian GottierBrian Gottier

1184




1184




closed as off-topic by Stephen Harris, Sparhawk, thrig, msp9011, nwildner Jan 8 at 16:22


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.




closed as off-topic by Stephen Harris, Sparhawk, thrig, msp9011, nwildner Jan 8 at 16:22


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
    Jan 8 at 7:49











  • 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
    Jan 8 at 7:54

















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
    Jan 8 at 7:49











  • 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
    Jan 8 at 7:54















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
    Jan 8 at 7:49











  • 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
    Jan 8 at 7:54













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 Jan 8 at 7:49









ilkkachu

56.9k785158




56.9k785158










answered Jan 8 at 5:45









HaxielHaxiel

1,763410




1,763410












  • @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
    Jan 8 at 7:49











  • 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
    Jan 8 at 7:54

















  • @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
    Jan 8 at 7:49











  • 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
    Jan 8 at 7:54
















@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
Jan 8 at 7:49





@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
Jan 8 at 7:49













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
Jan 8 at 7:54





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
Jan 8 at 7:54


Popular posts from this blog

Peggy Mitchell

Palaiologos

The Forum (Inglewood, California)