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

Discussion in 'C Programming' started by clusardi2k@aol.com, Aug 16, 2005.

  1. Guest

    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
     
    , Aug 16, 2005
    #1
    1. Advertising

  2. Guest

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

    Sorry,
    Christopher Lusardi
     
    , Aug 16, 2005
    #2
    1. Advertising

  3. Re: fopen ("file on shared drive","w+") doesn't work on 2nd call usingWindows LabView DDL

    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 "implementation 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:>
     
    Kenneth Brody, Aug 16, 2005
    #3
  4. SM Ryan Guest

    # 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_CREAT|O_WRONLY,0755);
    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.
     
    SM Ryan, Aug 16, 2005
    #4
  5. Guest

    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
     
    , Aug 17, 2005
    #5
  6. Guest

    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
     
    , Aug 17, 2005
    #6
  7. Re: fopen ("file on shared drive","w+") doesn't work on 2nd call usingWindows LabView DDL

    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:>
     
    Kenneth Brody, Aug 17, 2005
    #7
  8. Re: fopen ("file on shared drive","w+") doesn't work on 2nd callusing Windows LabView DDL

    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_Keith) <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.
     
    Keith Thompson, Aug 17, 2005
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Marina
    Replies:
    0
    Views:
    917
    Marina
    Aug 12, 2003
  2. Nonee
    Replies:
    2
    Views:
    2,656
    Neredbojias
    Oct 25, 2005
  3. john

    FPGA LABVIEW programming

    john, Aug 1, 2006, in forum: VHDL
    Replies:
    3
    Views:
    5,319
    Mike Treseler
    Aug 1, 2006
  4. Replies:
    1
    Views:
    504
    Victor Bazarov
    Aug 17, 2005
  5. Michel Rouzic
    Replies:
    4
    Views:
    1,834
    Michel Rouzic
    Apr 28, 2008
Loading...

Share This Page