f



Can't Find Answer Any Where (What would you do/try): fopen ("file on shared drive","w+") doesn't work on 2nd call using Windows LabView DDL

Hello,

I have a shared drive on SGI, Linux, and Windows. The fact that I'm
using a shared drive may be mute information.

The problem is within the same program a second call to fopen does not
create a file if the file has been deleted.

I would like to use fopen for its pointer return value to solve this.

What is the best way to fix this problem?

The reason I want to do this is I do not want to exit completely
from LabView and then re-enter it to create the file!

I talked to my system person and he said something "like" this. That it
is a caching problem. Windows has the file in cache memory. All
references to it affect the cached file. You can do fopens (NULL not
returned, and errno not set), reads, and writes, but they do not affect
the file in question on the shared drive. He went on to say thathave to
use an unbuffered option with "creat" and change all read/writes
appropriately.

Will doing a creat with an unbuffered option (his suggestion) help?

Thank you, 

Christopher Lusardi

0
clusardi2k (508)
8/17/2005 6:58:20 AM
comp.lang.c++ 49423 articles. 7 followers. Post Follow

1 Replies
890 Views

Similar Articles

[PageSpeed] 35

clusardi2k@aol.com wrote:
> I have a shared drive on SGI, Linux, and Windows. The fact that I'm
> using a shared drive may be mute information.
> 
> The problem is within the same program a second call to fopen does not
> create a file if the file has been deleted.
> 
> I would like to use fopen for its pointer return value to solve this.
> 
> What is the best way to fix this problem?
> 
> The reason I want to do this is I do not want to exit completely
> from LabView and then re-enter it to create the file!
> 
> I talked to my system person and he said something "like" this. That it
> is a caching problem. Windows has the file in cache memory. All
> references to it affect the cached file. You can do fopens (NULL not
> returned, and errno not set), reads, and writes, but they do not affect
> the file in question on the shared drive. He went on to say thathave to
> use an unbuffered option with "creat" and change all read/writes
> appropriately.
> 
> Will doing a creat with an unbuffered option (his suggestion) help?

This is covered in the FAQ 5.8.  Don't forget to read the rest of the
section 5.

V
0
v.Abazarov (13256)
8/17/2005 1:31:06 PM
Reply: