From:	Martin Str|mberg <ams AT ludd DOT luth DOT se>
Message-Id:	<199806132329.BAA12138@father.ludd.luth.se>
Subject:	Re: UMSDOS
To:	broeker AT physik DOT rwth-aachen DOT de (Hans-Bernhard Broeker)
Date:	Sun, 14 Jun 1998 01:29:36 +0200 (MET DST)
Cc:	djgpp-workers AT delorie DOT com (DJGPP-WORKERS)
In-Reply-To:	<Pine.LNX.3.93.980608123347.24150E-100000@acp3bf> from Hans-Bernhard Broeker at "Jun 8, 98 12:41:28 pm"
MIME-Version:	1.0

According to Hans-Bernhard Broeker:
> On Sat, 6 Jun 1998, Martin Str|mberg wrote:
> 
> > Following the links to links thread with interest, I want to know how
> > you look at the issue of porting Linux UMSDOS system to DJGPP. 
> 
> I think this has even less probability of being done than VFAT support in
> plain DOS (which seems to be available, at least for OpenDOS users). The
> basic problem is that this kind of operation can only be implemented
> sensibly by the operating system (or the multitasker, if the OS itself is
> singletasked).  Otherwise, we'd get into loads of problems with several
> DJGPP programs trying to modify the 'hidden' datastructure simultaneously. 
> 
> Just think of two DJGPP programs working multitasked (under Win3.1, where
> no VFAT support exists), both operating on files in the same directory.
> Result: crashes, corrupted long filenames, or even corrupted file system. 

Well I don't see a problem there: there are some enticing functions in
DJGPP's libc like _dos_lock(); although I suspect that only works in a
networked environment. Nevertheless, I can always resort to
open("./lock", CREATE|EXCL) or something like that (I don't remember
the syntax right now). That operation must be atomic at least. I hope
that this is the case even for DOZE boxes in Windoze.

What kind of synchronisation functionality does Win31 et al. provide?
Perhaps it is possible to know/detect if this is plain DOZE or a more 
multitasking environment and only then bother with exclusion locks.

Thoughts anyone?


Throwing Muses, Limbo,

							MartinS

- Raw text -