Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > fopen() with full path affecting subsequent fopen calls

Reply
Thread Tools

fopen() with full path affecting subsequent fopen calls

 
 
Michel Rouzic
Guest
Posts: n/a
 
      04-28-2008
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
 
Reply With Quote
 
 
 
 
vippstar@gmail.com
Guest
Posts: n/a
 
      04-28-2008
On Apr 28, 3:14 pm, Michel Rouzic <(E-Mail Removed)> 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.
 
Reply With Quote
 
 
 
 
Bill Reid
Guest
Posts: n/a
 
      04-28-2008

<(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> On Apr 28, 3:14 pm, Michel Rouzic <(E-Mail Removed)> 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



 
Reply With Quote
 
Richard Tobin
Guest
Posts: n/a
 
      04-28-2008
In article <dHkRj.135868$(E-Mail Removed)>,
Bill Reid <(E-Mail Removed)> 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
 
Reply With Quote
 
Michel Rouzic
Guest
Posts: n/a
 
      04-28-2008


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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
os.path.walk() to get full path of all files dude Python 5 03-17-2011 09:09 AM
MIME::Head subsequent calls in a loop return empty values ebg005@gmail.com Perl Misc 0 02-07-2008 09:45 AM
tmpnam behaviour on subsequent calls Lars Uffmann C++ 8 01-22-2008 10:45 AM
share function argument between subsequent calls but not between class instances! K. Jansma Python 7 02-21-2006 01:31 PM
What is up with fopen??? FOpen and local directories Nonee HTML 2 10-25-2005 09:18 PM



Advertisments