forums.silverfrost.com

[Anonymous]

Hi,

just now I encountered an errormessage and I cannot detect the source of it:

character*1 cc

open(unit=10,file=mapfiles(jmap),form='unformatted',access='transparent',position='rewind',iostat=ierr)
print*,'iostat=',ierr
rewind 10
do j=1,18
read(10)cc
enddo
read(10)iwidth,iheight
close(unit=10)

This is the code. It works fine for some time, but after a very long piece of program it fails and I receive the errormessage that the read-statement is trying to read past end of file on its first execution.

Iostat gives 0 and the file is existing and more than 900kb in size. I doublechecked all other units to be closed.

Some routine executed before the final open apparently smashes some information needed for opening or reading, but as SDBG cannot give me any clue, I am at a loss where and how to hunt for the malicious piece of code.

Can anybody help me ?

Norbert

[PaulLaidler]

Norbert

1) At first sight it looks like your rewind statements are redundant in this fragment.

2) TRANSPARENT is a non-standard extension which may also be redundant in this context.

3) Using UNFORMATED usually requires that you have used similar write statements to create the file.

4) It is a good idea to use STATUS = "OLD" to make sure that the file exists.

Regards

Paul

[ursuselasticus]

Hi Paul,

thanks for your support.

I usually open a file and afterwards have a rewind statement. The redundancy evolved after I entered the rewind in the open statement to see if iostat would encounter an error. I did the same now with status='old'. Same result. Iostat gives 0 as errorcode (meaning no error occurred) and still I get the errormessage 'Trying to read past end of file' when the read statement is executed for the first time after opening the file.

Right now I thought it a good idea to check the consitency of my data declarations. Got a little bit out of hand lately.

Norbert

[ursuselasticus]

Well, I spent a whole day in checking my data, but did not get any solution out of it. This errormessage is still harassing me allthough the file is existant and iostat brings out '0'.

I still believe, that some overriding of databounds occurs that somehow affects the reading or opening procedure. But only how to find it ? Does Checkmate check for overriding of databounds - if not, how can I make it do so. I did set the compiler options in Project Explorer to full checking code but did not get any clue.

Any one any idea ?

Norbert

[PaulLaidler]

Norbert

Do you have to use unformatted IO?

If not then you will get a better idea of what is happening if you use formatted IO.
You will be able to read the output file in a text editor etc. For unformatted IO you need a binary editor to read the file.

If you must use unformatted IO then it is essential that your file is created using corresponding write statements.

Something like this....

!write the file...
open(unit=10,file=fname,format="UNFORMATTED",iostat=ierr)
print*,'iostat=',ierr
do j=1,18
write(10)cc
enddo
write(10)iwidth,iheight
close(unit=10)
!read the file...
open(unit=10,file=fname,format="UNFORMATTED",iostat=ierr)
print*,'iostat=',ierr
do j=1,18
read(10)cc
enddo
read(10)iwidth,iheight
close(unit=10)

[ursuselasticus]

Paul,

thanks again for the pain you took to answer to my post. But, sorry, it goes a little bit in the wrong direction.

There is no problem in reading unformatted data. These files here are 24 bit bitmaps containing map images to be displayed (and processed) within my program. I wrote a little utilöity to read any unfromatted file to check for its contents. There is no problem in this direction.

My prog works okay in opening and reading quite a number of these files within this piece of code. The prob arises when the user selected a special option in processing data - a long one involving opening and closing of windows - and then wants to open the next bitmap file. This then will result with the above mentioned error when reading the very first byte. This happens even if I try to reopen a file that was read perfectly before. And after exiting and restarting my prog it does read the file in question again without any problem.

My conclusion is, that during the a.m. data processing some malfunction occurs resulting in corrupting the read or open procedure. But this piece of code is about 1800 lines in size - and I am at a loss on how to hunt down this bug. Checkmate does not give any clue of overriding any data bounds nor does SDBG give any clue until processing the fatal read statement.

I checked my data as far as I could but could not find any 'simple' error - which of course does not mean that there isn't any. What would help me would be some hint as to how best to proceed.

