Date: Sun, 8 Feb 1998 13:57:06 +0200 (IST) From: Eli Zaretskii To: "Salvador Eduardo Tropea (SET)" cc: djgpp-workers AT delorie DOT com Subject: Re: fopen and SHARED files In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Fri, 6 Feb 1998, Salvador Eduardo Tropea (SET) wrote: > Windows 95 interprets the compat mode as "DENY WRITE", that means: if a > djgpp program uses the compat mode to open a file (for read only) then other > djgpp tasks can only open the file for reading. That means: other tasks can't > write to the file. This is not entirely correct, AFAIK. Under Windows 95, when a file is open in compatibility mode, other programs *can* open it in write (or read/write) mode; but when the other program tries to actually write to the file, it gets an error code (EACCES). However, as soon as the first program closes the file, the second one *can* write to it using the same handle it got from the original `open' call. In contrast, DENY WRITE will fail the attempt to open the file, which is quite different, at least in the case that different programs access files for short periods of time (i.e., if they use the open/read/close paradigm). Another case which will fail is when the same program opens the same file more than once. I am not sure whether this change will not break something, since the code that reads from or writes to the file can be quite far (in both time and source lines) from the code which opens the file. > int __djgpp_share_mode=SH_DENYWR; I think it is safer to make this 0 by default, so it would be backwards-compatible to previous versions. > fd = open(file, oflags | __djgpp_share_mode, 0666); I think it is wrong to add sharing bits unconditionally. IMHO, it should only be done if the user didn't request specific sharing bits. If the user did, the exact sharing bits specified should be used. > The only problem I can see with that is if the user tries to open the same > file two times in the same task (one for reading and the other for writing), > with this new code it will fail, but I think that's better because the > results of a success are unpredictable (the files are buffered by the libc). The file is *not* buffered by the library if the program uses `read' and `write', or lower-level calls. It is IMHO incorrect to prevent such code from working. In sum, I think that adding the `__djgpp_share_mode' variable which will default to zero, and using it inside `open' if the caller of `open' didn't specify any sharing bits, is the best compromise. I suggest you submit a patch for `open' along these lines.