home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / alt / hackers / 1952 < prev    next >
Encoding:
Internet Message Format  |  1993-01-22  |  6.1 KB
  1. Path: sparky!uunet!paladin.american.edu!howland.reston.ans.net!bogus.sura.net!udel!apache.dtcc.edu!apache.dtcc.edu!not-for-mail
  2. From: weave@apache.dtcc.edu (Ken Weaverling)
  3. Newsgroups: alt.hackers
  4. Subject: Gotta hack into DOS's COMMAND.COM :-(
  5. Date: 22 Jan 1993 09:20:36 -0500
  6. Organization: Delaware Technical & Community College
  7. Lines: 132
  8. Approved: Bill Gates
  9. Distribution: world
  10. Message-ID: <1jovrkINNetl@apache.dtcc.edu>
  11. NNTP-Posting-Host: apache.dtcc.edu
  12. Summary: I hate MS/DOS
  13.  
  14. Yuck!  Looks like I have to lower myself and hack into DOS's COMMAND.COM
  15. program.  What a drag...
  16.  
  17. The problem I have been having is that my users on our PC network have been
  18. having Sharing Violations triggered and the infamous "Abort, Retry, Fail"
  19. error to greet them.
  20.  
  21. Naturally, they freak out and choose the wrong one (hardly ever Retry which
  22. almost always works since someone else had the file lock). 
  23.  
  24. However, once in a while, someone must reboot or something and a batch file
  25. or EXE file gets stuck in locked mode, and no one else can run it.
  26.  
  27. A real bummer from an admins standpoint.
  28.  
  29. We run Locus's PC-Interface which is nice because it is bare-bones
  30. networking, doesn't chew up RAM space, and allows our Unix hosts to 
  31. function as DOS file servers and I can do all administrative duties from
  32. Unix 
  33.  
  34. (Indeed, we also have software that turns the same Unix box into a Mac
  35. Appleshare compliant server so user files are always accessible whether they
  36. use DOS, Unix, or Macs... but I digress...)
  37.  
  38. So I contacted Locus and after several mail messages, the poor front-end
  39. non-technical person helping me drops a note on me which I should have
  40. realised way before hand myself.   But it leads me to the conclusion that
  41. I have to start hacking at DOS!  
  42.  
  43. Below is my latest mail to Locus.  Anyone else out there have any clues?
  44.  
  45. ============= cut here ============
  46.  
  47. > So, more specific questions are...
  48. > 
  49. > 1) What causes a DOS EXE file to get locked? Does COMMAND.COM do this?
  50. >    Or does certain utility programs lock themselves when they run?
  51. > 
  52. >      'TIS THE WAY THE FILE IS OPENED. IF A FILE IS OPENED IN WRITE DENY MODE
  53. >      NO OTHER USER CAN OPEN THE FILE UNTIL THE FIRST USER CLOSES THE
  54. >      FILE.
  55.  
  56. Thanks, this tells me a lot!
  57.  
  58. The DOS technical reference manual says...
  59.  
  60. "If the file was successfully opened on one of the other sharing modes
  61.  and an attempt is made to open the file again in Compatibility Mode,
  62.  an interrupt 24H is generated to signal this error. The base interrupt
  63.  24H error indicates Drive not ready, and the extended error indicates
  64.  Sharing Violation"
  65.  
  66. Now, INT 24H is the "Critical Error" handler and is what puts up the
  67. ole Retry, Ignore, Fail message, so this looks like what is happening.
  68.  
  69. However, since it seems like DOS's COMMAND.COM program is the guilty
  70. one in all of these cases, it is probably safe to assume he opens 
  71. files in the same mode every time.  ie, since I have had locked EXE
  72. files and BATch files, it must be COMMAND.COM that is opening them.
  73.  
  74. But if he always opens them with Deny Write (like he should), then that
  75. should allow others to open the file for Deny Write access. 
  76.  
  77. But the next paragraph in the DOS tech manual offers a clue...
  78.  
  79. "The sharing modes for a file opened in compatibility mode are *CHANGED*
  80.  by DOS depending on the read-only attribute of the file. This is to
  81.  allow sharing of read-only files"
  82.  
  83. Ah, what the heck is going on here?
  84.  
  85. >From the open table in the manual it indicates that a read-only file opened in
  86. compatibility mode, read-only  will implicitly cause a file to be opened in 
  87. "Deny Write" mode, like you said.  
  88.  
  89. Ah, which brings us around to the top of my hypothesis above. If a file
  90. is opened in Write Deny mode and someone else attempts to open it in
  91. compatibility mode, it triggers the critical error!!!!!
  92.  
  93. So, if the above theory is correct, then I'd say the *bug* is Microsoft's
  94. since a lot of programs don't specify sharing modes and simply open 
  95. files in "compatibility mode" and a read-only file should logically
  96. never be denied access for read-only operation.
  97.  
  98. So, the possible solutions are...
  99.  
  100. 1) Make the DOS executables read/write access. A real bummer. This would
  101.    open up possibilities of students copying trojans or other nasty
  102.    stuff to publically accessible files
  103.  
  104. 2) Get Microsoft to fix it (yeah, right!)
  105.  
  106. 3) Have Locus alter the default behavour. I'd say that this would be
  107.    dangerous and not a good idea, since it won't work as documented by  
  108.    Microsoft and could break a lot of stuff.
  109.  
  110. 4) Request Locus to allow users to remove record locks from Unix without
  111.    having to log out all PCI users first.  (Indeed, I could do this 
  112.    with sharectl -r under server version 2.8.7 but if I do this with
  113.    4.0, everyone's login hangs at the next file access...)  Ideally,
  114.    a Unix utility program to list record locks and allow individual
  115.    deletion of them would be the most ideal.
  116.  
  117. 5) I could dump COMMAND.COM into a disassembler and find out where he
  118.    sets the AL register before a call to DOS function 3D hex and alter
  119.    it from binary 0 (compatibility mode) to 010 (Deny Write) mode
  120.  
  121. Obviously the first three are out, so what I'd like you to do, if you
  122. don't mind, is to forward this note to the technical staff and/or 
  123. programming team and suggest #4.
  124.  
  125. As for me, I will most likely try and patch COMMAND.COM myself and
  126. see what happens!
  127.  
  128. Thanks for your time Julia.  I really appreciate it.  All along, I
  129. thought that the problem was with the record locking function call,
  130. it never dawned on me to look into how files are opened!  (Yeah,
  131. I try and avoid DOS at all costs -- especially programming in it! :-)
  132.  
  133. If you want, I can let you know if my diving into the COMMAND.COM 
  134. binary proves me correct and the problem disappears. I probably won't
  135. get to this until next week.
  136.  
  137. ======== cut here =======
  138.  
  139. So, I guess this posting is an  OBFhack (Obligatory future hack!)
  140.  
  141. -- 
  142. Weave's 10/90 recipe for insanity: Take one programmer, divide into portions: 
  143. 10% programming consisting of equal parts in systems and applications plus
  144. admin duties broken down into 20% for Unix, 5% PRIMOS, 10% hardware & network, 
  145. 35% DOS/Windows, 10% news, 5% postmaster, and 5% babysitting IRC kiddies.
  146.