fopen ("file on shared drive","w+") doesn't work on 2nd call using Windows LabView DDL

[clusardi2k]

Hello,

I have a shared drive on SGI, Linux, and Windows.

A second call to fopen doesn't create the file if it 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 that

I have to use "creat" and change all read/writes appropriately.

Thank you,
Christopher Lusardi

[clusardi2k]

I posted DDL on the subject line when I should have typed DLL.

Sorry,
Christopher Lusardi

[Kenneth Brody]

cl********@aol. com wrote:

Hello,

I have a shared drive on SGI, Linux, and Windows.

A second call to fopen doesn't create the file if it has been
deleted.
I believe this is really platform-specific given your description.
I don't know if it's a Linux issue of a Windows issue.

Is the first FILE* still open? Linux lets you delete files that
are still open, Windows does not. What happens when Windows has
a Linux file open, one can only guess. I doubt the standard says
anything about this, beyond "undefined" or "implementa tion specific".

[...] 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 that

I have to use "creat" and change all read/writes appropriately.

If fopen() returns something other than NULL, then errno won't be
set because it didn't fail.

If the first FILE* is still open, I would venture to guess that your
"system person" may be on to something. The file is still open, so
it may be that Windows doesn't bother asking the remote system to
re-open the file, instead opting to duplicate the existing handle.

If the first FILE* was closed before the file was removed, then it
may be a bug in Windows, allowing you to open a file which is no
longer there. (Though one could claim my first scenario is a bug
as well.)

You'll probably have to ask a Windows newsgroup for further details.

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer .h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:Th***** ********@gmail. com>

[SM Ryan]

# 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 that

I suppose Windows inability to handle something as simple as
fopen/fclose/fopen shouldn't be surprising.

# I have to use "creat" and change all read/writes appropriately.

You might fdopen available that can turn a system specific
file designator into a FILE* pointer.

On Unix it could be something like
int fd = open(path,O_CRE AT|O_WRONLY,075 5);
FILE *fp = fdopen(fd,"w");

--
SM Ryan http://www.rawbw.com/~wyrmwif/
Raining down sulphur is like an endurance trial, man. Genocide is the
most exhausting activity one can engage in. Next to soccer.

[clusardi2k]

Kenneth Brody wrote:

Is the first FILE* still open?

The file has been closed before the second fopen.

Will doing a creat with an unbuffered option help?

Christopher Lusardi

[clusardi2k]

Solved it by myself, see below.

SUMMARY
C and C++ file operations, by default, perform their own data caching.
This caching is in addition to the disk caching done by the operating
system. Under certain conditions it may be necessary to ensure your
data is fully flushed to the disk. This article explains how to ensure
that your data is properly flushed to the disk.

MORE INFORMATION
To flush the C runtime buffers, you need a call to fflush for files
that are opened with fopen or a call to the flush function for C++
ofstream objects. Flushing the operating system's disk cache is a
little more difficult; it depends on the operating system in use.

16-bit Operating Systems - MS-DOS or Windows 3.1
In MS-DOS or Windows 3.1 running Smartdrv.exe version 4.0 or later, you
have two choices. You can use the _commit C runtime function or link
with Commode.obj and use the fflush C runtime function.

32-bit Windows Operating Systems
In 32-bit versions of Windows, the operating system has built-in disk
caching. The only way to force a file to be flushed to disk is by
linking to Commode.obj.

Commode.obj is designed to affect the way the C Runtime handles files.
When you link to this .obj file, a call to the C runtime function
fflush also forces the operating system to flush its cache to disk,
making the call to _commit unnecessary.

Christopher Lusardi

[Kenneth Brody]

cl********@aol. com wrote:

Kenneth Brody wrote:

Is the first FILE* still open?
The file has been closed before the second fopen.

Was it closed before the file was deleted?

If so, I'd say it's a bug in Windows. (There's no reason for it to
be caching anything about a remote file that's closed.)

If not, I'd say it's simply the way Windows handles deleting of files
that are still open. (Remember, Windows won't permit this if the file
were on a Windows box, so it may not be able to handle it when the file
is on a remote *nix box.)
Will doing a creat with an unbuffered option help?

Dunno. Now you're getting into things you would need to ask on a Windows
newsgroup.

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer .h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:Th***** ********@gmail. com>

[Keith Thompson]

cl********@aol. com writes:
[...]

To flush the C runtime buffers, you need a call to fflush for files
that are opened with fopen or a call to the flush function for C++
ofstream objects. Flushing the operating system's disk cache is a
little more difficult; it depends on the operating system in use.

Just keep in mind that fflush() is undefined for input streams.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.