Question
Attribute vs. Share: Choosing Accidental-Modification Protection in MS-DOS
Sora Orbit
0 reputation · 22 Aug 2025, 18:51 UTC
14.8K views
Loading…
0 reputation · 22 Aug 2025, 18:51 UTC
When protecting important files from accidental change on an MS-DOS system, the designer must decide whether to rely on the READ-ONLY attribute set with ATTRIB.EXE or to load SHARE.EXE and use its deny‑write locking mode.
The attribute method is simple and requires no resident software, but it is advisory and can be defeated by any program that clears the flag or issues raw disk I/O; its effectiveness therefore depends on the behavior of each application and the DOS version in use. SHARE.EXE provides cooperative locking that returns a sharing‑violation error when another program tries to write, yet it only works if all accessing programs respect the TSR and if the correct version of SHARE is loaded in the environment.
Which approach yields more consistent protection against unintended modifications when considering varying application cooperation and DOS version differences? Under what circumstances does the READ-ONLY attribute alone provide sufficient safety for everyday use?
30275 reputation · 23 Aug 2025, 02:13 UTC
For protection against unintended modifications by standard applications, the READ-ONLY attribute set via ATTRIB.EXE is the more consistent choice. It is a built-in feature of the DOS kernel that does not require resident memory or a specific TSR (Terminate and Stay Resident) program to function, making it independent of the current memory state or the presence of SHARE.EXE.
| Feature | READ-ONLY Attribute | SHARE.EXE (Deny-Write) |
|---|---|---|
| Dependency | Kernel-level (No TSR needed) | Requires resident SHARE.EXE |
| Memory Cost | Zero | Consumes conventional memory |
| Enforcement | DOS API (INT 21h) | Cooperative locking via TSR |
| Primary Risk | Programs can clear the flag | Programs may ignore the TSR |
Both methods rely on cooperative behavior. Neither can stop a program that performs raw disk I/O (bypassing the DOS API entirely), such as disk editors or certain low-level backup utilities.
msdosATTRIB -R or INT 21h function 43h before writing.SHARE.EXE is loaded for the specific DOS version, or if an application ignores the locking protocol, the protection fails.The READ-ONLY attribute alone provides sufficient safety for everyday use when:
SHARE.EXE).To verify protection on your specific DOS version and application set:
ATTRIB +R filename.extSHARE.EXE, verify it is loaded in memory and matches your DOS version to ensure sharing violations are triggered correctly.Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.