Norbert

[ursuselasticus]

Heureka !!! (Greek: I got it !!) This was one of the worst I ever had.

This was how it worked:

During execution of some part of my prog the setting of the current directory changed (and I forgot about this!)
Now on program execution trying to open the file not existantnot this directory caused a directory entry of the files name of size 0kB.
All the following reads executed during program testing and debugging - after the forgotten change of the current directory was executed that is - did not open the file I was thinking it was but opened the 0kB file again, bringing no error message, as the file - that is the directory entry - exists, but as there were no bytes to read the error occured.

So now there is one question for me: Is it possible to switch off this feature, that files that could not be opened create an entry in the directory ? Of course it has its advantages to be able to find out where your prog is looking for which file by checking the directories in question - but as long as opening a 0kB file does not create any error it might be a highly confusing feature.

Best regards

Norbert

[PaulLaidler]

Norbert

There are two approaches that might be relevant.

1) Use STATUS = "OLD" in the OPEN statement

2) Use FEXIST@ to test if the file exists.

[ursuselasticus]

Paul,

[small]Paul Laidler wrote:[/small]
1) Use STATUS = "OLD" in the OPEN statement

2) Use FEXIST@ to test if the file exists.

That's what I did - but this test got the wrong results as the file existed (after the first try to read it, which created that 0kB directory entry).

Norbert

[PaulLaidler]

Norbert

The only way that we can help you further with this problem is for you to send us your code.
However we would have to charge a significant consultation fee for this service.

Regards

Paul

[ursuselasticus]

Hello Paul,

mabe my English is not good enough to make myself understood.

My prob is solved.

Just wanted to know as an additional question if the progs could be modified not to create files on futile tries of opening files.
That's all. If there is no answer to this last one - it's all okay with me.

But thanks for your tries in supporting me.

Norbert

[PaulLaidler]

Norbert

Yes I do not understand the problem.

If test.dat does not exist then

OPEN(10,FILE="test.dat",STATUS="OLD",IOSTAT=ier)

gives ier = 128.

Similarly if test.dat does not exist then

LOGICAL L,FEXISTS@
L = FEXISTS@("test.dat",ier)

give L = .FALSE.

In both case test.dat is assumed to be in the current working directory.

Regards

Paul

[ursuselasticus]

Well its not a problem any more, just a question on if some settings could be changed. Let me try to explain once again what has been my prob.

My prog (still under development) works as follows:

Step 1: Looking up a specified directory and compile a list of the files available

Step 2: offer this to the user to select one file to process.

Step 3: files are opened and processed at the user's (=myself) will and all works fine until

Step 4: the bug hits home: in some recesses of my prog another directory was attached - and the proper directory was not reattached.

Step 5: trying to open another file from the list - but the computer looking in the wrong directory - creates an errormessage

Step 6: I start debugging, entering errorchecks on the existance of the file

Step 7: Restarting the prog performing the same sequence of processing my data - but now after the wrong directory was attached all my tests lead in the wrong direction because now, on the second execution, my prog finds the file existing on the wrong directory but size 0kB. So all the checks indicate that the file is existing but still my prog cannot read it.

Step 8: Start to believe in ghosts because I was unaware that the file that was tested for existence was not the one I looked at in the original directory.

So now I just have the very plain and simple question, if it could be avoided that my prog creates an entry into the wrong directory when trying to read a non existent file, so the next run would give the message that this file does not exist. Is there any compiler or linker option that can be set ?

Hope I made myself clear.

Norbert

[Martin]

If I understand your question correctly, you are looking for an option to specify status="old"as the default for all OPEN statements (note that it is the OPEN statement that creates the file, not the read statement).

Off the top of my head, I don't think there is such an option in FTN95, so you will have to ensure that you specify it explicitly for every OPEN statement, or manually check that the file exists before attempting to open it.

[ursuselasticus]

Thanks Martin,

so I got it:

If I specify status='old' ind the open statement, the file will not be created in the directory when the prog in error tries to access a file that is not existant on that directory.

Somehow I never thought about this simple option.

Thanks,

Bye

Norbert