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/
:
- Delete all files from within
/recent-files/
- Scan
/files/
for any file (not directory) created within a week - 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.
Best Answer
(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: