Be careful with UNC paths and del *.*

R

Red Squirrel

[H]F Junkie
Joined
Nov 29, 2009
Messages
9,211
Just a heads up. :D

Story:

So you know in windows how if you try to delete a bunch of files, if one fails it just halts the whole process? Well I was getting pissed off by this so I whipped up a batch file with a "del *.log*" command and executed it in that folder. I kinda forgot how some commands wont run in UNC paths and default to windows folder. The del command is one of them. Yeah...

Just glad it was *.log* and not actually *.*. It did screw up the server but a reboot fixed the issue. Guess it killed an active log file and the app was not designed to handle that or something.

So yeah, be careful with UNC paths and destructive commands.

This also begs a few questions:

MS invented UNC paths, why can't they be natively supported properly as a normal path?
And WHY default to windows?! At least default to temp or something! Silly Microsoft!
WHY does MS halt a whole delete or copy operation over one single error?! They've always done this. At least keep going and just show a final status at the end or something.

I can't be the only one who has done something like this, fess up! :D
 
At my last job, we used t-log shipping to sync databases across datacenters. One was active, the other was standby. The DBAs wrote some pretty basic scripts to ship the logs via batch script that would run from SQL.

When you shell out from certain apps, like things that run as admin, they default to c:\windows\system32.

His script went like this: del . t:\logs\*.* /S /F /Q (can't remember exactly what he did, but there was an extra . and it made it delete the current path as well as his target).

Of course, the DBAs insisted that the SQL service account run as admin (which I constantly fought and we changed shortly after this fiasco). And, of course, he forced it and surpressed all prompts. That extra ',' in there made it kill system32 (recursively, if I remember) on the production server we had JUST started using. The machine stayed up. Instead of calling me, he just robocopied system32 from the partner server over to his victim, not bothering to verify patch level or anything.

It bluescreened on the next reboot. Luckily we had the other server and had failed over before I rebooted, since we were pretty sure it was borked.

Fun times... Worst part is that he's one of the smartest DBAs I've ever met. It was just an innocent mistake.
 
Or maybe he was using \\dbserver\t$\logs or something. I can't remember. Either way, he really borked my server.
 
C:\> del *.*

I suppose in Windows 7 then, it would default to your users user folder.

Wait, I just tried it. del \\server\share\test.txt and it definitely deleted the file.
 
cmd cant use unc as a working directory. Use powershell and you wont have this problem :)
 
You can't use a UNC as a working directory, but you can do del \\UNC\Share. I think in the case I'd mentioned, he did something like del . \\unc\share\*.* and it killed the working directory. I wish I'd kept a copy of it.

Yes, PowerShell fixes that...and most other things :)
 
You must log in or register to reply here.
Back
Top