Yes it's a bug.
Hugs makes no attempt to watch for this happening though it would probably
be easy to catch many common cases by just keeping a list of names (in normal
form!) of all the files in the filetable.
This won't work in all cases though - basically because NFS, symbolic links,
etc
prevent us from reducing filenames to "normal form".
--
Alastair Reid Yale Haskell Project Hacker
[EMAIL PROTECTED] http://WWW.CS.Yale.EDU/homes/reid-alastair/
> Mark Utting writes:
> >
> > As a simplified example of this, the following Haskell command
> >
> > do {s<- readFile "data"; writeFile "data" "123"; putStrLn s}
> >
> > always displays "123", rather than the original contents of the file.
> >
> > I think this is a bug? I/O commands should conceptually be done
> > in the order that they appear in the 'do' sequence?
> > If it is a bug, it exists in Hugs 1.3, Jan98 1.4, and June98 1.4.
> >
Sigbjorn Finne replies:
> Yes, it's a bug. An implementation of the Haskell IO spec should as
> far as possible implement process-local file locking. Specifically,
> when you open "data" in WriteMode (via writeFile), an exception should
> be raised. See 11.3.1 of the 1.4 library report for details.
>
> I don't know if the Hugs implementation does or doesn't implement file
> locking, perhaps its an artifact of the platform you're working on?
> (i.e., no device numbers & i-nodes readily at hand.)
