[MPICH] Bug(s) in src/mpi/romio/adio/ad_ntfs_open.c

[Rob Ross]

Hi Robin,

We'll have a look at ad_ntfs_open.c; that does sound like a bug.  We 
will also have a look at the error code creation in that case and see if 
we can work something up that is more effective; clearly that particular 
error message, on your platform, with that file system, is useless.

Users vary widely in what they would like in error messages.  More 
development-oriented users want exactly the sorts of things that you're 
discussing: stack traces, system calls, etc.  Other users want a string 
that says something meaningful, like "file foo cannot be accessed for 
reading", and are confused when they get a bunch of details.  There's no 
one solution that is right for everyone, and no one has time to 
implement a collection of solutions and let the user pick.

Regards,

Rob

Robin Boerdijk wrote:
> Hi,
> 
> There is a bug in src/mpi/romio/adio/ad_ntfs_open.c. In line 40, the
> second argument of the Windows CreateFile() call is hardcoded to be
> GENERIC_READ | GENERIC_WRITE, but it looks like this argument should
> have been set to the 'smode' variable that has been set up in the lines
> before.
> 
> This bug causes MPI_File_open(..., MPI_MODE_RDONLY, ...) to fail on my
> Windows machine when executed on more than one processor. The attached
> test program shows this. This test program is designed so that it can
> be included in the test/mpi/io directory and built and run using the
> existing createprojects.wsf and runtests.wsf scripts.
> 
> One thing I noticed when running this test is that the error message
> produced by MPI_File_open() is not very informative (something like
> "Other I/O Error: No error"). I think this is caused by the fact that
> line 60 of ad_ntfs_open.c uses strerror(errno) to produce the error
> message but, apparently, Windows does not set errno when CreateFile()
> fails. It would probably be better to use
> GetLastError()/FormatMessage() to get the error code and produce an
> error message. I hope this can be fixed as well (presumably in more
> places than just here). 
> 
> Now we are on the topic, I would also like to suggest to include as
> much information in the MPI error messages as possible. So not only the
> error message produced by strerror() or FormatMessage(), but also the
> original error code and, preferably, the name of the system call that
> failed (so that I don't have to look it up in the source). Good error
> messages help a lot in solving problems and it is one of the first
> things I look at when judging the quality of a piece of software. I'd
> be happy to assist in this effort if needed.
> 
> Best regards,
> 
> Robin Boerdijk