Win 10(?) Problem with ACCESS() Function

[O_Sullivan__John]

A legacy program compiled with IVF Composer XE 2013 SP1 Update 3 Integration for Microsoft Visual Studio* 2010, 14.0.0092.2010, uses the Fortran Portability Function ACCESS(name,mode) to test whether a user has network access to a particular license file.  Access is granted by assigning the user to an Active Directory Group that has read access. 

The ACCESS call uses the mode as "r", which is supposed to test for read permission.  It works fine on Windows 7, but after a recent OS-only update, in Windows 10 ACCESS() is now returning " EINVAL", which is supposed to mean "The mode argument in invalid".  Apparently, the hard-coded "r" is not getting included in the call.  A second or third execution of the program within a few minutes will work properly without encountering this error.

Does anyone know if this is a problem with Windows or with IVF?  Any suggestions on getting past this would be very welcome.

Thanks very much, and God bless!

Jack

[andrew_4619]

Having used IFORT and its predecessors for many years I have never come across the ACCESS function. Have your tried the standard INQUIRE function?  e.g INQUIRE(FILE=filename. READ= rd) ?

[Steve_Lionel]

I am not seeing this behavior on a local file on Windows 10. I tried the example in the manual, specifying the source file of the program. I got 0 for the first call (rw is ok), and 13 (EACCESS or Permission Denied) on the second.

I repeated this with a file on a network share using a mapped drive letter - same results. Then with a UNC path - again, same results.

Network access, though, has always been a tricky thing, with inconsistent results rather common.

I do agree with Andrew that it would be preferable to use INQUIRE, though you can't ask INQUIRE if something is executable.

[O_Sullivan__John]

Thanks very much, both Andrew and Steve.  

It turns out that this error is showing up after several years of no-problem network access testing.  We'd thought it was something peculiar to Windows 10, but now I have reports of at least one Windows 7 installation throwing the same error.  I'm beginning to wonder if it might have to do with recent Windows fixes to the Spectre and Meltdown problems.  Might the older Fortran compilation be tripping over itself now that they are cleaning up the search-ahead?

In any case, we'll put on our to-do list to try INQUIRE as a replacement for ACCESS.  I can't remember now why I opted for the former -- probably just a by-product of advanced-age ADD ;-)  It's not yet worth a re-issue of the program with all the accompanying validation and redocumentation storkdance since we do have an easy work-around: try again and you'll likely go through.

________________

Sorry I missed your "Retirement Party", Steve.  I seem to recall that I was the first person to reply to your first announcement here in the Intel Fortran Forum after several years of our exchanges under the Compac VF regime.  (At that time, my forum moniker was jackosullivan, which for some reason got lost recently.)  Hope you are enjoying your "liberation", and so thankful that your "retirement" doesn't include leaving all us other Forum "retirees" in the lurch.  Thank you so much for your amazing contributions to the computing community.

God bless!

[Steve_Lionel]

I believe that the behavior change is not related to the compiler at all - especially considering that the implementation of ACCESS isn't in Fortran at all. I'd guess it is an issue with the particular network stack you are using.