Sender: vheyndri AT rug DOT ac DOT be Message-Id: <3497AB79.416C@rug.ac.be> Date: Wed, 17 Dec 1997 11:37:45 +0100 From: Vik Heyndrickx Mime-Version: 1.0 To: Eli Zaretskii Cc: djgpp-workers AT delorie DOT com, DJ Delorie Subject: Re: Q?on sharing/locking files References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Eli Zaretskii wrote: > > On Mon, 15 Dec 1997, Vik Heyndrickx wrote: > > > Can I expect that when I manage to open a file for writing with fopen, > > that writing is inhibited by all other accesses to this file? > > AFAIK, it's on OS- and compiler-dependent mess. > > On Unix, for example, several processes can happily write to the same > file with interesting results. > On DOS and MS-Windows it depends on whether some kind of file-sharing > (SHARE or VSHARE) is or isn't loaded, and what kind of sharing did you > specify when you open a file. Since fopen does not allow to specify the sharing mode (AFAIK), wouldn't it be better that more sensible defaults were chosen: open for reading -> deny write open for writing -> deny read & write Would this break any code? Specifying the sharing modes would at least not harm anyone if share were not installed (Win95 has it always installed, I think). > The default for DJGPP is to open files > in Compatibility mode. According to my references, this means that > any other DJGPP program should have been able to open the same file > and write all over it with no problems. What do you mean with "no problems"? I think that in compatibity mode, one area of the file can be written and read at the same time (pseudo), with evidently funny results. > However, Windows 95 disallows > any attempts to open the file in either write or append mode (which is > quite wise, IMHO). So even documented behavior is not always > observed (or maybe I'm missing something). I'm currently trying to test some file routines (bypassing any DJGPP routine). I'll check whether this is possible. Just to understand completely well, you say that a file opened in compat. mode, yields EACCESS when a consecutive open-write is issued? > > Or should I lock the file, but how do I do this portably? > > First, I'd suggest to try hard to stay away of this problem if you > can, since even locking won't always solve possible conflicts (see > below). If the problem in point can be solved without requiring > simultaneous file access, try that approach first. The real reason why I asked this, was to test a program that should eventually run on Sun Sparc Solaris. Obviously not such a good idea to test this with DJGPP (or any DOS(y) compiler). > If you do need to lock, use the functions `lock' or `_dos_lock' in the > library (there are also corresponding unlock functions). They aren't > portable, but you could easily write a wrapper around them to have > Unix-compatible `flock' and `lockf', which have similar functionality, > but slightly different interface. > > (Btw, DJ, why don't we have `lockf'? My references seem to imply that > it is POSIX. Isn't it?) Even if it wouldn't be, it would be helpful. Randy Maas sent to me a version of lockf. I'll see what I can do with it. Having better specs would be a must, though. > You should know that on Unix also, locking files cannot ensure that > two applications won't write to the same file. It should at least work under some conditions reliable, else there is no purpose of having locking functions? > For starters, locking > doesn't work reliably across networks, so any file in a volume mounted > over NFS can be scrogged by two different programs. Very painful if you are installing Linux while the files are being updated. > Also, locking on > Unix is ``advisory'': it requires that all the programs that access a > file use calls to `lockf' to see which parts of it are locked, so it's > only good enough for cooperative programs. For 'entire file' locking, I think that DOS does not have this requirement (neither unix BTW). If we could only prevent 2 programs from opening a file so that there accesses may mutually influence each other badly, we were one step down the road, IMHO. > That is why every > application that is serious about this issue implements its own > locking mechanism (Emacs is one example). Isn't there anything Emacs doesn't have? > AFAIK, ANSI doesn't say anything about these issues. DJ? Regards. -- \ Vik /-_-_-_-_-_-_/ \___/ Heyndrickx / \ /-_-_-_-_-_-_/