Fopen to create a file in a sub-folder (such as "Mygoal").

[VijaKhara]

Hi all,

Please tell me how to create a file (using fopen) in a sub-folder
(such as sub-folder "Mygoal")? I tried

if ( ( fp = fopen ( "mygoal\myfile.tif", "wb" ) ) == NULL ) {
fprintf ( stderr, "cannot open file %s\n");
exit ( 1 );
}

But it doesn't work.

Also , is there anyone know how to get the current directory from C
codes?

Thanks

 

[Ben Pfaff]

Please tell me how to create a file (using fopen) in a sub-folder
(such as sub-folder "Mygoal")? I tried

if ( ( fp = fopen ( "mygoal\myfile.tif", "wb" ) ) == NULL ) {
fprintf ( stderr, "cannot open file %s\n");
exit ( 1 );
}

Please read the FAQ.

19.17: Why can't I open a file by its explicit path? The call

fopen("c:\newdir\file.dat", "r")

is failing.

A: The file you actually requested -- with the characters \n and \f
in its name -- probably doesn't exist, and isn't what you
thought you were trying to open.

In character constants and string literals, the backslash \ is
an escape character, giving special meaning to the character
following it. In order for literal backslashes in a pathname to
be passed through to fopen() (or any other function) correctly,
they have to be doubled, so that the first backslash in each
pair quotes the second one:

fopen("c:\\newdir\\file.dat", "r")

Alternatively, under MS-DOS, it turns out that forward slashes
are also accepted as directory separators, so you could use

fopen("c:/newdir/file.dat", "r")

(Note, by the way, that header file names mentioned in
preprocessor #include directives are *not* string literals, so
you may not have to worry about backslashes there.)

 

[user923005]

Hi all,

Please tell me how to create a file (using fopen) in a sub-folder
(such as sub-folder "Mygoal")? I tried

if ( ( fp = fopen ( "mygoal\myfile.tif", "wb" ) ) == NULL ) {
    fprintf ( stderr, "cannot open file %s\n");
    exit ( 1 );
  }

But it doesn't work.

Look up errno return and call perror to find out what went wrong.
Besides Ben's comment, some compilers may now allow you to create a
file in a directory that does not exist.

In order to make non-portable directory stuff more portable, try this
thing:
http://legacy.imatix.com/pub/sfl/src/sflsrc21.tgz
Documentation is here:
http://legacy.imatix.com/pub/sfl/doc/sfldoc21.tgz

Also , is there anyone know how to get the current directory from C
codes?

The ANSI/ISO C specification does not describe how to do this.
Some compilers offer a function called either getcwd() or _getcwd() to
collect the current working directory. Try your compiler docs for
that.

 

[Jack Klein]

Look up errno return and call perror to find out what went wrong.
Besides Ben's comment, some compilers may now allow you to create a
file in a directory that does not exist.

Why lookup errno? fopen() is not required to set it.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

 

[user923005]

Why lookup errno?  fopen() is not required to set it.

Too bad. It works on all the platforms that I care about (POSIX,
Windows, OpenVMS, MVS), but it is still tragic that a place where it
would obviously be helpful is left in the cold. I would be curious as
to why such an obviously helpful diagnostic was deemed unnecessary. I
mean, even if I am opening a port in a toaster IC, I would not see any
reason why a hint as to what went wrong would not be in order.

 

[santosh]

Too bad. It works on all the platforms that I care about (POSIX,
Windows, OpenVMS, MVS), but it is still tragic that a place where it
would obviously be helpful is left in the cold. I would be curious as
to why such an obviously helpful diagnostic was deemed unnecessary. I
mean, even if I am opening a port in a toaster IC, I would not see any
reason why a hint as to what went wrong would not be in order.

That's exactly the current situation isn't it? In practise errno is set
to something meaningful if the system can do so, but since not all
systems may have that capability the Standard declined from mandating
that errno shall be set by fopen() after a failure.

 

[user923005]

That's exactly the current situation isn't it? In practise errno is set
to something meaningful if the system can do so, but since not all
systems may have that capability the Standard declined from mandating
that errno shall be set by fopen() after a failure.

Can you please describe for me a scenario where opening a file fails
and it is not possible to diagnose why?

This is a lazy result for the standards committee. Quite frankly,
it's a black eye on the C language.

 

[Kaz Kylheku]

This is a lazy result for the standards committee.  Quite frankly,
it's a black eye on the C language.

Can you describe a situation in which a C implementor would duck out
of setting errno in fopen, just because the standard allows it?

An implementation can conform, yet demonstrate poor quality in a
myriad other ways than this.

