f



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

Hello,

   My second call to fopen doesn't create the file if it has been
deleted. I want to also use fopen for its pointer return value.

   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!

Thank you,
Christopher Lusardi

0
clusardi2k (508)
8/16/2005 4:57:19 PM
comp.unix.programmer 10848 articles. 0 followers. kokososo56 (350) is leader. Post Follow

11 Replies
1076 Views

Similar Articles

[PageSpeed] 46

I forgot to mention the shared drive is also on SGI and Linux.

Thanks,
Christopher Lusardi

0
clusardi2k
8/16/2005 5:00:02 PM
Also, someone was telling me something this may be a caching problem.
What is that?

Christopher Lusardi

0
clusardi2k
8/16/2005 5:02:02 PM
clusardi2k@aol.com wrote:
> Hello,
> 
>    My second call to fopen doesn't create the file if it has been
> deleted. I want to also use fopen for its pointer return value.
> 
>    What is the best way to fix this problem?

What is in errno (presuming that fopen has returned NULL)?

Robert
0
Robert
8/16/2005 5:22:46 PM
Robert Harris wrote:
> clusardi2k@aol.com wrote:
> >    My second call to fopen doesn't create the file if it has been
> > deleted. I want to also use fopen for its pointer return value.
>
> What is in errno (presuming that fopen has returned NULL)?

fopen does not return NULL.

Christopher Lusardi

0
clusardi2k
8/16/2005 5:32:09 PM
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.

Christopher Lusardi

0
clusardi2k
8/16/2005 6:08:09 PM
On 16 Aug 2005 10:32:09 -0700, clusardi2k@aol.com wrote:

>
>Robert Harris wrote:
>> clusardi2k@aol.com wrote:
>> >    My second call to fopen doesn't create the file if it has been
>> > deleted. I want to also use fopen for its pointer return value.
>>
>> What is in errno (presuming that fopen has returned NULL)?
>
>fopen does not return NULL.
>
>Christopher Lusardi

Then the fopen has succeeded, and the file exists, as far as your
program is concerned. Whether is has physically been created at that
time is up to the operating system and not topical for comp.lang.c. I
would presume, however, that the file would physically exist once your
program exits, unless you delete it again in the meantime. In the
interim, why would you care? Is there another piece to this problem
that you aren't telling us?
-- 
Al Balmer
Balmer Consulting
removebalmerconsultingthis@att.net
0
Alan
8/16/2005 7:07:30 PM
In article <t3e4g11u2nhv1d29iou6p8amlkm52ialpj@4ax.com>,
 Alan Balmer <albalmer@att.net> wrote:

> On 16 Aug 2005 10:32:09 -0700, clusardi2k@aol.com wrote:
> 
> >
> >Robert Harris wrote:
> >> clusardi2k@aol.com wrote:
> >> >    My second call to fopen doesn't create the file if it has been
> >> > deleted. I want to also use fopen for its pointer return value.
> >>
> >> What is in errno (presuming that fopen has returned NULL)?
> >
> >fopen does not return NULL.
> >
> >Christopher Lusardi
> 
> Then the fopen has succeeded, and the file exists, as far as your
> program is concerned. Whether is has physically been created at that
> time is up to the operating system and not topical for comp.lang.c.

This isn't comp.lang.c, it's comp.unix.programmer.

But since he's using Windows, not Unix, he's off-topic here as well.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
0
Barry
8/17/2005 4:37:49 AM
Alan Balmer wrote:
> I
> would presume, however, that the file would physically exist once your
> program exits, unless you delete it again in the meantime. In the
> interim, why would you care? Is there another piece to this problem
> that you aren't telling us?

Well, the file can be deleted under two circumstances:

  1) Some one goes to their command line and types : rm file, or
  2) Another program hangs, is re-started, and MUST issue : rm file

My team lead just wants to cover all the bases and have it work under
all possible circumstances! I have been told to fix this immediately,
or I have to discard large sections of the code and start over with
another algorithm which I tkink is very bad.

Wow on me, what do you think?

Christopher Lusardi

0
clusardi2k
8/17/2005 2:06:33 PM
On Wed, 17 Aug 2005 00:37:49 -0400, Barry Margolin
<barmar@alum.mit.edu> wrote:

>In article <t3e4g11u2nhv1d29iou6p8amlkm52ialpj@4ax.com>,
> Alan Balmer <albalmer@att.net> wrote:
>
>> On 16 Aug 2005 10:32:09 -0700, clusardi2k@aol.com wrote:
>> 
>> >
>> >Robert Harris wrote:
>> >> clusardi2k@aol.com wrote:
>> >> >    My second call to fopen doesn't create the file if it has been
>> >> > deleted. I want to also use fopen for its pointer return value.
>> >>
>> >> What is in errno (presuming that fopen has returned NULL)?
>> >
>> >fopen does not return NULL.
>> >
>> >Christopher Lusardi
>> 
>> Then the fopen has succeeded, and the file exists, as far as your
>> program is concerned. Whether is has physically been created at that
>> time is up to the operating system and not topical for comp.lang.c.
>
>This isn't comp.lang.c, it's comp.unix.programmer.

My mistake. He posted the same question on c.l.c., and I wasn't paying
attention to where I was.
>
>But since he's using Windows, not Unix, he's off-topic here as well.
-- 
Al Balmer
Balmer Consulting
removebalmerconsultingthis@att.net
0
Alan
8/17/2005 3:43:27 PM
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

0
clusardi2k
8/17/2005 3:45:01 PM
* clusardi2k@aol.com
| Wow on me, what do you think?

Since you have not stated what the problem exactly is (fopen succeeds,
so what *is* the problem?), it is hard to tell whether anyone will
vote for 'wow'...

However, it sounds like the problem is specific to the fact that the
program runs on a Windows client with a Unix file server (Samba?), so
better ask in a Windows programming group or in the newsgroup for the
file server in question.

R'
0
Ralf
8/18/2005 8:46:40 AM
Reply: