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

[Jack Klein]

On Mon, 28 Jan 2008 17:46:54 -0800 (PST), user923005
<dc*****@connx. comwrote in comp.lang.c:

On Jan 28, 5:05*pm, VijaKhara <VijaKh...@gmai l.comwrote:

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.

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.l earn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

[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:Th***** ********@gmail. com>

[user923005]

On Jan 29, 1:52*pm, Kenneth Brody <kenbr...@spamc op.netwrote:

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.

[Richard Bos]

ri*****@cogsci. ed.ac.uk (Richard Tobin) wrote:

Kaz Kylheku <kk******@gmail .comwrote:

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

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

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

[Eric Sosman]

user923005 wrote:

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

While I agree that a failing fopen() (and fread() and
getenv() and time() and ...) *ought* to set errno, I see
no evidence that the omission of such a requirement was due
either to laziness or to stupidity.

If you have direct evidence that any of the Standard
writers were lazy or that any were stupid, please reveal it.
Otherwise, lay off the name-calling.

--
Er*********@sun .com

[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:Th***** ********@gmail. com>

[user923005]

On Jan 30, 7:44*am, Eric Sosman <Eric.Sos...@su n.comwrote:

user923005 wrote:

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

* * *While I agree that a failing fopen() (and fread() and
getenv() and time() and ...) *ought* to set errno, I see
no evidence that the omission of such a requirement was due
either to laziness or to stupidity.

* * *If you have direct evidence that any of the Standard
writers were lazy or that any were stupid, please reveal it.
Otherwise, lay off the name-calling.

I did not say that the standard writers were lazy or stupid. I said
that the decision to not have a failed fopen() set errno was lazy and
stupid. There is a difference between lazy and stupid people and lazy
and stupid decisions (though lazy and stupid people are far more prone
to lazy and stupid decisions than energetic and intelligent ones). My
direct evidence that a lazy and stupid decision was made is that there
is no requirement in the standard for fopen() to set errno.

[David Thompson]

On Tue, 29 Jan 2008 16:52:29 -0500, Kenneth Brody
<ke******@spamc op.netwrote:

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".)

But you can still 'return' an errorcode saying that. Almost exactly
that was done by Multics, one of the biggest completely carried
through efforts at a secure multiuser system. (IIRC it was the only
system at the time to be certified 'orange book' A-something, and one
of the few ever.) I got all too familiar with an errorcode that
decoded as 'insufficient access to return any information', sometimes
because of incorrect ACL settings and sometimes because I had
accidentally requested the wrong thing.

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.

- formerly david.thompson1 || achar(64) || worldnet.att.ne t