For instance, suppose that your compiler only emits the message ``this
translation unit requires a diagnostic''. No filename, no line number,
no information.

You know you can test whether or not fopen set errno. Assign zero to
errno before calling fopen. If fopen fails, and errno is found to be
nonzero, then take advantage of the value.

 

[user923005]

Can you describe a situation in which a C implementor would duck out
of setting errno in fopen, just because the standard allows it?

Sure, people do stupid things that follow the standard exactly all the
time.
For instance, I know of one compiler vendor who coded to exactly the
standard limits.
(e.g. nest levels, line lengths, etc.).
Now, it was no difficulty whatsoever to allow longer lines and deeper
limits.
But because the standard says it must be _at least_ x, all values were
set to x.

An implementation can conform, yet demonstrate poor quality in a
myriad other ways than this.

For instance, suppose that your compiler only emits the message ``this
translation unit requires a diagnostic''. No filename, no line number,
no information.

You know you can test whether or not fopen set errno. Assign zero to
errno before calling fopen. If fopen fails, and errno is found to be
nonzero, then take advantage of the value.

There are not any compilers that I know of that do not set the errno
value on fopen() failure.
But the fact that you are allowed to leave errno unchanged is clearly
a gaffe.

 

[Walter Roberson]

Sure, people do stupid things that follow the standard exactly all the
time.
For instance, I know of one compiler vendor who coded to exactly the
standard limits.
(e.g. nest levels, line lengths, etc.).
Now, it was no difficulty whatsoever to allow longer lines and deeper
limits.
But because the standard says it must be _at least_ x, all values were
set to x.

Could be a useful compiler for testing conformance with the
minimums permitted by the standard. Not necessarily a design flaw
at all.

 

[user923005]

Could be a useful compiler for testing conformance with the
minimums permitted by the standard. Not necessarily a design flaw
at all.

It's only a problem when the minimuns are inadequate. In such a case,
it is truly a design flaw, because the design (aka the C Standard) did
not state an adequate miniumum. This can really be a problem, because
the C Standard is designed so that a C compiler can be written for
some itty-bitty microcontroller. The minimums for something like that
do not make sense on a 500 million dollar mainframe.

 

[Kenneth Brody]

user923005 wrote:
[...]

There are not any compilers that I know of that do not set the errno
value on fopen() failure.
But the fact that you are allowed to leave errno unchanged is clearly
a gaffe.

