[QoTD file] my ISP has reported that they couldn't find a good copy (which makes me wonder what their backup policy/procedure is for user files -- but I'm not sure how to ask without sounding like I'm being snippy about it).
Pose as a prospective customer (or get a friend to do it) and ask along with other questions about their service.
How long was the file corrupt before you reported it to them? If you can tell them that, as of the day you reported the problem, the file had been corrupt for less than $SMALL_INTEGER days, and ask for the list of available backup copies, and add that as you're paying a third party to try to recover the data, all available versions of the file that they corrupted might be helpful, you might get a good snapshot of (a) what their actual backup policy is, and (b) whether they are likely to damage other files of yours.
You can also ask them what software upgrades they did on the system during the time in question, since that may well be part of the problem.
Of course, once you determine that you have gotten as much assistance out of them as you can expect to get, you can consider publishing a web page detailing your experience with them and how it does (or does not) correlate with the backup policies that they claim when trying to impress potential customers.
As a side thought, is it possible that the database program *encrypted* your data file?
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.
(no subject)
Pose as a prospective customer (or get a friend to do it) and ask along with other questions about their service.
How long was the file corrupt before you reported it to them? If you can tell them that, as of the day you reported the problem, the file had been corrupt for less than $SMALL_INTEGER days, and ask for the list of available backup copies, and add that as you're paying a third party to try to recover the data, all available versions of the file that they corrupted might be helpful, you might get a good snapshot of (a) what their actual backup policy is, and (b) whether they are likely to damage other files of yours.
You can also ask them what software upgrades they did on the system during the time in question, since that may well be part of the problem.
Of course, once you determine that you have gotten as much assistance out of them as you can expect to get, you can consider publishing a web page detailing your experience with them and how it does (or does not) correlate with the backup policies that they claim when trying to impress potential customers.
As a side thought, is it possible that the database program *encrypted* your data file?
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.