fortran binary files

[WSinc]

I am under the impression I can make a binary file that allows random access to a set of fixed size records.

Its allowing me to write records sequentially, but if I pick a record number, I cant do that.

for example if I have 100 records of 20 integer words each, I should be able to pick and replace record number 48, right?

Maybe I dont have the right set of keywords to open the file. But you dont give us any examples that I can find.

[GVautier]

Call getcwd and print the result before the input of the filename to open.

The user will know the current directory and be able to input the correct path to the file to open

[jimdempseyatthecove]

>>The problem is, if it gives you an EOF ERROR without any info, then you have learned nothing whatsoever

Then this is a strong indication that the file opened is not the file you assumed was opened.

IOW in the file explorer, you see the file you want to open, but the OPEN is actually opening a NULL file somewhere else.

This has happened to me many times in the 50+ years of programming. An additional issue often experienced during development is after updating a source file and building an object/lib/dll that you link in or load library a different version of the build. This will get you going for a while with "?I just fixed this??"

Jim Dempsey

[WSinc]

I modified my little test program to allow me to input only one integer(4) per record

to be read in. It fails on the first attempt,  so it appears that STREAM input is a dismal failure.

Of course the concept of a record really has no meaning here, since I am not treating this file is having any KNOWN record structure.

Has anyone out there been able to solve this problem?

I guess INTEL cannot.

[Arjen_Markus]

I have searched for the file you are trying to read, but as Steve Lionel indicated, the best way to attach it - together with the sample program is by using a zip-file. As I haven't seen a zip-file (or indeed any other attachment) I cannot try and reproduce the problems you are seeing.

The only thing I can tell you is that stream access works fine in general and is the correct approach for this of things. What did you learn from the hex browser?

[Steve_Lionel]

Visual Studio has a hard-to-find binary file editor. Microsoft even proposed removing it at one time, but it is still there.

In Visual Studio, select File > Open > File... 

Select the file you want to open, but don't click Open yet. Notice the black triangle next to the word Open on that button?

Click it and select Open With...  A list of editors will appear. Scroll to the end and select Binary Editor:

then click OK.

[Steve_Lionel]

A couple of suggestions to help identify the issue. First, add STATUS='OLD' to the OPEN. This will prevent it from creating an empty file (and give you an error if the file is not there.) I also like to then do an INQUIRE (UNIT=xxx,NAME=sss) after the OPEN, where sss is a character variable of sufficient length (say, 100) to hold the returned file name. I then print the name.

As I asked earlier, add the MIDI file to a ZIP archive and attach the ZIP to a reply here. The forum accepts many different file types, but not .mid.

[GVautier]

Inquire is not very useful because it returns the name used in the open statement not the full name.

Use getFullPathName from Windows API to get it.

I think that an empty file has been created once  in the actual current directory and it's that empty file who is opened now. Using status=old now will not solve the problem without deleting the empty file but it is a good advice if file must exist.

Print he current directory before filename input and you will see that your are not launching the program in the correct directory.

[Steve_Lionel]

@GVautier  "Inquire is not very useful because it returns the name used in the open statement not the full name."

Not true.

D:\Projects>type t.f90
character(100) :: fname
open (unit=1,file='whoareyou.txt')
inquire (unit=1,name=fname)
print *, fname
end
D:\Projects>ifort t.f90
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 19.1.1.216 Build 20200306
Copyright (C) 1985-2020 Intel Corporation. All rights reserved.

Microsoft (R) Incremental Linker Version 14.26.28806.0
Copyright (C) Microsoft Corporation. All rights reserved.

-out:t.exe
-subsystem:console
t.obj

D:\Projects>t.exe
D:\Projects\whoareyou.txt

[WSinc]

i know about the issues re
not being pointed at the right direction. (file location)

