Can't Find Answer Any Where (What would you do/try): fopen ("file on shared drive","w+") doesn't wor

Discussion in 'C++' started by clusardi2k@aol.com, Aug 17, 2005.

  1. Guest

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

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

    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
    Victor Bazarov, Aug 17, 2005
    #2
    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. knutivar
    Replies:
    2
    Views:
    321
    bruce barker
    Dec 9, 2004
  2. Nonee
    Replies:
    2
    Views:
    2,625
    Neredbojias
    Oct 25, 2005
  3. Replies:
    7
    Views:
    798
    Keith Thompson
    Aug 17, 2005
  4. Michel Rouzic
    Replies:
    4
    Views:
    1,816
    Michel Rouzic
    Apr 28, 2008
  5. Kirk I Reiten
    Replies:
    3
    Views:
    730
    Steven Cheng[MSFT]
    Apr 11, 2006
Loading...

Share This Page