fopen() with full path affecting subsequent fopen calls

Discussion in 'C Programming' started by Michel Rouzic, Apr 28, 2008.

  1. I made a program that accepts as parameters an input file name that
    we'll call file1, and an output file name that we'll call file2, and
    opens on its own a configuration file called file3. My program works
    correctly when calling it like this : ./program file1 file2, and also
    with full paths, like this : ./program c:\dir\file1 c:\dir\file2

    However, a most puzzling phenomenon occurs when I use the full path
    only for the first file, like this : ./program c:\dir\file1 file2.
    Normally I would expect file2 to be written in the same place as it
    did when I didn't use the full path for file1. Only that's not what
    happens. File2 gets successfully written to, as well as file3 (which
    my program loads data from and saves data into), only not where I
    expect, and actually, I don't have a single clue where they can be.
    They're surely getting written to a valid place because the program
    operates normally and file3, the one from the mysterious location,
    gets read from normally.

    So here's my problem stated in a more concise manner : if I call
    fopen() using a full path, it affects subsequent fopen() calls in that
    if they don't call absolute paths they will try to reach the files in
    an unknown location, which is definitely not what I want.

    I'd really like to understand how one fopen() call can affect all
    others, although they are completely unrelated, and how I can make
    sure this doesn't happen. Oh and I made sure this wasn't a backslash
    issue by replacing backslashes with forward slashes in my full paths.

    Thanks in advance
     
    Michel Rouzic, Apr 28, 2008
    #1
    1. Advertising

  2. Michel Rouzic

    Guest

    On Apr 28, 3:14 pm, Michel Rouzic <> wrote:
    > I made a program that accepts as parameters an input file name that
    > we'll call file1, and an output file name that we'll call file2, and
    > opens on its own a configuration file called file3. My program works
    > correctly when calling it like this : ./program file1 file2, and also
    > with full paths, like this : ./program c:\dir\file1 c:\dir\file2
    >
    > However, a most puzzling phenomenon occurs when I use the full path
    > only for the first file, like this : ./program c:\dir\file1 file2.
    > Normally I would expect file2 to be written in the same place as it
    > did when I didn't use the full path for file1. Only that's not what
    > happens. File2 gets successfully written to, as well as file3 (which
    > my program loads data from and saves data into), only not where I
    > expect, and actually, I don't have a single clue where they can be.
    > They're surely getting written to a valid place because the program
    > operates normally and file3, the one from the mysterious location,
    > gets read from normally.
    >
    > So here's my problem stated in a more concise manner : if I call
    > fopen() using a full path, it affects subsequent fopen() calls in that
    > if they don't call absolute paths they will try to reach the files in
    > an unknown location, which is definitely not what I want.

    Of course it does not. We can't be 100% sure of what actually happends
    without seeing your code.
    Try to isolate the problem in the least lines possible before you post
    it.
     
    , Apr 28, 2008
    #2
    1. Advertising

  3. Michel Rouzic

    Bill Reid Guest

    <> wrote in message
    news:...
    > On Apr 28, 3:14 pm, Michel Rouzic <> wrote:


    > > I made a program that accepts as parameters an input file name that
    > > we'll call file1, and an output file name that we'll call file2, and
    > > opens on its own a configuration file called file3. My program works
    > > correctly when calling it like this : ./program file1 file2, and also
    > > with full paths, like this : ./program c:\dir\file1 c:\dir\file2
    > >
    > > However, a most puzzling phenomenon occurs when I use the full path
    > > only for the first file, like this : ./program c:\dir\file1 file2.
    > > Normally I would expect file2 to be written in the same place as it
    > > did when I didn't use the full path for file1. Only that's not what
    > > happens. File2 gets successfully written to, as well as file3 (which
    > > my program loads data from and saves data into), only not where I
    > > expect, and actually, I don't have a single clue where they can be.
    > > They're surely getting written to a valid place because the program
    > > operates normally and file3, the one from the mysterious location,
    > > gets read from normally.
    > >
    > > So here's my problem stated in a more concise manner : if I call
    > > fopen() using a full path, it affects subsequent fopen() calls in that
    > > if they don't call absolute paths they will try to reach the files in
    > > an unknown location, which is definitely not what I want.


    > Of course it does not. We can't be 100% sure of what actually happends
    > without seeing your code.
    > Try to isolate the problem in the least lines possible before you post
    > it.


    It's very likely a "current working directory" problem of some sort,
    and of course, not a part of the "C" standard, like all directory issues.
    Despite the egregious off-topic nature of the post, he should search
    through the documentation for his compiler for functions that change
    the "current working directory", and then evaluate carefully what
    that directory would be at each fopen() call.

    ---
    William Ernest Reid
     
    Bill Reid, Apr 28, 2008
    #3
  4. In article <dHkRj.135868$>,
    Bill Reid <> wrote:

    >It's very likely a "current working directory" problem of some sort,
    >and of course, not a part of the "C" standard, like all directory issues.
    >Despite the egregious off-topic nature of the post, he should search
    >through the documentation for his compiler for functions that change
    >the "current working directory", and then evaluate carefully what
    >that directory would be at each fopen() call.


    It might be useful to print out the current directory before each call
    to fopen(), to see if it's changing. I take it from the filenames
    that it's a Windows system, but quite likely the Posix getcwd()
    function will be available.

    -- Richard
    --
    :wq
     
    Richard Tobin, Apr 28, 2008
    #4
  5. Bill Reid wrote:
    > It's very likely a "current working directory" problem of some sort,
    > and of course, not a part of the "C" standard, like all directory issues.
    > Despite the egregious off-topic nature of the post, he should search
    > through the documentation for his compiler for functions that change
    > the "current working directory", and then evaluate carefully what
    > that directory would be at each fopen() call.


    My bad, seems like I mis-reported my problem. It seems to only happen
    when I drag and drop file1 on the program. I used your advice and did
    a getcwd() and as it turns out when and only when I drag and drop
    file1 on the program, the current working directory changes to c:
    \windows\system32, and that happens even before any fopen() call.

    My apologies, this is decidedly a platform specific problem.
     
    Michel Rouzic, Apr 28, 2008
    #5
    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. Nonee
    Replies:
    2
    Views:
    2,711
    Neredbojias
    Oct 25, 2005
  2. K. Jansma
    Replies:
    7
    Views:
    338
    Duncan Booth
    Feb 21, 2006
  3. Lars Uffmann

    tmpnam behaviour on subsequent calls

    Lars Uffmann, Jan 18, 2008, in forum: C++
    Replies:
    8
    Views:
    1,206
    James Kanze
    Jan 22, 2008
  4. dude
    Replies:
    5
    Views:
    1,787
    Jussi Piitulainen
    Mar 17, 2011
  5. Replies:
    0
    Views:
    104
Loading...

Share This Page