IOSTAT error 146

When i try to open a file via a network mount point, i get an error 146. Opening via its equivalent \\UNC path works.

e.g. with Z: mounted as '\\server\mountable'

OPEN (LU, FILE='Z:\data\file.txt', STATUS='OLD', ERR=80, IOSTAT=IOS)

fails

but

OPEN (LU, FILE='\\server\mountable\data\file.txt', STATUS='OLD', ERR=80, IOSTAT=IOS)

works.

is this a known issue?

K

ok, i think i've found a workaround...

in a Cmd/DOS box (possibly as admin) type:

mklink /d 'c:\share' ''\\server\mountable'

then this works:

OPEN (LU, FILE='c:\share\data\file.txt', STATUS='OLD', ERR=80, IOSTAT=IOS)

K

...but i will still need a solution to the original issue since our client needs to get written permission signed in triplicate (sent in, sent back, queried, lost, found, subjected to public inquiry, lost again, and finally buried in soft peat for three months and recycled as firelighters.) before he can use the mklink command.

K

OPEN leads to a call to the Microsoft API function CreateFile. The error is reported via GetLastError() and the value 146 means 'The path specified is being used in a substitute'.

I don't have any further information at the moment.

Kenny,

What does 'INQUIRE (UNIT=LU, NAME=FILE_NAME)' return for the different naming cases you are considering? This may give an indication of what is best to use.

FTN95 is good in this regard, as it gives a full tree name for when I use INQUIRE, unlike other compilers that only give the local file name.

John

It may be possible to use the Windows API function WNetGetConnection in order to get the full path and this could be written into the FTN95 I/O library but there are two problems with this.

1. I am not sure that this is the right function to use and
2. WNetGetConnection has the following limitation.

'If the network connection was made using the Microsoft LAN Manager network, and the calling application is running in a different logon session than the application that made the connection, a call to the WNetGetConnection function for the associated local device will fail.'

I've done some more testing...

if the program is started from a DOS box it fails with a 146 if it's started by double-clicking it from a Windows file browser it works!

further, the DOS box itself doesn't know anything about the Z: drive

so, i tried using the 'net use y: \\server\mountable' command and that works for the DOS box, but the windows file browser doesn't know about the Y drive! So i tried 'net use z: \\server\mountable' and now both methods work!!!

so, it appears that 'mount network drive' from a Windows file browser and 'net use' from a DOS box don't know about each others' drive letters!

so, what i will ask the client to try is to duplicate his Z: drive mapping using 'net use' and see if that works...

John, the failure filename that is reported by the INQUIRE command is the 'Z:' version - not the '\\server'

K

I have started to get this problem too, but in an apparently simpler setting. If I try to read a file that is one directory up and prefix the filename with '..\' then I get this error 146. If I copy the file into the current directory and simply open with the filename I get error 10002. I feared the problem may be related to me using the wrong version of ClearWin+. I have been trying a number of versions of FTN95 lately, and I compile clrwin.f95 mswinapi.f95 and mswinprm.f95 along with the program. The versions of those files I have are dated, respectively 2025-03-05, 2023-04-03 and 2024-04-03. All of those are newer than the files that came with my latest version of FTN95 (9.10.2.0) and I vaguely recall copying some new versions that Paul released. But regardless, if I compile with the versions that came with the compiler the problem does not resolve.

Simon

I doubt that it has anything to do with ClearWin+.

I would try using the full path name first (not using ..\). If that works then we could look to find a way to implement the Windows API function PathCanonicalize from Fortran.

Just a FWIW, years ago as I was transitioning my SW to FTN95, I kept getting error messages in the 10000's. I finally was able to determine that this had to do with my DropBox 'getting in the way'.

When I open a file as 'New', I always use 'Replace'. This is because 'New' will fail when the file already exists. 'Replace' apparently deletes the file (if it exists), then creates a new file. With DropBox, it intercepts the delete operation and while that is proceeding (and syncing), FTN95 attempts to create the file. This results in a conflict, and the error is reported. Why it is always above 10000, I have no clear idea.

I discovered it was DropBox when I paused DropBox for another reason and the errors went away totally. Turn it on, errors; turn it off, no errors.

I use a single routine to open/close all files, so I added in a check for an error (any error). If an error occurs, I sleep for 2./15. seconds, then retry up to 50 times. And I record a message every 10 tries (just in case something else is awry, like Excel has a file opened). This message recording every 10th try very rarely occurs, and never more than once.

I have seen other commercial packages have a similar problem with DropBox 'getting in the way'. Most of them do not gracefully recover. For those that don't deal with this well (rare), I turn off DropBox while using the app.

Thanks all. Including the full path seems to have resolved the problem. I've been using the relative path for years, so I don't know why it stopped working. I don't have dropbox installed, but I like the idea of implementing a loop to retry.

simon,

I think the same could happen with OneDrive or any of the automated cloud backup applications like them.

BTW, the problems became less and less (during testing) as my internet speed got faster. Nowadays, very rare!

Bill

Thanks Bill. I'll investigate that.

I have identified a cause of this problem. If there is an accent in the filename or directory, then Open returns the error 146. This problem is not unique to FTN95; any ideas of how to work around that? I see that there is a solution proposed here: https://community.intel.com/t5/Intel-Fortran-Compiler/Unicode-characters-in-file-name-in-OPEN-statement/td-p/832640 but I am wondering whether this can be done in Fortran alone.

If this relates to the Fortran OPEN statement then I doubt that anything can be done in the compiler IO library to fix this.

Maybe there will be a different way for the user to get the file name and then use a RENAME to change the name to one without the offending characters.

Hi Paul, Understood. It seems to affect both OPEN and INQUIRE - the latter returns .false. when using EXIST, and OPEN generates the 146 error message. But you have given me an idea with RENAME ...