On a system I have, files are uploaded through a series of various mechanisms into one central "incoming" directory. Once a day those files are processed and they are moved off to where they need to be (that logic isn't relevant here). They end up in a subdirectory of /files/. I guess a simple (albeit inaccurate in my specific case) would be to say that files that start with "a" get moved to /files/a/afile.

So I have a load of subdirectories in /files/. That's great and it works for me. However the client has just told me that it would be nice if there could be a "recently added" directory where files from the past week are available.

My first thought was to create a directory called /recent-files/ and extend the file processing script to do the following after it moves files out of /incoming/:

  1. Delete all files from within /recent-files/
  2. Scan /files/ for any file (not directory) created within a week
  3. Create a symlink for each to its real path and stick it in /recent-files/

Sounds like it would work but my bash is still pretty weak when it comes to arithmetic and file-creation dates. Can anybody lend me a hand crafting a find ... -exec ... statement that approximates parts two and three?

Of course, if there's another way of creating a command-line and NFS visible "search directory", let me know.

2 Answers 2

find -L files -type f -newerct '-7 days' -exec ln -s -t recent-files {} +

(Of course, change "files" and "recent-files" as appropriate.)

The 'c' used in -newer isn't creation time, it's the "change" field as shown by stat (the command, e.g. man 1 stat). It's currently uncommon for *nix filesystems to store creation time, but change ('c'), modification ('m'), and access ('a') time is available. If your filesystem does store creation time, you can use 'B' ("birth time") — you'll get an immediate error message if it's unsupported.

You can see the exact cutoff with date:

$ date -d '-7 days'
Sat Oct 16 02:46:27 UTC 2010
$ date  # this was executed one second later
Sat Oct 23 02:46:28 UTC 2010
  • What is the -L for? It claims it doesn't know what it is. But yes, this appears to work well!
    – Oli
    Oct 23, 2010 at 11:53
  • 1
    Well as I say, it's throwing this out: find: unknown predicate '-L'
    – Oli
    Oct 23, 2010 at 12:06
  • @Oli: I merely had -L in the wrong location, as I tested without the 'files' parameter, using find's default of the cwd.
    – Roger Pate
    Oct 23, 2010 at 12:23
  • I found that -mtime -7 worked better for find but that's probably due to a filesystem quirk. The rest of the code (including the nifty ln syntax) worked a treat. Thank you.
    – Oli
    Oct 29, 2010 at 15:26
  • @Oli: I originally looked at -mtime (and -mtime 7 should be equivalent to -newermt '-7 days'), but thought inode-change time would be better for you (though I can't recall now why). Glad it works well.
    – Roger Pate
    Oct 29, 2010 at 15:30

If using Zeitgeist and FUSE is feasible for your scenario, Zeitgeist Filesystem enables sorting files and other Zeitgeist events by time in a userspace filesystem.

Another (simpler) solution might be to use something like fileschanged in your script to monitor your directory for incoming files.

  • That's so very cool. I'm not using Zeitgeist and I think setting it up for something that could (I think) be accomplished by a daily-run find -exec would be a bit overkill for my simple needs. But for others who need better resolution on files, this is awesome. The fusepy module (used by this) looks awesome too. You could practically make a filesystem out of anything with a few lines of Python. Anyway, +1 for your idea. But no cigar.
    – Oli
    Oct 22, 2010 at 22:56
  • 1
    I've combined both answers into this one.
    – mgunes
    Oct 23, 2010 at 3:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.