March 11, 2009, 10:26 AM — Springing ahead brings the promises of after work daylight hours, but always leaves me grouchy and out of sorts for a few days. It's just one hour, of course, that we push our clocks forward. Even so, experts in chronobiology — the study of how our internal clocks, our adaptation to solar and lunar rhythms, work — say it's pretty normal for people to take several days to adjust when we move our clocks ahead every Spring. So, yawn along with me while I explain how I found files on a Unix server dating not back to prior era but springing forward all the way to 2036!
I was checking a system to make sure that it was receiving data updates from a remote host when I discovered the futuristic files. I had been running a find command to provide me with a list of files that were less than one day old. To my surprise, I found about thirty files all dating forward to 2036. This is not a complete surprise. After all, the format of the Unix date command is a bit unwieldy at times. It's easy to forget whether one has to include the year and, if so, whether it goes at the beginning or end of the date string. Since I know how easy it is to make a mistake using the date command, I always follow a date reset with a second date command to make sure the date and time looks like what I expect to see. Otherwise, I try again or read the man page to figure out what I did wrong. Somehow, whether through a date error on this server or a transfer of files from another system with a date problem, we ended up with files dated far into the future.
My "find -mtime -1" command found the "future files" along with more than a hundred files that had been legitimately updated within the previous 24 hours or so. To get a list of only those files with dates stretching forward into the future, I ran a find command with "-mtime -0" -- in other words, "younger than brand new".
While I had no way to know what an appropriate time stamp would have been for any of these files, I wanted to grab them back from the far flung future if only to ensure that legitimately newer versions of the same files would be able to bump them if some "if newer than" logic were being applied.
My approach for updating the files was to use a find command to create a file list and then examine a long listing of each file before running the touch command to make each file's timestamp current. A reference file could be have been used instead if I wanted to give the files an earlier date, but I just didn't want them to be the newest files on the system for the next 27 years. The feedback also served to confirm how many files were affected by the problem and to see if there was anything that tied them together (e.g., names or file system locations).
find . -mtime -0 -ls > /tmp/futfiles
for file in `cat /tmp/futfiles | awk '{print $NF}'`
do
ls -l $file
echo -n "> "
read ans
touch $file
ls -l $file
done
