From: John W. Krahn on
Marc Girod wrote:
> On Aug 7, 7:40 am, "John W. Krahn"<jwkr...(a)example.com> wrote:
>
>> Your code does not check the return value from sysopen() so the error
>> message you are receiving is not related to sysopen().
>
> Doesn't it?
> The block is an if block.
> If the condition (the return from sysopen) is false,

Or true.

> the function returns 0 unconditionally.

Correct.

> Besides, the error I get from $!, at the time of reporting in the
> calling function is, as I wrote it, 'File exists'.

By that time $! could have been changed by some other system function.

You need to capture or print the value of $! immediately after the
system function that sets it, for example:

sysopen my $FILE, $file, O_EXCL | O_CREAT | O_WRONLY, $mode or do {
warn "Cannot open '$file' $!";
return 0;
};


*Note that "$mode" is really the permissions field, and the MODE field
is actually "O_EXCL | O_CREAT | O_WRONLY".




John
--
Any intelligent fool can make things bigger and
more complex... It takes a touch of genius -
and a lot of courage to move in the opposite
direction. -- Albert Einstein
From: Marc Girod on
On Aug 7, 1:10 pm, "Peter J. Holzer" <hjp-usen...(a)hjp.at> wrote:

> If the network filesystem doesn't support O_EXCL, then the open will
> succeed even though it shouldn't (or it will fail every time with
> EINVAL), it won't fail when the file doesn't exist.

Thanks.

> No. sysopen is the closest you can get to the OS.

OK.

> Yes. Most likely causes are IMHO:
>
>  * The file really exists at the time. You have to find out why
>    (maybe your script is supposed to remove the file before it
>    terminates and it either doesn't do it or a previous invocation
>    hasn't finished yet). If you know why the solution is probably
>    obvious.
>  * The file did exist and has already been removed at the time the
>    script runs, but the information about the file's existence is still
>    cached by the OS. In this case you should check the configuration of
>    the file system (on both the client and the server).

Well, I have to figure out how either could be possible.
I cannot see what in the code could remove anything...
Those files are left to be accessible from a web page.
There is a loop which increments a digit in the file name and tries
100 times.
I don't think this is very smart, but I cannot see how the 100
different files could exist.

The error returned in the end is of course only the one for the last
try.
So that I don't *know* why the 99 first attempts failed.
But in the general case, I cannot find the 100th file either.

I may leave this for a while: I have more urgent, and the symptom has
stopped for now.
But I don't doubt it will come back.

Thanks.
Marc
From: Marc Girod on
On Aug 7, 6:40 pm, "John W. Krahn" <jwkr...(a)example.com> wrote:

> Or true.

Indeed.

> By that time $! could have been changed by some other system function.

Yes.

> You need to capture or print the value of $! immediately after the
> system function that sets it, for example:

Yes...

> *Note that "$mode" is really the permissions field, and the MODE field
> is actually "O_EXCL | O_CREAT | O_WRONLY".

I saw that. It was set to 0444.
Thanks. I'll save a pointer to this and come back later.

Marc
From: Ben Morrow on

Quoth jwkrahn(a)shaw.ca:
>
> sysopen my $FILE, $file, O_EXCL | O_CREAT | O_WRONLY, $mode or do {
> warn "Cannot open '$file' $!";
> return 0;
> };
>
>
> *Note that "$mode" is really the permissions field, and the MODE field
> is actually "O_EXCL | O_CREAT | O_WRONLY".

While it is correct that the fourth argument is the permissions, and
that perldoc -f sysopen calls the third and fourth arguments MODE and
PERMS respectively, open(2) calls the second argument (corresponding to
Perl's third) 'int flags' and the third 'mode_t mode'. So it's not an
unreasonable name for the variable.

Ben

From: Peter J. Holzer on
On 2010-08-09 11:50, Marc Girod <marc.girod(a)gmail.com> wrote:

[sysopen(... O_EXCL ...) fails with EEXIST although the file shouldn't
exist]

> Well, I have to figure out how either could be possible.
> I cannot see what in the code could remove anything...
> Those files are left to be accessible from a web page.
> There is a loop which increments a digit in the file name and tries
> 100 times.
> I don't think this is very smart, but I cannot see how the 100
> different files could exist.
>
> The error returned in the end is of course only the one for the last
> try.
> So that I don't *know* why the 99 first attempts failed.
> But in the general case, I cannot find the 100th file either.

I would log each failure with all the details I can think of. In this
case:

* exact name of the file to be created
* $! immediately after the failure
* cwd at the time of the failure
* try to lstat the file just after the failure (but after logging $!,
or you will change it!) and log all relevant information if the
file exists - this will help you to determine where the spurious
files come from


> I may leave this for a while: I have more urgent, and the symptom has
> stopped for now.
> But I don't doubt it will come back.

If you add the diagnostics now you will have the information next time
the problem occurs.

hp