[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: fstat update
- Subject: Re: fstat update
- From: ashmall(at)my-dejanews.com (Justin Ashmall)
- Date: Fri, 29 Jan 1999 10:30:14 GMT
- Newsgroups: comp.lang.idl-pvwave
- Organization: Imperial College
- References: <firstname.lastname@example.org> <email@example.com>
- Xref: news.doit.wisc.edu comp.lang.idl-pvwave:13486
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
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!
In article <firstname.lastname@example.org>,
>email@example.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,
> 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.