Error in openning file

[H.H.]

I have a C++ code which fails when openning a file for reading or for writting:

1:
ifstream fileStream;
fileStream.open(fileName, ios::in);
if (fileStream.fail()){
return 1;
}

2:
ofstream fileStream;
fileStream.open(fileName, ios::out|ios::trunc);
if (fileStream.fail()){
return 1;
}

Actually file exists, user is file's owner and file has permissions 777. I cannot understand why in this case it is impossible to read or write a file. Do you have any ideas?

I have a some suggestions, but I'm not sure about them:
1) File is busy by another process. Is it possible? If yes, is there a command which I can use for monitoring which processes use my file? But it seems there are no another processes interested in this file.
2) There are some system limitations for files (like limitations from file system). Is it possible? If yes, what are these limitations and can I check them by some commands?
3) There are some process limitations for opened files. Is it possible? If yes, how I can check them?
4) Any another ideas?

Thanks

[Steven Schweda]

I'm a lowly C coder, with minimal C++
knowledge, but even a clod like me will try
to learn the cause of a failure from the OS.
Sonething like "errno", as I recall. Perhaps
C++ has something similar which might be
informative. This often works better than
guessing possible reasons for an I/O failure
with no clues.

Perhaps I've missed them but I don't see a
few insignificant details in your problem
report (other than a complete failing test
case), such as:

The file name used by the program (which
could be invalid).

Ownership and permissions of the
directory where this file might be sought
(or created)

The OS and its version, or the compiler
snd its version.

[Dennis Handly]

>1) File is busy by another process. Is it possible?

HP-UX doesn't enforce checking like that.

2>) There are some system limitations for files

Yes, too many inodes open. See nfile(5).

>3) There are some process limitations for opened files.

Yes, too many files open per process.
What does "ulimit -a" show?

>4) Any another ideas?

What Steven said about printing errno.

Also what compiler and OS version are you using?

[H.H.]

> The file name used by the program (which
> could be invalid).

file name is ok. But I will recheck it tomorrow. Actually, problem happened on a customer side

> Ownership and permissions of the
> directory where this file might be sought
> (or created)

ownership of directory is the same of process'es ids (effective and real)

> The OS and its version, or the compiler
> snd its version.

aCC: HP ANSI C++ B3910B A.03.63
HP-UX 11.11 32 bit

Thanks

[H.H.]

>>2>) There are some system limitations for files
>
>Yes, too many inodes open. See nfile(5).

unfortunately, utility nfile doesn't exist on that HP-UX instance.

>>3) There are some process limitations for >opened files.
>
>Yes, too many files open per process.
>What does "ulimit -a" show?

Let me check this output.

[Dennis Handly]

>utility nfile doesn't exist on that HP-UX instance

What utility? nfile(5) says look at the man page in section 5.
You can use sar(1m) for the inod-sz:
$ sar -v 1 5
22:42:20 text-sz ov proc-sz ov inod-sz ov file-sz ov
22:42:21 N/A N/A 179/4200 0 822/156532 0 569/65536 0