however :
1) if i make a scratch file it shows up in the same location.
2) an OPEN statement does not give any error messages when i specify READ ONLY. Why would it make a new scratch file ?
3) When i change the file name it gives me " file not found."
4) it repeats the ENTIRE PATH NAME every time i get an error message.

Have I left anything out ?

[Steve_Lionel]

Yes - you haven't provided us with the file or a complete program to try reading it.

READONLY does not change the STATUS default from 'UNKNOWN' to 'OLD'.

[mecej4]

Bill, you wrote:

2) an OPEN statement does not give any error messages when i specify READ ONLY. Why would it make a new scratch file ?

Scratch files differ from other external files in that 

• You cannot specify a name for the file when opening it.
• When your program creates a scratch file and terminates, the scratch file gets deleted.

Does that not force every scratch file to be "new"?

[WSinc]

If you cannot answer my question, please refer me to someone who can.

Its not like I used abusive language, etc. I have tried to be polite.

I am willing to PAY FOR advice.

Anyway, I have tried all your suggestions, but still getting some weird results.

What is this SAML authenication stuff ? Is that from your end ?

[andrew_4619]

"Anyway, I have tried all your suggestions, but still getting some weird results."

So the small but complete example I posted in your other thread, did you try it? Did it work? What weird results did you get?

[jimdempseyatthecove]

>>What is this SAML authenication stuff ? Is that from your end ?

When Intel switch to the new forum web page design, they introduced a bug in the Log-in process.

To correct for this (at least for me), is to delete the browser's Cookies, then you will be able to Log-in.

I've griped about this to them earlier. Additional gripe, is my preference is to keep a browser open to the site all the time. However, possibly due to lack of activity (sleeping), they force a log out, and when this happens, often the SAML (cookie) problem arises.

>>Anyway, I have tried all your suggestions, but still getting some weird results.

You have been asked to prepare a small reproducer. From your description to date, this could be an under 10 line program plus sample data file. Do not complicate the sample program with things you want to do with the data (that may be a different issue for a different thread).

A memorable quote from the movie Cool Hand Luke:

    What we have here is a failure in communication.

Jim Dempsey

[Steve_Lionel]

You don't have to delete all the browser cookies, just the three sets Intel defines. In the browsers I use, I left click on the icon at the left of the address bar (usually a lock symbol), then select Cookies.

Select each of the cookie host names and click Remove for each. Now click your link for the forum - you will need to log in again.

As for paid consulting, I offer this for $200/hour, half-hour minimum. Let me know if you're interested.

[jimdempseyatthecove]

>>And I can always attach the file on an OPEN statement, but every time I try to read one record it gives me an EOF return, rather than reading in the data.

Your original post was File Not Found. So now you have File Found, but data not being read.

It is likely that the data you have composed for consumption is not conformant with the READ statements you are issuing.

Fortran expects data format compatible with the format specified in the OPEN statement. For example of an erroneous condition, your Open expects textual data, perhaps comma delimited. Fortran expects (requires) the file to be ASCII (7-bit) compliant. Should you create your input file using say WordPad, the default output format is UTF-8, not 7-bit ASCII. To correct this in WordPad you use SaveAs and select Plain Text format.

You should be able to construct a simple program (e.g. with OPEN, READ a record, PRINT a record) and supply a small data file. (assuming the example program exhibits the error).

Jim Dempsey

[Steve_Lionel]

It is almost certainly the case that the program is opening the file in a different location than you expect. If you are running from inside Visual Studio, the default directory is the project directory, NOT the one with the EXE.

What will happen then is that the OPEN will create a new, empty file, which then gets you an EOF when you try to read from it. Look for other copies of this data file and you will likely find an empty one where you don't expect it.

This is a fairly common thing that Windows users run into. It has nothing to do with the data file itself.

[WSinc]

Actually, when I get an error message, I can always look at the path it took in the file directory.

I dont understand why I still sometime get "file not found" when the file directory is correct and the file is sitting there.

[andrew_4619]

Use the full path file name as a good low effort starting point!