fstat, file_info and file_test [message #35090] |
Wed, 14 May 2003 06:50  |
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  |
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  |
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
|
|
|