Best way to test for existence of a file

[Bigdakine]

Hello,

I was wondering what is the most bullet proof way to test for a file. I am
concerned, that a program could hang when trying to test for the existence of a
file across an NFS mount that is humped.

Not that that happens alot, but if it does happen I don't want a program to
hang because NFS is not giving it a response.

Yours,

Stuart


Dr. Stuart A. Weinstein
Ewa Beach Institute of Tectonics
"To err is human, but to really foul things up
requires a creationist"

[Marc Rochkind]

On 09 Jul 2003 01:51:26 GMT, Bigdakine <bigdakine@aol.comGetaGrip> wrote:

> Hello,
>
> I was wondering what is the most bullet proof way to test for a file. I
> am
> concerned, that a program could hang when trying to test for the
> existence of a
> file across an NFS mount that is humped.
>
> Not that that happens alot, but if it does happen I don't want a program
> to
> hang because NFS is not giving it a response.
>
> Yours,
>
> Stuart
>
>
> Dr. Stuart A. Weinstein
> Ewa Beach Institute of Tectonics
> "To err is human, but to really foul things up requires a creationist"
>

Can't answer the actual question, becuase I'm not an NFS expert, but the
general answer is the access system call. stat is also fine, with a bit
more work.

To prevent hanging, set an alarm before you issue the call. If it goes off
(you'll need a signal handler), you know that you have some cleanup work to
do.

However, access and stat are not blocking system calls, so they aren't
required to be interrupted by a signal (EINTR), and probably won't be. You
need to longjmp out of the signal handler to get around the stuck call.

This is all theoretical. It is entirely possible that the level of
stuckness is beyond what my siimple suggestion is capable of dealing with.

--Marc

[Bigdakine]

>Subject: Re: Best way to test for existence of a file

>From: Marc Rochkind [email]rochkind@basepath.com[/email]
>Date: 7/8/03 4:36 PM Hawaiian Standard Time
>Message-id: <oprr0uu40rojfyi9@den.news.speakeasy.net>
>
>On 09 Jul 2003 01:51:26 GMT, Bigdakine <bigdakine@aol.comGetaGrip> wrote:
>

>> Hello,
>>
>> I was wondering what is the most bullet proof way to test for a file. I
>> am
>> concerned, that a program could hang when trying to test for the
>> existence of a
>> file across an NFS mount that is humped.
>>
>> Not that that happens alot, but if it does happen I don't want a program
>> to
>> hang because NFS is not giving it a response.
>>
>> Yours,
>>
>> Stuart
>>
>>
>> Dr. Stuart A. Weinstein
>> Ewa Beach Institute of Tectonics
>> "To err is human, but to really foul things up requires a creationist"
>>

>
>
>Can't answer the actual question, becuase I'm not an NFS expert, but the
>general answer is the access system call. stat is also fine, with a bit
>more work.
>
>To prevent hanging, set an alarm before you issue the call. If it goes off
>(you'll need a signal handler), you know that you have some cleanup work to
>do.
>
>However, access and stat are not blocking system calls, so they aren't
>required to be interrupted by a signal (EINTR), and probably won't be. You
>need to longjmp out of the signal handler to get around the stuck call.
>
>This is all theoretical. It is entirely possible that the level of
>stuckness is beyond what my siimple suggestion is capable of dealing with.
>

THanks for your response, unless something else is suggested, I'll give that a
shot.

Yours,

Stuart
Dr. Stuart A. Weinstein
Ewa Beach Institute of Tectonics
"To err is human, but to really foul things up
requires a creationist"

[David Schwartz]

"Marc Rochkind" <rochkind@basepath.com> wrote in message
news:oprr0uu40rojfyi9@den.news.speakeasy.net...

> Can't answer the actual question, becuase I'm not an NFS expert, but the
> general answer is the access system call. stat is also fine, with a bit
> more work.

> To prevent hanging, set an alarm before you issue the call. If it goes off
> (you'll need a signal handler), you know that you have some cleanup work

to

> do.

> However, access and stat are not blocking system calls, so they aren't
> required to be interrupted by a signal (EINTR), and probably won't be. You
> need to longjmp out of the signal handler to get around the stuck call.

> This is all theoretical. It is entirely possible that the level of
> stuckness is beyond what my siimple suggestion is capable of dealing with.

In all likelihood, this won't work. The problem is that NFS generally
tries to emulate other file systems and other file systems don't allow you
to break out of blocking on disk I/O woth a signal. Even if you could do
non-blocking reads/writes, that wouldn't help you as what you're trying to
do is a non-blocking open, stat, or access.

Most OSes have an 'intr' mount option that makes NFS calls able to be
interrupted by a signal. I don't know if it works for operations other than
reads and writes, but I think that was its intent. The Linux NFS FAQ makes
it clear that this option won't always work (because the task might be
blocked on a kernel sempahore and a signal can't interrupt such a low-level
wait).

The only approach that's sure to work is to fork off a child process.

DS

[Ed L Cashin]

"David Schwartz" <davids@webmaster.com> writes:

> "Bigdakine" <bigdakine@aol.comGetaGrip> wrote in message
> news:20030710130124.14767.00000093@mb-m07.aol.com...
>

>> > The only approach that's sure to work is to fork off a child process.

>

>> You mean run fstat in the child process?

>
> Yes.

While it's sure to work, it's still not "bullet-proof", which was the
original criterion as stated by the OP.

Maybe some heavy metal plates on the outside of the case and a cooling
and ventilation system in conjunction with the techniques already
mentioned. ;)

--
--Ed L Cashin PGP public key: [url]http://noserose.net/e/pgp/[/url]