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

Discussion in 'C Programming' started by VijaKhara, Jan 29, 2008.

  1. VijaKhara

    VijaKhara Guest

    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
     
    VijaKhara, Jan 29, 2008
    #1
    1. Advertising

  2. VijaKhara

    Ben Pfaff Guest

    VijaKhara <> writes:

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

    --
    char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
    ={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa67f6aaa,0xaa9aa9f6,0x11f6},*p
    =b,i=24;for(;p+=!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
    2:{i++;if(i)break;else default:continue;if(0)case 1:putchar(a[i&15]);break;}}}
     
    Ben Pfaff, Jan 29, 2008
    #2
    1. Advertising

  3. VijaKhara

    user923005 Guest

    On Jan 28, 5:05 pm, VijaKhara <> wrote:
    > 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.

    > Thanks
     
    user923005, Jan 29, 2008
    #3
  4. VijaKhara

    Jack Klein Guest

    On Mon, 28 Jan 2008 17:46:54 -0800 (PST), user923005
    <> wrote in comp.lang.c:

    > On Jan 28, 5:05 pm, VijaKhara <> wrote:
    > > 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.learn.c-c++
    http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html
     
    Jack Klein, Jan 29, 2008
    #4
  5. VijaKhara

    user923005 Guest

    On Jan 28, 7:35 pm, Jack Klein <> wrote:
    > On Mon, 28 Jan 2008 17:46:54 -0800 (PST), user923005
    > <> wrote in comp.lang.c:
    >
    >
    >
    >
    >
    > > On Jan 28, 5:05 pm, VijaKhara <> wrote:
    > > > 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.


    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.
     
    user923005, Jan 29, 2008
    #5
  6. VijaKhara

    santosh Guest

    user923005 wrote:

    > On Jan 28, 7:35 pm, Jack Klein <> wrote:


    <snip>

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


    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.
     
    santosh, Jan 29, 2008
    #6
  7. VijaKhara

    user923005 Guest

    On Jan 29, 12:28 am, santosh <> wrote:
    > user923005 wrote:
    > > On Jan 28, 7:35 pm, Jack Klein <> wrote:

    >
    > <snip>
    >
    > >> 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.

    >
    > 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.
     
    user923005, Jan 29, 2008
    #7
  8. VijaKhara

    Kaz Kylheku Guest

    On Jan 29, 11:52 am, user923005 <> wrote:
    > 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.
     
    Kaz Kylheku, Jan 29, 2008
    #8
  9. VijaKhara

    user923005 Guest

    On Jan 29, 12:41 pm, Kaz Kylheku <> wrote:
    > On Jan 29, 11:52 am, user923005 <> wrote:
    >
    > > 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?


    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.
     
    user923005, Jan 29, 2008
    #9
  10. In article <>,
    user923005 <> wrote:

    >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.
    --
    "History is a pile of debris" -- Laurie Anderson
     
    Walter Roberson, Jan 29, 2008
    #10
  11. VijaKhara

    user923005 Guest

    On Jan 29, 1:32 pm, -cnrc.gc.ca (Walter Roberson)
    wrote:
    > In article <>,
    >
    > user923005  <> wrote:
    > >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.


    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.
     
    user923005, Jan 29, 2008
    #11
  12. 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:>
     
    Kenneth Brody, Jan 29, 2008
    #12
  13. VijaKhara

    user923005 Guest

    On Jan 29, 1:52 pm, Kenneth Brody <> wrote:
    > 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.
     
    user923005, Jan 29, 2008
    #13
  14. user923005 wrote:
    > 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
    .....


    --
    Mark McIntyre

    CLC FAQ <http://c-faq.com/>
    CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
     
    Mark McIntyre, Jan 29, 2008
    #14
  15. In article <>,
    Kaz Kylheku <> wrote:

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


    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
    --
    :wq
     
    Richard Tobin, Jan 29, 2008
    #15
  16. VijaKhara

    CBFalconer Guest

    user923005 wrote:
    > Jack Klein <> wrote:
    >

    .... snip ...
    >>
    >> 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.


    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.

    --
    [mail]: Chuck F (cbfalconer at maineline dot net)
    [page]: <http://cbfalconer.home.att.net>
    Try the download section.



    --
    Posted via a free Usenet account from http://www.teranews.com
     
    CBFalconer, Jan 29, 2008
    #16
  17. VijaKhara

    CBFalconer Guest

    user923005 wrote:
    > Kaz Kylheku <> wrote:
    >

    .... snip ...
    >>
    >> 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.


    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.

    --
    [mail]: Chuck F (cbfalconer at maineline dot net)
    [page]: <http://cbfalconer.home.att.net>
    Try the download section.



    --
    Posted via a free Usenet account from http://www.teranews.com
     
    CBFalconer, Jan 29, 2008
    #17
  18. VijaKhara

    santosh Guest

    user923005 wrote:

    > On Jan 29, 12:28 am, santosh <> wrote:
    >> user923005 wrote:
    >> > On Jan 28, 7:35 pm, Jack Klein <> wrote:

    >>
    >> <snip>
    >>
    >> >> 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.

    >>
    >> 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?


    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.

    > This is a lazy result for the standards committee. Quite frankly,
    > it's a black eye on the C language.
     
    santosh, Jan 30, 2008
    #18
  19. VijaKhara

    Richard Bos Guest

    (Richard Tobin) wrote:

    > Kaz Kylheku <> wrote:
    >
    > >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
     
    Richard Bos, Jan 30, 2008
    #19
  20. 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:>
     
    Kenneth Brody, Jan 30, 2008
    #20
    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. -berlin.de

    How to create folder at fopen?

    -berlin.de, Sep 1, 2004, in forum: C Programming
    Replies:
    15
    Views:
    1,799
    Michael Wojcik
    Sep 3, 2004
  3. Ben
    Replies:
    2
    Views:
    961
  4. Michel Rouzic
    Replies:
    4
    Views:
    1,859
    Michel Rouzic
    Apr 28, 2008
  5. Lawrence D'Oliveiro

    Death To Sub-Sub-Sub-Directories!

    Lawrence D'Oliveiro, May 5, 2011, in forum: Java
    Replies:
    92
    Views:
    2,172
    Lawrence D'Oliveiro
    May 20, 2011
Loading...

Share This Page