forums.silverfrost.com

[sparge]

Another matter arising from my efforts to get one of my applications running under WinXP. The following program works under WinXP when logged on with admin rights, but fails when logged on as a user:

program xp_file
integer opstat
open (unit = 6, file = 'log.txt', position = 'append', action = 'write', iostat = opstat)
if (opstat .eq. 0) write (6, 10)
close (unit = 6)
stop
10 format (1x,'Gotcha!')
end program xp_file

It fails with runtime error 139 on the conditional write statement, reporting "You may not write to a file that is READONLY" - despite the fact that iostat has returned a value of 0 indicating that the write statement is legitimate.

My copy of Metcalf & Reid, in respect of OPEN (..., action =...), says the following:

"if WRITE is specified, the READ statement must not be used (and BACKSPACE and POSITION='APPEND' may fail on some systems"

It seems a member of the group Usres on WinXP is one of those systems. I'd be interested to know the reason why this combination of specifiers is potentially problematic, but really I want to know why it doesn't fail gracefully? (i.e. with a non-zero value of iostat).

Andy

[DrTip]

Hi Andy

I have half a possible answer for you. At our company we have had a lot of problems with user rights on XP. Basically this boils if you are writing to anywhere other than the current users "My Documents" folder your not allowed to, unless you have admistrator rights.

For developers this is obviously absurd and we have basically had to give everyone admin rights on there "own" machines. I can't speak for the compiler but I guess this sort of Microsoft control freakery is pretty tough to pick up. We've had pretty much the same problem on even Microsoft products like Word and Excel, where user specified preferences are stored in a sub folder of C:program files.. etc.

There probably are ways of configuring the problem I am talking about in a less extreme manner but the boss wouldn't have the patience for it, more a don't break it attitude.

Carl

[sparge]

Hi Carl,

Thanks for reading and replying.

Curiouser and curiouser ... on my Win XP Home machine (at home), the proglet I posted runs just fine. And yet the folder I ran it from on that machine has the same user rights as the folder I ran it from on the Win XP Pro machine - where it doesn't work.

I don't really see why Microsoft control freakery should be harder to pick up than any other sort of operating system control freakery. The operating system is there to administer what a program can and can't do, and where. The OPEN statement gives a program the facility to request permission for write access to a specific folder, and the operating system the facility to grant permission or deny it, and if necessary to say why it has been denied. And those facilities were around long before Windows XP came along.

My gripe is not with the inability to write where I don't have write access under Windows XP. My gripe is with the inability to get the OPEN statement to behave consistently as it ought under Windows XP.

As I said, Metcalf and Reid note that "if WRITE is specified, the READ statement must not be used (and BACKSPACE and POSITION='APPEND' may fail on some systems").

What I want to know is:

1) why BACKSPACE and POSITION='APPEND' may fail on some systems
2) whether the nature of this failure is graceful (a non-zero error code returned by OPEN) or disgraceful (apparent success followed by runtime error when trying to WRITE)

Andy

[brucebowler]

I can only guess that "why BACKSPACE and POSITION='APPEND' may fail on some systems" is because some systems may implement those actions "behind the scenes" as READs which M&R say must not be used.

I would further guess that they might fail disgracefully depending on whether the compiler writer took note of how they implement BS and P=A in the code they use to OPEN a file (if they said to themselves "we READ to BACKSPACE, let's fail now", it might fail at the open with an error code, elsewise it might fail poorly with a RTE at the write (or BS)

Bruce