comp.lang.idl-pvwave archive
Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado

Home » Public Forums » archive » fstat, file_info and file_test
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Switch to threaded view of this topic Create a new topic Submit Reply
fstat, file_info and file_test [message #35090] Wed, 14 May 2003 06:50 Go to next message
btt is currently offline  btt
Messages: 345
Registered: December 2000
Senior Member
Hello,

This appears to be the week for file questions.

I see that in the now distant past, my question has been asked here
before, but the answers were pre-IDL 5.4 when FILE_xxxxx routines appeared.

I would like to have a test that reports if the file is open - by simply
providing the filename. FSTAT almost does it, but I have to associate
the file with a LUN first. FILE_INFO and FILE_TEST each take the
filename as an argument (instead of the lun that FSTAT requires), but
neither test for 'openess'.

What I would like to have is a function similar to:

result = FILE_ISOPEN(filename)

that returns a 1 (for open) or a 0 (for closed). Or, perhaps better in
the long run, I'd like to see an /ISOPEN keyword added to FILE_TEST.


Any suggestions?

Thanks,
Ben
Re: fstat, file_info and file_test [message #35214 is a reply to message #35090] Thu, 15 May 2003 08:44 Go to previous message
btt is currently offline  btt
Messages: 345
Registered: December 2000
Senior Member
Paul van Delst wrote:

>
> Umm, pardon my denseness, but how is this different from file access/status issues for
> other languages? My experience is limited to Fortran (which has a number of file inquiry
> capabilities) but I would think at some point, regardless of language, the programmer has
> to take responsibility for avoiding the problems mentioned. At the very least, code
> defensively to trap or minimise subsequent damage.
>
> paulv
>

No, no, your not dense at all! You've hit it right on the head! I think
that is what Nigel might have been saying under his breath - but I
shouldn't put words there. I thought I was being careful by checking
that the file was open before writing to it (or closing it when I'm
done.) I'm still banging my head against the images from a submarine
camera. It's one of the GUI things where the images are being collected
from a rolling tape at n second intervals. The user might want to pause
the collecting process to wait for a jelly fish to float past the
camera, swap tapes or who knows what? Your right, I'll just have to be
tight about programmatic control.

Cheers,
Ben
Re: fstat, file_info and file_test [message #35215 is a reply to message #35090] Thu, 15 May 2003 08:27 Go to previous message
Paul Van Delst[1] is currently offline  Paul Van Delst[1]
Messages: 1157
Registered: April 2002
Senior Member
Ben Tupper wrote:
>
> Nigel Wade wrote:
>>
>> How do you deal with the issue of the file being renamed or deleted after
>> you've opened it? What do you do if the file you opened is renamed and new
>> file created with the same name - should the test indicate it's open or
>> not?
>>
>> In general, not even the OS can tell you reliably what you want for these
>> reasons.
>>
>
> Good questions! Another question to add to your list, what happens if
> more than one valid pointers exist to the single file? Witness below,
> that u1 and u2 are each valid LUNs to the same file. Gaak! I can see
> why the underlying OS can't be counted upon for 'truth' - too many cooks!
>
> IDL> get_LUN, u1
> IDL> get_LUN, u2
> IDL> openW, u1, file
> IDL> for i = 0, 2 do print, s[i]
> Unit Attributes Name
> 100 Read, Write, New, Reserved /Users/ben/data.dat
> 101 Closed, Reserved
> IDL> openU, u2, file
> IDL> help, /file, output = s
> IDL> for i = 0, n_elements(s)-1 do print, s[i]
> Unit Attributes Name
> 100 Read, Write, New, Reserved /Users/ben/data.dat
> 101 Read, Write, Reserved /Users/ben/data.dat


Umm, pardon my denseness, but how is this different from file access/status issues for
other languages? My experience is limited to Fortran (which has a number of file inquiry
capabilities) but I would think at some point, regardless of language, the programmer has
to take responsibility for avoiding the problems mentioned. At the very least, code
defensively to trap or minimise subsequent damage.

paulv

--
Paul van Delst
CIMSS @ NOAA/NCEP/EMC
Ph: (301)763-8000 x7748
Fax:(301)763-8545
  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: FFT confusion
Next Topic: TVLCT as mouse is moved?

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Wed Oct 08 15:49:21 PDT 2025

Total time taken to generate the page: 0.00532 seconds