[m-rev.] Small bug in io.file.m

[Volker Wysk]

Am Mittwoch, dem 15.03.2023 um 19:04 +1100 schrieb Peter Wang:
> On Wed, 15 Mar 2023 08:11:24 +0100 Volker Wysk <post at volker-wysk.de> wrote:
> > Am Mittwoch, dem 15.03.2023 um 14:06 +1100 schrieb Julien Fischer:
> > > Hi Volker,
> > 
> > Hi!
> > 
> > > 
> > > On Tue, 14 Mar 2023, Volker Wysk wrote:
> > > 
> > > > In io.file.m, line 839:
> > > > 
> > > >    is_error(Error, "can't find file type: ", MaybeIOError, !IO),
> > > > 
> > > > This doesn't include the file name in the IOError, like it's common.
> > > 
> > > In the current io module and its submodules, the generation of I/O error
> > > messages is entirely up to the I/O facilities of the target platform. In
> > > the above case, FileName is passed to file_type_2/6, which is the
> > > predicate that creates the value Error; some target will mention the
> > > file name (e.g. in the C# and Java grades), some don't seem to (e.g.
> > > Linux / glibc).
> > 
> > When doing a "ln -s aaa aaa" and apply file_type to it, I get:
> > 
> > can't find file type: Too many levels of symbolic links
> > 
> > When creating a file "aaa" with insufficient permission to read it, and try
> > to read it, I get:
> > 
> > aaa: Permission denied
> > 
> > In the first case, the file name isn't included, but in the second one, it
> > is. My target is Linux with an asm_fast grade.
> 
> How are you getting the second one? I think it would be the outlier.

I'm getting it by running my program. I assumed that it was some library
predicate which made the IOError, which includes the file name. But now I've
determined where exactly the io.error occurs, and it isn't. It's a call to
"io.make_io_error_from_system_error", where I include the file name as the
"Prefix". 

Sorry.

Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20230315/9375ac92/attachment.sig>