The fact that neither you nor I know of any systems which do not
set errno does not mean that there aren't any. I can imagine a
"security" system which would prohibit access to some files, but
for security reasons, refuse to tell you why. (ie: there is no
way to distinguish between "the file doesn't exist" and "the file
does exist, but you didn't give the correct encryption key".)

However, if I were on the committee, I would have suggested making
something like a generic EUNKNOWN error code, which could be used
on systems where a failure could occur, but for which the C runtime
could not determine the "true" cause. (Perhaps the O/S simply
returns a "failed" condition?) At least, you could then trust that
errno was set, even if you can't guarantee that it was set to a
"known" error code. For all I know, the suggestion was made, but
reject for some reason.

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[user923005]

user923005 wrote:

[...]

There are not any compilers that I know of that do not set the errno
value on fopen() failure.
But the fact that you are allowed to leave errno unchanged is clearly
a gaffe.

The fact that neither you nor I know of any systems which do not
set errno does not mean that there aren't any.  I can imagine a
"security" system which would prohibit access to some files, but
for security reasons, refuse to tell you why.  (ie: there is no
way to distinguish between "the file doesn't exist" and "the file
does exist, but you didn't give the correct encryption key".)

I'm sorry, but EACCES is the logical return here, and not telling me
why serves no purpose.

However, if I were on the committee, I would have suggested making
something like a generic EUNKNOWN error code, which could be used
on systems where a failure could occur, but for which the C runtime
could not determine the "true" cause.  (Perhaps the O/S simply
returns a "failed" condition?)  At least, you could then trust that
errno was set, even if you can't guarantee that it was set to a
"known" error code.  For all I know, the suggestion was made, but
reject for some reason.

I'm not buying it. It was a lazy and stupid decision.

 

[Mark McIntyre]

Can you please describe for me a scenario where opening a file fails
and it is not possible to diagnose why?

Depends what you mean by "why". There may be an underlying 'why' which
was not determinable by the requester.

Consider that in some circumstances, knowing that a file exists is
useful information for a hacker. Your OS might therefore refuse to
confirm both the existence and nonexistence of the file.

Sorta like asking MI5 the name of their operative in New york. Their
answer might well be "we neither confirm nor deny that we even have
operatives"

This is a lazy result for the standards committee. Quite frankly,
it's a black eye on the C language.

Not so sure. Unless you restrict the errono value to "success" and
"failure" ther are too many reasons for failure to usefully codify.

E-NOTFOUND
E-ACCESS-DENIED
E-DISK-REMOVED
E-FILE-DELETED-BY-OTHER-PROCESS
E-FILE-LOCKED-BY-OTHER-USER
E-FILE-LOCKED-BY-YOU-ALREADY
E-TAPE-MISSING
E-TAPE-NEEDS-REWOUND
E-ITS-MONDAY
.....

 

[Richard Tobin]

This is a lazy result for the standards committee.  Quite frankly,
it's a black eye on the C language.

Can you describe a situation in which a C implementor would duck out
of setting errno in fopen, just because the standard allows it?

An implementation can conform, yet demonstrate poor quality in a
myriad other ways than this.

For instance, suppose that your compiler only emits the message ``this
translation unit requires a diagnostic''. No filename, no line number,
no information.[/QUOTE]

And yet the standard *does* require a diagnostic, even if it's a
useless one. Why doesn't it do the same for fopen(), requiring
errno to be set, even if to a useless value?

You know you can test whether or not fopen set errno. Assign zero to
errno before calling fopen. If fopen fails, and errno is found to be
nonzero, then take advantage of the value.

And what's the advantage of requiring the user to do this test?

-- Richard

 

[CBFalconer]

.... snip ...

Too bad. It works on all the platforms that I care about (POSIX,
Windows, OpenVMS, MVS), but it is still tragic that a place where
it would obviously be helpful is left in the cold. I would be
curious as to why such an obviously helpful diagnostic was deemed
unnecessary. I mean, even if I am opening a port in a toaster IC,
I would not see any reason why a hint as to what went wrong would
not be in order.

Reminds me of the elegant Microsoft error returns from their
interface software. A routine with about umpty-ump parameters
always returned a code (which had to be laboriously looked up)
which translated to "parameter error". It didn't even identify the
parameter. Untangling that took about two days.

 

[CBFalconer]

.... snip ...

There are not any compilers that I know of that do not set the
errno value on fopen() failure. But the fact that you are allowed
to leave errno unchanged is clearly a gaffe.

Not so. For example, it allows a very tight system to be generated
that will fit into a chip/memory combination. If testing/debugging
that lack may be a nuisance, but it is not a gaffe.

 

[santosh]

Can you please describe for me a scenario where opening a file fails
and it is not possible to diagnose why?

Personally no. The best I can think of is that some primitive or
otherwised brain-damaged systems failed to provide a proper diagnostic
for some file open failures to fopen(), which means that fopen() could
not sensibly set errno for all instances of failure.

As Chris Hills put it, C goes out of it's way to accommodate itself to
the hardware unlike some other languages. If some systems somewhere
were damaged in this way I suppose the Committee would have preffered
to have fopen() adapt for them than insist that it return sensible
error messages and force the system software manufacturers to put out
patches.

 

[Richard Bos]

And yet the standard *does* require a diagnostic, even if it's a
useless one. Why doesn't it do the same for fopen(), requiring
errno to be set, even if to a useless value?

Because it adds nothing of importance to that fopen() call. If all you
want to know is _whether_ the call succeeded, and you either don't care
or aren't allowed to know _why_, you don't need errno, you can just
check whether fopen() returned a null pointer.
Granted, this ignores the scenario where you string several function
calls together, one of which is an fopen(), and you want to check
afterwards if any of them set errno. That is a reason to make fopen()
set errno, but I posit that, in the case of fopen(), it is not as likely
a scenario as in the case of, e.g., a string of floating point
computations.

Richard

 

[Kenneth Brody]

CBFalconer wrote:
[...]

Reminds me of the elegant Microsoft error returns from their
interface software. A routine with about umpty-ump parameters
always returned a code (which had to be laboriously looked up)
which translated to "parameter error". It didn't even identify the
parameter. Untangling that took about two days.

And let's not forget the XP SP2 upgrade, which has a tendency to
give, 25 minutes into the install, the message "Access Denied", and
then spend another 25 minutes undoing what it had done up to that
point. (Yes, that's the entire text of the error message.)

However, your example does relate back to the original "why doesn't
the Standard require fopen() to set errno" question. If the
Standard were to require errno to be set, wouldn't it also need to
define all of the possible error values? Would it make sense for
the Standard to say "errno must be set to an implementation-defined
value"?

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>