Re: Windows NT 4.0, 95, 98 (?) networked PRN flaw

From: David LeBlanc (dleblancat_private)
Date: Sun Jun 06 1999 - 11:45:43 PDT

  • Next message: Terry Milnes: "Re: Windows NT 4.0, 95, 98 (?) networked PRN flaw"

    At 08:20 AM 6/4/99 -0400, STEVENS, Eric wrote:
    >-----BEGIN PGP SIGNED MESSAGE-----
    >Hash: SHA1
    
    >I suppose that, in an effort to maintain reverse compatibility with
    >old MS-DOS command line gurus, you cannot create a file or directory
    >named PRN.xxx where the xxx is replacable with any extension.
    
    [lots and lots trimmed]
    
    I first encountered this a long time ago when I inadvertantly created a
    file named 'CON'.  Went round and round through most of the snippage trying
    to remove it.  What it boils down to is that anything that has the same
    name as a DOS device (which is a link to an actual device, just like you're
    used to seeing in /dev) is going to resist getting deleted and moved.
    
    The solution is to use a POSIX utility to remove it.  The POSIX subsystem
    is blissfully unaware of DOS, and PRN, CON, LPT1 and the like mean nothing
    to it.  So if you'd just tried rm PRN.xxx, then it would have gone away.
    
    It's kind of amusing to me that the solution is to use a UNIX CLI utility -
    the people from a DOS background never think of it, and the people from a
    UNIX background don't usually think to try UNIX tools to fix an NT problem 8-)
    
    There's a KB article on this one -
    http://support.microsoft.com/support/kb/articles/Q120/7/16.asp
    
    I've found that searching the knowledge base can sometimes save me a lot of
    time.
    
    BTW, you can get a POSIX version of rm in the NT Resource Kit.  I believe
    there are a number of other POSIX shells and subsystems available, some of
    which are free.  If you don't have one, it is also pretty easy to create
    one using VC++ - creating POSIX apps is documented, so int main(int argc,
    char* argv[]){return unlink(argv[1]);} will do in a pinch.  Note that some
    ports of rm and other UNIX tools do run in the Win32 subsystem, and so may
    not remove it.  I haven't experimented with it, but I would suspect that
    various absolute UNC paths may well nuke such files - passing something
    along the lines of \\.\c$\temp\prn.xxx to DeleteFile() might also do it.
    \\?\c:\temp\prn.exe may also work, since it says in the notes to
    CreateFile() that this turns off path parsing.
    
    Also, if someone decides to annoy you by creating these, check the owner of
    the file - should lead to the culprit.  If I caught someone doing this to
    me, I'd set their shell to notepad, or put shutdown.exe in their logon
    script >8-) - something to get the idea across that playing games with the
    admin isn't a great idea...
    
    
    David LeBlanc
    dleblancat_private
    



    This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:48:18 PDT