Text File Duplication

[Robert_Middleton]

Hello,

I am trying to write some code to:

1) open a text file,
2) save the contents to memory,
3) and overwrite the contents back to the same file.

I am able to perform all 3 steps except for one thing, when I close the file it adds one extra blank line to the end of the file. Not really a huge problem if you only open the file one time, but if you open the same file 1000 times it's going to become a problem.

This is how I am opening the file:

OPEN (file=c_file_name_and_path%string_data, status='unknown', &
access='sequential', form='formatted', iostat=i_status, &
NEWUNIT=file_unit_number)

This is how I am writing out the data to the file if the line is blank: ADVANCE='NO'
WRITE (UNIT=filedata%file_unit_number, FMT='(A)', ADVANCE=adv_switch, ERR=9999)
or if the line has data
WRITE (UNIT=filedata%file_unit_number, FMT='(A)', ADVANCE=adv_switch, ERR=9999) &
file_line%string_data(index:index)

At the very end:
CLOSE (UNIT=filedata%file_unit_number)

Please let me know if you need anything else.

Thanks,
Bob

[Arjen_Markus]

Can you show us a (small) program that exhibits this behaviour?
I first thought it had to do with line endings (UNIX-style line endings or
the last line of the file not being finished with a line ending, but that
is not going todo it.
Your description of the process may be accurate, but my guess is
that there is some detail you have not got quite right.

Regards,

Arjen

[Robert_Middleton]

Arjen,

Ipackagedmy testproject, let me know if you can't open a zip file. I used 7zip to create this file.I am building this project with MSVS 2008 and Intel Visual Fortran Composer XE 2011.

The problem area is in the Function SAVE_FILE_DATA, if you add a couple of break points at line 289 and 327 you will be able to see what is happening in the file. I use notepad++(free) to view the file while the program is running. File is perfect until I call the CLOSE function and it adds an extra line.

Please note that the test file has two blank lines at the end, there will be three after running the test.

Thanks for the help and good luck,
Bob

[Arjen_Markus]

Hi Bob,

I have the zip-file and I will try and have a look tonight. Can't promise anything, but it is one of
those things that keep nagging :).

Regards,

Arjen

[Robert_Middleton]

Hi Arjen,

I'm sorry, I was beinglazy sending you the entire project, plus you will have all sorts of issues with file paths so I have written a very simple program that demonstrates the issue.

Basically, I open a file and write a couple of lines to it. When I call theCLOSE function it will add one more line to the file that I do not want.

Thanks for looking,
Bob

[Arjen_Markus]

I had a quick look and your use of allocatable-length strings may inhibit my running the program,
but I suggest you have a thorough look at the reading routine. That might be one possibility for the
cause of the problem.

Regards,

Arjen

[Arjen_Markus]

Thanks,

I will have a look at that much simpler code :)

Regards,

Arjen

[Arjen_Markus]

Are you sure?

I tried with Intel Fortran 12 and gfortran on Linux: nothingextra
I also tried with Intel Fortran 11 on Windows: nothing extra either (not counting the CRs)

I do not have ready access to Intel Fortran 12, so can't test that.
Odd, very odd.

Regards,

Arjen

[Robert_Middleton]

Arjen,

A little more information about my system, I am running Windows 764bit.

Best regards,
Bob

[Arjen_Markus]

Hi Bob,

that should not really matter. At least I hope so. I have no Windows 7 machine at hand
right now, so I hope someone else can step in. In the meantime it does remain bizarre.

Regards,

Arjen

[Robert_Middleton]

Arjen,

On my Windows 7 machine, I have a XP virtual machine installed. In XP I have our old Lahey compiler installed, when I compile and run the code, no extra line ;-). I think Intel has a bug and I am going to report it. Thanks for helping by running the same code on some other systems and thanks again for taking the time to look at my problem, I appreciate it.

Best regards,

Bob

[Arjen_Markus]

You're welcome :)

Regards,

Arjen

[Steven_L_Intel1]

I don't see a bug. If you open the file in a text editor, yes, the editor will present it as three lines but there are really only two. If you look at the file with a binary editor, you will see the second line properly ending with a CR-LF delimiter and there is nothing after that. Notepad, etc. will position the cursor on the yet-to-be-created third line.

[Robert_Middleton]

Hi Steve,

I agree, the simple code sampleI submitted is not doing what the larger program does. Please see the attached file "input.dat." If you look at it with yourbinary editor you will see a sequence of 4 "0D 0A" entries at the tail end of the file. This is from running my larger program 4 times.The entire projectfor this program was submitted in a zip file in an early post. I am unable to produce a simpler example thatdemonstrates the issue.

Thanks,
Bob