Curious
Evidently "Pascal" did shoot himself in the foot, despite what is said about the compiler
I'd better be going
Batch file automated a clean-up job, then fouled itself by deleting the wrong directory
WHO, ME? Welcome to another installment of "Who, Me?" – the reader-contributed column in which The Register opens the working week with your tales of IT woe. This week, meet a reader we'll Regomize as "Pascal," who once worked for a company that had just acquired its first Exchange server, home to around 600 mailboxes. "The IT …
-
Monday 24th August 2026 08:19 GMT Anonymous Coward
work 1
We had a couple of contractors in with out team. Nothing odd. Unbeknown to me, one of the permies who looked after the SAN and some of the clusters had spent the last 4 weekends in after mass cluster failures.
I get asked to look and see if I can work out why, but I am also given a clue about to look at a new script / batch routine as it ties in. So I check the routine and on first glance, there is nothing wrong with it. All looks good. I decide to check each line and then on the delete I am asked if I want to delete c:\ and not what was there. I had another look at there was an extra space in the delete command which instead of deleting where it was inferring, meant do it at the root.
I made sure that all the folders etc were now in quotes to make that obvious
-
Monday 24th August 2026 08:29 GMT Anonymous Coward
work 2 - an AD delete
For whatever reason, at this employer we all had Domain Admin. Normally no issues, but one morning I got in to several calls from one of the departments...indeed, nearly all the department and they were mostly all about their machine or the occasional login (laptop users)
I could not work out why as a couple had come down to where our base was in that building and getting them to logon there had issues too - so not just their devices.
I looked at AD and initially there was nothing obvious. A reset and they could get in but had other issues which were all profile related.
I checked a few more things and noticed that the parent OU for that department had an odd created date, infact, last night quite late - and so did everything else.
We were able to get nearly everyone in and then started the investigation as this OU date was a concern and niggled.
Transpires that a team member had "accidently" deleted that OU. Now instead of telling anyone or getting a restore initiated / performed, they had decided the way to "fix" this was to recreate the OU and sub OU's (as they were standardised for all depts, so easy to copy) There was a list of all users and then recreate all of them. Took them hours.
Management PRAISED them for their efforts when the rest of us were bewildered at the initial action, the lack of creditable resolution steps, their final methodology, the mess we had to fix and then the management response.
-
Monday 24th August 2026 08:52 GMT Pete 2
Who tests the testers?
> It tested OK
Apparently not. Maybe it passed functional testing on the bench, but it doesn't appear to have been integration tested in a copy of the production environment.
Who is to blame? The manager, for not having the experience to identify the shortcomings before putting it live.
-
Monday 24th August 2026 09:49 GMT RMclan
Read properly before run
Our trade portal with 125,000+ parts on it ran from a single table in our Postgres based ERM.
I flagged about 500 records for deletion. I first ran "select count(id) from table where flag='Y'" to see how many were flagged, then just to make sure changed that to "select count(id) from table where flag<>'Y'" to see how many weren't flagged.
Then without thinking properly I altered the query to be "delete * from table where flag<>'Y'" forgetting to change the <> to =. The database was set to commit automatically if there were no errors.
Luckily it was about 3pm on a Friday afternoon, a quiet time for trade orders for us.
I was able to restore the table from the previous night's backup as no other changes had been made to it during the day., and was back up and running in under an hour.
-
Monday 24th August 2026 11:54 GMT Bebu sa Ware
Re: Read properly before run
It's many decades since I have used SQL in anger but I might have considered an
INSERT INTO <temp table> SELECT * FROM tradeportal WHERE flag='Y'before embarking on the more courageous DELETE. ;)As always best to script this stuff so when (and not if) you stuff up you can discover exactly why and where which invariably saves time in recovery.
It is almost an axiom of IT that files, data etc that everyone has sworn on a stack of bibles will never, ever be needed and should be deleted forthwith become existentially vital within minutes of the last byte being consigned to oblivion.
That's why the sage BOFH make archive copies - knowing as he does the difference between backups and archives - and to engage in a little extortion. :)
I have fished long deleted data off +10 year old DDS (DAT) tape archives that suddenly became vitally important. The real wonder was that those tapes were still readable - DDS wasn't the most resilient or robust tape technology.
-
Monday 24th August 2026 14:17 GMT GlenP
Re: Read properly before run
Last year I had a request for some data from pre-2008 when we migrated to our ERP system (and before I joined the company). I declined gracefully on the grounds that, whilst we still had the data, the program disks, a system that could actually run them and anyone who knew how to run the system were long gone! Had it been absolutely critical I do know someone who could have helped, at a price, but any data relating to a product purchased by a customer 20 years ago is probably invalid anyway.
Post 2009 I have year end copies of the databases just in case which are also themselves backed up off-prem.
-
-
-
-
-
Monday 24th August 2026 12:07 GMT Bebu sa Ware
a strong advocate against capital punishment
Ditto.
But your exception might be reframed as merciful euthanasia† or societally beneficial eugenics.
"Developers… I just wish they would stop developing and be adults."
† I have a vivid memory as a 12 year old of listening to a radio panel discussion concerning "youth in asia." Utterly confusing - completely did my head in.
-
Tuesday 25th August 2026 00:31 GMT doublelayer
Can we add a clause for what they say after that? I ask because I frequently say that, although always with a different phrasing, but my next sentence is always a variant of "I'll need some more information to determine why we're getting different results". It communicates the information that I know it's a problem, it wasn't designed or expected behavior, and there is a way for it to work properly probably without big code changes. It's never the end of the fix process, though if they don't answer my questions, that might be.
In my experience, about half the time, the end result once I've said that is user error, I.E. the proper command works on my machine when the invalid one failed on their machine. Sometimes, I didn't know that because there are many inputs to the process, they thought one of them was the most likely so sent that to me, but the error was in something else. Other times it's because a lot of people don't write detailed error reports, with "it didn't work" being a very common one in its entirety.
-
-
-
Monday 24th August 2026 11:27 GMT 42656e4d203239
AD Tidy-up
Once upon a time there was a large AD system that had a typical mix of users and an equally typical load of AD cruft left over, for many users, as the system evolved.
Someone, lets call him Clarance, decided to tidy it up using a script which checked AD parameters and deleting the cruft where applicable.
Clarance told everyone not to worry - the script would run and everything would be alright...
Sadly this wasn't the case. For some reason Clarence had made an error in the delete logic and instead of updating AD users, who's parameters fitted the criteria for tidy-up, it deleted them completely. It was rather fun (in a macarbre way) watching users getting slowly deleted (luckily fast code wasn't one of Clarance's stong points) from AD and knowing that I was immune, becasue I was a really new user to whom the tidy-up criteria couldn't apply.
The recovery was 'interesting' - not least because many of the users were synced to various O365 Tenants so they lost access to that data as well - and to get it back the AD objects had to have the same GUID... The backup scheme was tested for real, and did actually work, but the incident provoked an anti-O365 feeling in the userbase which persists up to today (despite it not actually being an O365 problem!).
Clarance has nightmares about that slight bug to this day (8 years later) even though he has now moved away from real work and is, last I knew, in a role addressing the tricky "how can we work better using Technology in our organisation" question.
-
Monday 24th August 2026 12:24 GMT Bebu sa Ware
tricky "how can we work better using Technology in our organisation" question.
Only tricky part is determining how little "we" and how much "technology" can we get away with, before we aren't in the 'we' but then I could be taking the piss.
The safest strategy in really large organisations is to evangelise technologies so useless that they cannot possibly do any harm even in the hands of the C-suite.
Clarence wouldn't by any chance be a reference to the cross-eyed lion from the Daktari TV series (and an earlier film) ?
-
Monday 24th August 2026 14:04 GMT 42656e4d203239
Re: tricky "how can we work better using Technology in our organisation" question.
>>Clarence wouldn't by any chance be a reference to the cross-eyed lion from the Daktari TV series (and an earlier film) ?
nope - I was thinking of "clearance, Clarance" in the movie Airplane... becasue the whole situation was/is still just aboout as farcical as that very memorable scene.
-
-
-
Monday 24th August 2026 13:57 GMT 42656e4d203239
Re: AD Tidy-up
>>If 2016 AD/forest level
Ah well there is anther tale. Until the year before last, owing to the powers that be having a domain controller for the internal live domain in the DMZ (! yes, you did read that right) - one of those machines that "can't possibly be upgraded" we were on AD 2003 or thereabouts (It might have been 2008) until a couple of years ago...
I did make myself very unpopular indeed whilst pointing out the errors of their ways - oddly enough when they started whinging that our servers weren't up to date, said whinges accompanied by threats of very large manure piles from those on high, I asked someone very high up why sauce for the goose wasn't sauce for the gander and a few people got educated with a clue bat. Apparently the clue bat wasn't big enough because we are still on AD level 2012R2.
-
-
-
Tuesday 25th August 2026 20:32 GMT RobDog
Just hang on a minute
The Exchange 5.5 admin at my old workplace planned a Saturday morning change to run some or other database related maintenance… Im not an Exchange admin so I don’t recall what it was…but a) it hadn’t been done before b) was predicted to take a few hours to run to completion and c) was initiated via command line.
So he duly got into work, settled in, typed the command and hit enter…nothing happened of note but the flashing cursor did disappear. So he gave it a few minutes, everything looked ok, so he went out shopping for nearly 2 hours.
When he came back, there was a new line that said
“Are you sure? (y/n)”
