By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
434,930 Members | 1,269 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 434,930 IT Pros & Developers. It's quick & easy.

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

P: n/a
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

Aug 17 '05 #1
Share this Question
Share on Google+
1 Reply


P: n/a
cl********@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
Aug 17 '05 #2

This discussion thread is closed

Replies have been disabled for this discussion.