| fstat update [message #14089] |
Mon, 25 January 1999 00:00  |
ashmall
Messages: 14
Registered: October 1998
|
Junior Member |
|
|
Dear All,
Has anyone had a problem like this?
We have a widget prog that periodically checks a file for new data, it does
this by monitoring the file size as returned by fstat. This usually works fine
but we have found on some (network) drives fstat always returns the same
value, namely the file size it first saw, even though the file is growing.
The only fix we've found is to constantly close and re-open the file which is
a rather inelegant, if not inefficient, solution.
It doesn't appear to be a buffering problem since we can see the file size
changing (across the network) using the command line or a file manager.
Any suggestions?
(We're using IDL 5.1.1 under NT4)
Many thanks,
Justin
|
|
|
|
| Re: fstat update [message #14129 is a reply to message #14089] |
Fri, 29 January 1999 00:00  |
ashmall
Messages: 14
Registered: October 1998
|
Junior Member |
|
|
Thanks for the response; since we can't have the program creating the data on
the same machine as the IDL machine I think we might try having the "data
program" write the data file onto the IDL machine's hard drive, via the
network.
I think, however, that the problem isn't soley one of NFS (or equiv) update
frequency since fstat reported the same file size every fews second for the
whole 8 hour run!
Thanks again,
Justin
In article <88iuduugyk.fsf@catspaw.jpl.nasa.gov>,
Vapuser<vapuser@catspaw.jpl.nasa.gov> wrote:
> ashmall@my-dejanews.com (Justin Ashmall) writes:
>
>> Dear All,
>> Has anyone had a problem like this?
>
>> We have a widget prog that periodically checks a file for new data,
>> it does this by monitoring the file size as returned by fstat. This
>> usually works fine but we have found on some (network) drives fstat
>> always returns the same value, namely the file size it first saw,
>> even though the file is growing. The only fix we've found is to
>> constantly close and re-open the file which is a rather inelegant,
>> if not inefficient, solution. It doesn't appear to be a buffering
>> problem since we can see the file size changing (across the network)
>> using the command line or a file manager.
>
>> Any suggestions?
>> (We're using IDL 5.1.1 under NT4)
>>
>> Many thanks,
>>
>> Justin
>
> I've seen this problem in a UNIX environment when running an IDL
> routine on one machine that was querying the size of a file which
> resided on a disk that was NFS mounted from another machine. I am
> unfamiliar with NT, so I don't know if 'network disk' is a fair
> analog of NFS. In this case it was a feature of the operating
> system/NFS, the file size didn't change as frequently on the NFS
> client, therefore fstat reported EOF correctly as far as it could
> see. The work around was to run the program on the machine which
> hosted (i.e. for which the disk was local) the disk containing the
> file in question.
>
> Hope this helps in some small way.
>
> whd
>
|
|
|
|
| Re: fstat update [message #14156 is a reply to message #14089] |
Tue, 26 January 1999 00:00 |
Vapuser
Messages: 63
Registered: November 1998
|
Member |
|
|
ashmall@my-dejanews.com (Justin Ashmall) writes:
> Dear All,
> Has anyone had a problem like this?
> We have a widget prog that periodically checks a file for new data,
> it does this by monitoring the file size as returned by fstat. This
> usually works fine but we have found on some (network) drives fstat
> always returns the same value, namely the file size it first saw,
> even though the file is growing. The only fix we've found is to
> constantly close and re-open the file which is a rather inelegant,
> if not inefficient, solution. It doesn't appear to be a buffering
> problem since we can see the file size changing (across the network)
> using the command line or a file manager.
> Any suggestions?
> (We're using IDL 5.1.1 under NT4)
>
> Many thanks,
>
> Justin
I've seen this problem in a UNIX environment when running an IDL
routine on one machine that was querying the size of a file which
resided on a disk that was NFS mounted from another machine. I am
unfamiliar with NT, so I don't know if 'network disk' is a fair
analog of NFS. In this case it was a feature of the operating
system/NFS, the file size didn't change as frequently on the NFS
client, therefore fstat reported EOF correctly as far as it could
see. The work around was to run the program on the machine which
hosted (i.e. for which the disk was local) the disk containing the
file in question.
Hope this helps in some small way.
whd
|
|
|
|
| Re: fstat update [message #14220 is a reply to message #14089] |
Fri, 29 January 1999 00:00 |
Martin Schultz
Messages: 515
Registered: August 1997
|
Senior Member |
|
|
Justin Ashmall wrote:
>
> Thanks for the response; since we can't have the program creating the data on
> the same machine as the IDL machine I think we might try having the "data
> program" write the data file onto the IDL machine's hard drive, via the
> network.
> I think, however, that the problem isn't soley one of NFS (or equiv) update
> frequency since fstat reported the same file size every fews second for the
> whole 8 hour run!
>
> Thanks again,
>
> Justin
We actually experienced something similar when we started to run IDL
on an SGI Origin 2000 machine. But in our case, it was definitively NFS,
because you could also copy files with some other machine on their hard
drives, and the SGI wouldn't catch up (which caused me run over quota a
couplke of times although I had deleted files). Our sys admin somehow
managed to fix this.
Short message: Try to find a test that is independent of IDL, then you
know at least who is to blame (and who should fix this).
Martin.
--
------------------------------------------------------------ -------
Dr. Martin Schultz
Department for Engineering&Applied Sciences, Harvard University
109 Pierce Hall, 29 Oxford St., Cambridge, MA-02138, USA
phone: (617)-496-8318
fax : (617)-495-4551
e-mail: mgs@io.harvard.edu
Internet-homepage: http://www-as.harvard.edu/people/staff/mgs/
------------------------------------------------------------ -------
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
