View previous topic :: View next topic |
Author |
Message |
KennyT
Joined: 02 Aug 2005 Posts: 317
|
Posted: Mon Sep 05, 2016 3:11 pm Post subject: 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 |
|
Back to top |
|
|
KennyT
Joined: 02 Aug 2005 Posts: 317
|
Posted: Tue Sep 06, 2016 1:37 pm Post subject: |
|
|
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 |
|
Back to top |
|
|
KennyT
Joined: 02 Aug 2005 Posts: 317
|
Posted: Thu Sep 08, 2016 1:53 pm Post subject: |
|
|
...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 |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7931 Location: Salford, UK
|
Posted: Thu Sep 08, 2016 7:45 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2556 Location: Sydney
|
Posted: Fri Sep 09, 2016 1:12 am Post subject: |
|
|
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 |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7931 Location: Salford, UK
|
Posted: Fri Sep 09, 2016 7:29 am Post subject: |
|
|
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." |
|
Back to top |
|
|
KennyT
Joined: 02 Aug 2005 Posts: 317
|
Posted: Fri Sep 09, 2016 8:50 am Post subject: |
|
|
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 |
|
Back to top |
|
|
|