I reported the corruption within a day of its happening, but it took another week (and mail to root@ instead of support@) to get a response from the support folks and apparently another few days for them to start looking. I told them what the datestamp was, and the last known-good datetime.
Maybe I'll try the "pose as a new customer" thing and see what I can find out.
"As a side thought, is it possible that the database program *encrypted* your data file?"
My "database program" in this case is csplit + sed + cat + the Unix filesystem:
#!/bin/tcsh
cd ~/quotetmp
# Split the quote queue into individual messages to make it easy to
# grab the first one.
csplit -k -n 4 ../LJQUOTEFILE '/cut line for QotD automation script/' '{300}'
# Massage the first quote in the queue to prepare it for posting.
sed -e "/cut line for QotD automation script/d" xx0001 > today.tmp
# Keep trying to post it until 'clive' returns a success status.
while ( ! { ( $HOME/bin/clive -p -u dglenn -w XXX -s QotD < today.tmp ) } )
sleep 120
echo Trying again, `date`
end
# Drop the posted quote in my mailbox.
$HOME/bin/bsdmail -s "Automagically posted LJ QotD" `/usr/ucb/whoami` < today.tmp
# Reassemble the queue minus the entry just posted, and clean up.
rm xx0001 xx0000
cat xx* > ../LJQUOTEFILE
rm xx*
# Archive today's quote.
mv today.tmp qotd.`date +%Y%m%d`.html
And the timestamp on the file was about six hours later than the last time the cron script had run. I'm wondering whether it's possible that a hiccup in SunOS could have caused someone else's file to be written to the inodes allocated to my LJQUOTEFILE while leaving the directory entry for my file still pointing to those places on the disk ...?
(Yes, I know that script could be tightened up a little, but it was a quick&dirty hack that I haven't gotten around to getting back to. (And for folks other than Aliza, who already knows this: yes, most of my quick&dirty hacks in languages other than old Microsoft BASIC have comments in them.))
BTW, I've thought about moving to a DBMS-oriented approach for ease of queue-maintenance, but keep not getting around to it 'cause editing the queue with vi, even when I'm rearranging it, hasn't been painful enough to shift the idea of a rewrite from "would be cool" to "solves a problem". But I do have some ideas for database maneuvers that would make pasting in a new quote a little more automatic.
QotD file
Maybe I'll try the "pose as a new customer" thing and see what I can find out.
"As a side thought, is it possible that the database program *encrypted* your data file?"
My "database program" in this case is csplit + sed + cat + the Unix filesystem:And the timestamp on the file was about six hours later than the last time the cron script had run. I'm wondering whether it's possible that a hiccup in SunOS could have caused someone else's file to be written to the inodes allocated to my LJQUOTEFILE while leaving the directory entry for my file still pointing to those places on the disk ...?
(Yes, I know that script could be tightened up a little, but it was a quick&dirty hack that I haven't gotten around to getting back to. (And for folks other than Aliza, who already knows this: yes, most of my quick&dirty hacks in languages other than old Microsoft BASIC have comments in them.))
BTW, I've thought about moving to a DBMS-oriented approach for ease of queue-maintenance, but keep not getting around to it 'cause editing the queue with vi, even when I'm rearranging it, hasn't been painful enough to shift the idea of a rewrite from "would be cool" to "solves a problem". But I do have some ideas for database maneuvers that would make pasting in a new quote a little more automatic.