Terminal: ctime flag in find not working as expected

[DominikHoffmann]

find ~/Downloads -ctime +14 | more

produces no output. I clearly have files older than 14 days in my Downloads folder. What could be going on?

I have had code using this snippet running in a cron job and migrated it into a launchd user agent. It doesn’t work as part of that, but it also doesn’t work on the command line directly.

 

[Slartibart]

you can use zsh‘s m+14 glob qualifier which can check files ages - or something like find -mtime +14.

 

[DominikHoffmann]

So, yes,

find ~/Downloads -mtime +14 | more

works. It still begs the question, why the ctime flag does not.

 

[DominikHoffmann]

you can use zsh‘s m+14 glob qualifier which can check files ages - or something like find -mtime +14.

That said, changing the ctime flag to “mtime” helped. Thanks very much for the suggestion!

I am using the functionality in this script:

#!/bin/sh
# Searches through ~/Documents/Temporary (2-week retention)/
# and deletes all files older than 30 days while leaving the folder
# ~/Documents/Temporary (2-week retention)/Scans/ alone.
# A log file delete.log in ~/Library/Logs/ is updated with the file names
# of the deleted files.

( /usr/bin/find ~/Documents/Temporary\ \(2-week\ retention\) -mtime +30 ! -regex '.*/\..*' ! -regex '.*/Scans'  -print0 | /usr/bin/xargs -0 rm -r -d ) >> ~/Library/Logs/delete.log 2>&1

And it is triggered by this launchd user agent in ~/Library/LaunchAgents/

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>KeepAlive</key>
    <false/>
    <key>Label</key>
    <string>local.cleanup-tempdocs</string>
    <key>Program</key>
    <string>/Users/dominik/.scripts/cleanup-tempdocs</string>
    <key>RunAtLoad</key>
    <true/>
    <key>StartCalendarInterval</key>
    <dict>
        <key>Hour</key>
        <integer>3</integer>
        <key>Minute</key>
        <integer>30</integer>
    </dict>
    <key>StartInterval</key>
    <integer>86400</integer>
</dict>
</plist>

It runs daily (every 86,400 s) at 3:30 AM local time. This way, I don’t have to clear out my Downloads folder all the time. Anything I want to keep, I have to rescue from this folder and put elsewhere, or after 30 days it will be gone. Should I have neglected such due diligence, I can restore a backup as the Downloads folder gets backed up continuously.

 

[bernuli]

find ~/Downloads -ctime +14 | more

produces no output. I clearly have files older than 14 days in my Downloads folder. What could be going on?

I have had code using this snippet running in a cron job and migrated it into a launchd user agent. It doesn’t work as part of that, but it also doesn’t work on the command line directly.

I think you might have better luck with -mtime:

find ~/Downloads -mtime +14d

 

[DominikHoffmann]

I think you might have better luck with -mtime:

find ~/Downloads -mtime +14d

Thanks! @Slartibart beat you to that with that suggestion, though! I posted my script, which might have some more universal utility, where I am using the find command, above.

 

[bernuli]

So, yes,

find ~/Downloads -mtime +14 | more

works. It still begs the question, why the ctime flag does not.

I think because ctime is not what you want. The man page for find stays ctime is "the last change of file status information". But you are trying to find files based on modification time.

As I recall, modification time is the only timestamp you can truly count on.

 

[DominikHoffmann]

The script worked for many years. Maybe the code for “find” was brought in line with the command specification only with more recent macOS iterations. I am pretty sure, I had the same issue with Big Sur and possibly with Catalina. In other words, for many years my script was relying on a faulty implementation. Once that was fixed, the script broke.

 

[bernuli]

The script worked for many years. Maybe the code for “find” was brought in line with the command specification only with more recent macOS iterations. I am pretty sure, I had the same issue with Big Sur and possibly with Catalina. In other words, for many years my script was relying on a faulty implementation. Once that was fixed, the script broke.

Just guessing here but changes in APFS could have an effect on expected results from ctime.

Changing extended attributes WILL update the ctime. macOS Catilina and up started adding more xattrs to files being accessed by Finder.

Changing file permissions will also change the ctime.

I have always used mtime in situations like yours.