Ooo, a mystery bit of script! Seems legit. Let's see what happens when we run it Monday is upon us, and with it another confession from a Register reader to make one consider one's own programming choices in the latest entry of our Who, Me? saga. This week's tale comes from a person we'll call "Chris" and is set in the closing years of the last century, back when Windows 95 first introduced an uncertain …
in the rain next to an abandoned mansion. We decided to go in to spend the night. Later that night my partner found a secret passage leading underground, while an electrical storm raged outside. Naturally we went down. There we found a coffin. After a short discussion we decided to open it. Contained within was a vampire and a thumb drive. The vampire and my partner both perished.
Should I plug the drive into my personal computer or a company server?
Ah but then you have to choose the correct wording in your warning-before-you-proceed message.
Consider a Win2k system that detects errors in your filing system, and it helpfully offers to "repair" it for you.
"Yes", this naive person clicked.
Cue a screenful of helpful lines reporting what it found wrong.
Cue a 30GB disc fragged into same-sized chunk with helpful names such as filexxxxx,frag where
1 < xxxxx < infinity
Yes, definitely naive in believing the "warning-before-you-proceed" message.
Cue a 30GB disc fragged into same-sized chunk with helpful names such as filexxxxx,frag where
That sounds like FAT to me. Never had such calamities with NTFS, except that time I was using a slightly faulty drive (with early onset dementia).
In any case, what was the alternative (to pressing 'yes, fix it')? As I recall, with FAT chkdsk would produce those files when it found clusters marked as used, with no directory entries pointing to them. If the original directory entry happened to be in a now-deleted directory, the cluster containing that directory could very well have been overwritten and since released. Pretty much a fool's errand to piece it all together.
OTOH, IIRC each cluster entry (in the allocation table) would point to the next cluster. So chkdsk could've checked "is the next cluster in use by a different file by now..?" and made a more educated guess. If caught early, the next cluster would most likely still be intact. I'm a bit surprised that chkdsk did not do that for you. (you mentioned the files all had the same size, presumably reflecting the cluster size)
OK, asked differently: Was there any chance that you would have researched this deeper, used a different computer to download a better tool and done this properly? (basically the original disk should've been put in forensics read/only mode to not corrupt it further)
Yes, FAT. As I said : naive. I thought M$ had provided a seemingly useful tool, and I was not officially in IT support.
Not so naive that I had not backed up all my data after previous uses. Not so true of the other users of that same computer (a data collection machine, off network to reduce response latency).
So I used to run a radio station or two amongst other things I've done. There are two main programs used for running the station:
A scheduling system that picks the music according to a template (or clock as it's known). Also a playout and automation system that uses a running order from the scheduler to play out the music, news etc.
One station only had a one live show that was networked over several other stations. This ran at 10pm Sunday to Thursday. When that wasn't on the system was in automation. That meant it was either playing out pre-recorded shows or just music, jngles and news. The news came from IRN and there was a bleep every two seconds if the news bulletin wasn't being read. Could also be soundbites/interviews broadcast for your station's news team to use.
Basically the automation computer was in the server room and fed directly to the transmitter. If there was a live show I just filled the hours with loads of instances of a 3 minute silent song. There were top of hour markers in the template that kept the system in sync. They told the automation to fade the last song into the news jingle. It backtimed everything so that the end of the news jingle was exactly on the O'clock. It allowed for their being less music in the hour because of the DJ talk time on live shows
For the news there were also differences for a live show. The automation news item in the scheduler had a command to open the feed from IRN on the automation computer in the server room for 3 minutes. After that it closed the feed and then it played whatever was next in the running order Normally this was a jingle followed by some music. This was direct to the transmitter and post studio. The other was called something like Live Show News. It was just 3 minutes of silence and didn't have any command attached.
I was handing over this station to someone who would be running it full time. I tried to make the handover as painless as possible for the new manager. I explained how the automation worked, how to change things in the playout system etc. I was very careful to explain that the automation system would keep running during the shows. As I'd already set up a template for the show in the scheduling system it should have been a doddle.
The new manager was happy with all of that. I'd writen it down in an email too just in case. So one night they're doing it by themselves. It's a running order I've put in so should be fine. Told I'm not needed I went home and came in the next day. The new manager after I'd left had decided to change how things were done. In the scheduling system they'd deleted my running order entirely. They'd taken out the "unneccesary" top of hour markers during the show and picked the opposite news to the one they needed.
So at 22:00 there was no news for listeners to my old station for the first 30 seconds. The DJ was expecting the news to play automatically like normal. He rectified this manually in the studio by fading up IRN on the mixing desk. Then as the top of hour markers weren't there the schedule went out of sync in the server room. The automation computer opend the IRN feed as soon as it reached the news command not at the top of the hour.
So during the show there were 3 minutes of IRN bleeps an hour on top of the show. Also in one hour there was a bonus of the tail end of some interview. They weren't monitoring the off air feed in the studio so didn't know about the bleeps. The 1am news was fine though as that hour hadn't been touched. A listener had emailed what they'd heard to the station address. I sat down with the new manager and re-explained/fixed everything. I pointed out where and when to use which commands and what things were mandatory. That was the only time it happened, I made damn sure of that.
I can honestly say no, I have never just run a script or piece of code without having an idea of what its *supposed* to do. Whether or not it actually did what was expected is a slightly different story.
But on the printer front, back in days of old, someone crossed out a note in a shift hand-over that said "DON'T print the output from this particular stock control run". No-one on the evening shift questioned it, so when I came in on the nightshift we just plodded on. Queue several thousand pages of fan-fold paper (printed on an old LP3000 printer - those of you old enough to remember will know what a pain in the proverbial that can be stacking paper). What a fun shift that was (only 2 of us in that night). The meeting with the Ops Manager was also a hoot when I pointed out what had happened and that it wasn't my fault.
Yikes! That brings back many unhappy memories. Our company changed paper suppliers briefly, and on some jobs we had 3 or 4-ply layers interleaved with carbon paper. Of course, when the cheaper stuff arrived it was either like that loo roll where the perforations never line up, or the last copy was illegible due to money-saving crap carbon.
I have to ask if you remember the dreaded decollators which the "new guy" on the shift always got to operate? Y'know, all 15 boxes...
The "perforations not lining up" issue with toilet paper is caused by having torn off just one of the two plies for a full turn (so you are now tearing between the two plies). Each row of perforations is the same number of mm from the last, but each millimetre of paper occupies a different number of degrees around the roll. So the perforations in adjacent layers cannot be expected to align.
The problem can be fixed the same way it was caused.
"and on some jobs we had 3 or 4-ply layers interleaved with carbon paper."
Oh, that just brought back a horrible memory. Customer was printing SEVEN PART fanfold. Called us up to say the printer wasn't working properly, bottom two copies were unreadable. I arrive on site expecting one of a number of problems, eg head gap too big, worn head pins etc, the usual stuff. None of the diags showed any issues, feeler gauges showed everything within tolerance, cleaned and lubed all the relevant bits, but still no joy. Having been there for a few hours, some guy from the shop floor comes over with a report and mentions how crap this new paper is. What new paper? says I. Oh, we changed suppliers last week, he says. Got any of of the old stuff left? says I. Put the original suppliers paper in, everything is hunky dory and report goes to my boss and their boss pointing out the fault was of their own making and therefore a significant call-out charge would be levied.
We had several label printers that had a diagram inside showing which way round the labels went. However, bean counters found a cheaper alternative that meant you had to put them in the other way. (Think of the internet meme about which way to hang the toilet roll on the holder).
After several calls about not printing due to labels put in wrongly, I used my initiative and went round with stickers to cover the diagram with the "new" way of putting in the rolls. Didn't make any difference, I would go to a printer and found that they would ignore the sticker or just peel it off - and then scribble on the remains.....
... the dreaded decollators ...
Ah yes. And trying to be the first to crank them up so hard that the carbon paper hit the ceiling!
Personally, I always preferred the burster & trimmer that used to trim the perforated strips off the paper and split it at the page perforations with a resounding and very satisfying thunk!
Of course, if someone I know emailed me with a touching romantic executable message in the 90s, I guess I'd run that at work just to see what it was as well. .... El blissett
Is GCHQ/Anyone else anywhere else working developing those a great deal further embracing and applying greater future use of ITs Adorable Captivating Feature for the Victory Captured and Lavishly Entertained ....... with Almighty Rewards which be Simply Heavenly Just Desserts for Sharing/Exchanging?
If they are not, they all should be .... imho.
Did you read the Snopes write-up?
Err, yes, I did.
If you read the Snopes write-up it quotes the apocryphal tale that it was Nat-West, however this is not the case: "a small UK-based company" does not equate to "A large bank".
Also:
Only a very small number of “Dear Rich Bastard” missives actually went out, rather than the 2,000 commonly stated in tellings of this event.
My bank which I won't name used to do premium accounts. The sort that gave you mobile/travel insurance, car breakdown cover etc. for a fee. I was asked by my branch manager if I'd like one and I said not at that price thanks. He says I can have it for free if I keep a grand in there. I did the sums and worked out that it's a no brainer in my case. The cost of the insurance etc. was way more than the interest I'd earn. Plus the account pays (another pathetic rate of) interest too. So that money comes out of my savings into the new account. I don't touch it....a few years pass and I get a letter from the bank about my account. They tell me that I have had the account for free before just by keeping my grand in there. Sadly now this won't be the case and it's going to be just under 20 GBP a month. This will start from the beginning of next month so I have 28 days to close it.
I took the letter in to the bank and eventually saw the manager. He looks at the letter then at the computer and says it's complete bollocks in my case. He took a copy but told me to just ignore it, "Someone's fucked it up". A week later another arrives from the bank this one informing me that it was indeed a mistake and they are very sorry for the cockup. When next in the bank the manager spots me and tells me that there were a shed load more letters sent out like mine. If they had a black circle at the bottom it was supposed to say you weren't going to have to pay. If it had a black square at the bottom it was supposed to say you're going to have to pay. I told a colleague of mine over lunch about this and he looked stunned. I thought it might be the size of the cockup that had bowled him over. No he spent the rest of lunch complaining that he'd always paid for the account. How the hell I'd got away with never paying was beyond him. He'd be writing to the bank, closing the account etc.
I've still got it and I've claimed on the insurance a few times which has been very handy.
I did on one occasion use a provided script on a database running on a VAX 11/780. Knowing it would take a long time to provide the relevant analysis I left it running over the weekend, Monday morning I found 3 boxes of fanfold printer paper on my desk so around 5,000 pages. I hadn't noticed that log switch in the script was turned on so it had printed every analysis action before finally giving the summary I was after, the operators just assumed it was deliberate and allowed the print to complete.
I wasn't short of scrap paper in the office for the rest of my time in the role but couldn't take it home to reuse as it was Government data (albeit very low level).
"I hadn't noticed that log switch in the script was turned on so it had printed every analysis action ..."
A loooong time ago, in the days of punched cards, a friend of mine did a project at uni. Unfortunately he hadn't formatted the output properly. So, instead of using all 80 columns of a card his program only used one, massively increasing the number of cards needed. Apparently after his program had gone through the third box of cards, the operators cancelled his job.
"Similar vintage a friend got the Fortran control characters wrong so it threw a new page instead of a new line."
This was quite common as the first column was generally used as a page control. If there was a number there it could cause this one line per page problem. Or even worse, overprinting on the same line until the paper tore through.
I can remember doing a summer programming job when I was at university for a certain company (I'll leave their name out of it - you can try to guess). One of the full-time programmers wanted a print out of an application he was working on. However this was on an IBM 370 running CICS - one of the most evil systems around. Anyway said programmer submitted the print job, but managed to miss the print queue and hit a punched card queue instead. He ended up with an 18 inch stack of punch cards on the corner of his desk and a very bemused expression on his face.
Those where the days ....
A long, long time ago in an East London outpost of the University of London I took a Fortran 77 module (course). The computers used were BBC Micros with 32 bit coprocessor attached via the Tube (interface, not the mass transport system or TV show). It ran a multiuser system with some sort of per user access privileges. One day I noticed that someone who should have know better had left without logging out–or rebooting, which was the quicker option in those days of ROM based OS's. I couldn't resist "playing" with the higher access privileges...after a bit of tinkering I discovered "add student" did what you might expect and a couple of "test" users with mature, innuendo free, names such as Ivor Biggun were added. At the end of the session I decided to undo my actions and tried "delete student" unfortunately it turned out that this deleted the login credentials of students. Queue swift exit...
... 'Are you sure you wish to proceed?' ...
I now add multiple prompts, each detailing precisely what is about to happen. This usually triggers the following sequence:
1 System prompts 'Are you sure you wish to proceed?'
2 User enters yes / clicks proceed
3 Repeat 1 and 2 until no more prompts
4 System produces hourglass
5 System removes hourglass.
6 User wonders what happened.
7 User wonders what the prompts said
8 User rings support to ask where their files / database have gone.
9 BOFH orders more carpet and quicklime.
2 User enters yes / clicks proceed
Mainframe days .. we had a monster monthly accounts job that was so data intensive that there wasn't enough space on the volume to accommodate 2 months of data at once, so the developers had put in a message for us lowly Ops: that we had to reply to once the long-running update had completed: "Delete Previous File?". The official answer was "Yes. Delete Previous File" EOB and the job would do just that and apply all the updates, taking around 4 hours.. That answer in bold on the shift notes.
However, us noobs that didn't think like Ops at the time and would invariably reply just "Yes" and due to a lazy designed-in-the-pub logic, the job would silently delete the previous file, not apply the updates and then end in about 10 minutes. Sadly, this would only come to light when the Ops Manager checked the job timings the next morning, and all hell would be let loose when a full restore from tape had to be done and the job rescheduled for the next night...
Amdahl had a largish printing facility just off Central Expressway in Sunnyvale (Cupertino?) in the 1980s. Virtually every mainframe print-job generated within the company, world-wide, was printed at said facility, and then next-dayed to whatever office had requested the print job. They had several gawdawfulfast channel attached printers, and a fleet of trucks delivering & sending out paper. Was awesome to watch in full-swing, if you had adequate ear protection.
However ... it sounded daft then, and still sounds daft now.
... no, I have never run a script without first understanding what it did ... at least not on production systems, nor personal systems that were important to me. Same for strange executables.
There is a reason for test systems. This is one of them. Anybody who doesn't understand this concept shouldn't have a level of access that can cause damage. They are quite simply not trustworthy.
There absolutely is. Except that there are companies that can't be arsed to have one. And I still have to go in and create functionality on the production server, because they need that functionality. So I go and code in production. Extra carefully.
Even then, I have had the odd phone call or abrupt face-to-face with a guy who asks me why did the mainframe do this supplementary job ? I answer "because I was told to put this file there".
Cue much anguish about how he needed to go and sort the mess out on his side. And now I have to continue coding without being able to actually test my code because if I do, I've just learned that another system will take that as a cue to go and do its thing, which nobody told me was going to happen.
You live and learn. That's life.
No doubt leading to the normal scenario of the manager who requested the new feature taking all the credit and glory for it, but of course if anything at all goes wrong it's entirely your fault and nothing to do with them at all.
Not that this has ever happened around here, oh no...
Absolutely.
Back in the 1980s I was working in a company that was using Unisys kit (actually rebadged Convergent Technology systems) running CTOS. These could be "clustered" together into small networks. Downstairs, the boss and admin staff used a system that consisted of a network consisting of a master computer, with the hard disks attached, and two or three networked slave machines. Upstairs, each developer had a single computer but one developer (let's call him Derek, mainly because that was his name) had quite a powerful system.
When the downstairs master computer had a problem the boss decided that Derek's computer would have to act as the master computer for a while. Derek did warn them that, in the process of developing software, it was possible that we would often crash the computers, but the boss wasn't deterred. Derek had also discovered (via the CTOS API manuals) that there was a system call that forced a deliberate crash. He wrote a small program to call that API and every so often, when he was bored or whatever, would whisper to the rest of the developers (who were safely isolated on their own systems) something like, "Listen for the shouts downstairs." Then he'd run the program to crash the network resulting in cries of anguish below. He'd then shout out something like, "Sorry, but I did warn you that we often cause crashes."
It didn't take too long before a new spare computer was made available and Derek's system became disconnected from downstairs again.
He should just think himself lucky that the normal response didn't kick in when it just did a quick hour glass change.
I've known many who would just sit there trying it again and again, presumably expecting something different or more enlightening to happen at some point. I think the record I've seen is something tried 25 times.
I have .bat, .cmd, .ps1 and .py files (and possibly some others) set to open in notepad++ by default, just in case they're accidentally executed from the Windows GUI (I've had it happen both by fat-fingering and by Windows taking a moment to appreciate the beautiful day we're having outside, before dutifully executing all of the keypresses and mouseclicks that had queued up while it was frozen).
I also have the same for .sql and .config files, though that's to spare colleagues the sound I make when I'm waiting for Visual Studio or SSMS to shamble itself together.
Once upon a time at a previous employer, I discovered a notepad process without a window on my corporate ID adminsitered laptop. Further probing with process explorer revealed that it was opening a vbs file. This appeared to be part of the login process, but vbs was blocked from executing as a security precaution.
Way back when in the days I was coding MS-DOS machines for image processing, I wrote two (harmless) programs that simply trapped interupt 9 (keyboard), discarded keyboard input, and did nothing except blink the screen and say the computer has crashed. Only a hard reset worked. I called these two variant HANG.EXE and CRASH.EXE. Everyone had to try them at least omce
When I was acting CTO for a small company 20 years ago I kept on a share available to devs 2 small programs: DoNothing.exe and DoNotExecuteEverVeryHarmful.exe
The first one did nothing, it was mostly used as a replacement for other exes when testing scripts.
The second one was a version of a demo program for a game coming from Ubisoft (I think) at a time I was working in the gaming industry.
It was displaying an Explorer-like window showing the content of the C: drive, and then asked the user if he wanted to delete everything, with a "Yes" "No" choice.
It was impossible to click on "No", and after a short while the mouse pointer moved by itself and clicked on "Yes"...
This was followed by the Explorer window showing all the content being deleted, including of course the Windows folder, before asking for a reboot.
Of course nothing was deleted, and the final screen showed information about the game to be released.
It usually took less than 2-3 days before a newcomer decided to execute this program and begin shouting in horror seeing the files "deleted"......
One of our developers wrote a windows service which polled a database once a second, and if for some reason it didn't get the answer it was looking for, he set it to send himself an email. Unfortunately, he didn't put in any code to see if it had already sent a previous email.
He deployed the code on a Friday afternoon (a big no-no in itself).
Later on the Friday evening, some other part of the project wrote an incorrect value into the database. So his bit of cheap and nasty code started sending error emails, once a second.
I got paged on Sunday morning because our SpamTitan spam blocker had finally had enough, and got a bad case of indigestion with 140,000 emails in its queue. It took me a while to identify where all these emails were coming from, and kill the offending service.
The developer was given a royal bollocking on Monday morning.
The product was supposed to read some sensors around 1-2 times a second, log the values and then send an email if they were out of the acceptable range.
The developer queried this, and suggested that maybe the emails should only be sent once an hour. The PM rejected this suggestion.
So the dev duly wrote the script, then tested it for 20 minutes.
The PM changed their mind.
Long ago, one HP engineer, at our site, noticed 250 000 alerts not routed to any group in VPO, our GDC monitoring tool. They were in limbo ...
What to do ? Of course, on a friday afternoon, mass select all of them, remove them and fuck off for the week !!
Result ? Oracle underlying DB of VPO went totally up the curtains in terms of rotating DB transaction logs, filing all archives like there was no tomorrow. For the whole WE ...
The system dude oncall didn't really like this. Struggled a lot with the amount of data that were never backed up on time :)
A sysadmin friend and I were swapping war stories about managing mail relays.
Friend got a CPU alert for their Sun E250 Postfix servers (this was a few years ago). They logged in and found that a certain dev had sent some hundred thousand messages to their own pager. My friend didn't see anything that required intervention, and logged off.
Long ago I worked for a company that put its systems on Data General minicomputers. The system administrators at the customer sites were not highly trained, but could be counted on to do backups, restart the machines, etc. One day we received a call from a customer. The administrator there had been working his way through the Commands and Utilities handbook, and had arrived at FORMAT. I don't think he managed to format the root drive--for that, as I recall, one would have needed a systape. However, the disk that he did manage to format had a lot of files.
It must be an age thing, but when I was taught to program in Pascal we were always told to add comments detailing what we were trying to achieve with out routine. Every script, batch job and program I've written ever since has always had at least a few lines describing what will happen when run. With my advancing years and broken brain I rely on a quick scan of the notes before I run anything.
A coworker once wrote a "cleanup" script for a C# project. It was meant to run from inside Visual Studio, so it was something like:
DEL /S $(OutDir)\*.foo
DEL /S $(OutDir)\*.bar
DEL /S $(OutDir)\*.xml
After said coworker left, another coworker took responsibility for that project. Don't remember the details, but at some point he ran the script by double clicking it.
He spent the afternoon picking files from other computers to try and make his system stable. Then, when he thought all was fine, he tried to reboot. Of course it wouldn't come up again.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
