Using device number-inode pairs fixes the symbolic link problems
(and, I believe, does a slightly better job than the "realpath" function
which is the most obvious approach).
I'm told this doesn't work over NFS.
I don't think I was told _why_ it doesn't work but I guess NFS
has some kind of restriction like not being able to obtain the
"absolute name" (eg IP address + device number) of the disk
you're grabbing files from.
That said, comparing absolute filenames or (less portably?)
device-inode pairs would probably catch most cases and would
certainly be good enough in the case you describe.
If someone would be good enough to send some code I could include in
Hugs, I'd be happy to do so. It either has to be completely portable
or it should include appropriate autoconf tests so that it reverts to
the current behaviour on systems that lack appropriate system calls.
Given the upcoming Hugs-GHC merger, it might make more sense to write
suitable code for GHC and wait for the merger to complete - I believe
they have similar preferences.
(Yes, it'd be easier if I'd volunteer to do this but ...)
Alastair
> > 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".
>
> > Sigbjorn Finne replies:
> > > ...
> > > 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.)
>
> As Sigbjorn hints at here device number, i-node number pairs (which
> you can get with fstat(2)) give you unique IDs on Unix. Is there some
> reason this won't work?
>
> mike
