Attribute vs. Share: Choosing Accidental-Modification Protection in MS-DOS

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?