How to check the status of a directory in C under Unix? - Unix

This is a discussion on How to check the status of a directory in C under Unix? - Unix ; Hi, I need to write a C program that allows me to write to a file with full directory to that. I asked the question in the C google group and knew i should create the directory first by system("mkdir ...

+ Reply to Thread
Results 1 to 20 of 20

Thread: How to check the status of a directory in C under Unix?

  1. How to check the status of a directory in C under Unix?

    Hi,

    I need to write a C program that allows me to write to a file with
    full directory to that. I asked the question in the C google group and
    knew i should create the directory first by system("mkdir testdir") if
    the directory is not exist, and then I have a question arised from
    this question. Because I create the directory, I should check whether
    it is exist or not, its writting permission etc. I knew that I can use
    ls -l to see the directory permission in Unix, but how can i check
    that in a C program on whether the directory is exist or not and its
    writting permission?

    Thanks a lot for the help.

    Hongyu

  2. Re: How to check the status of a directory in C under Unix?

    In article
    <1ca9ae14-887a-4c1f-a1f1-0bc0a6273218@a70g2000hsh.googlegroups.com>,
    Hongyu wrote:

    > Hi,
    >
    > I need to write a C program that allows me to write to a file with
    > full directory to that. I asked the question in the C google group and
    > knew i should create the directory first by system("mkdir testdir") if
    > the directory is not exist, and then I have a question arised from
    > this question. Because I create the directory, I should check whether
    > it is exist or not, its writting permission etc. I knew that I can use
    > ls -l to see the directory permission in Unix, but how can i check
    > that in a C program on whether the directory is exist or not and its
    > writting permission?
    >
    > Thanks a lot for the help.
    >
    > Hongyu


    stat(2).

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***

  3. Re: How to check the status of a directory in C under Unix?

    Barry Margolin writes:

    > In article
    > <1ca9ae14-887a-4c1f-a1f1-0bc0a6273218@a70g2000hsh.googlegroups.com>,
    > Hongyu wrote:


    > ... but how can i check
    >> that in a C program on whether the directory is exist or not and its
    >> writting permission?

    >
    > stat(2).


    Having seem your post on comp.lang.c I suspect this reply might
    confuse you. When you see somename(num) it is usually a reference to
    somename in the section num of the Unix/Linux/*nix manual. Hence
    Barry Margolin is suggesting you read:

    man 2 stat

    Section 2 documents system calls. man stat is likely to give you
    information about a command called stat and man 3 stat will tell you
    about a very similar POSIX function (section 3 is for library
    functions). It is merely a happy accident that stat is in so many
    sections.

    --
    Ben.

  4. Re: How to check the status of a directory in C under Unix?

    On Aug 11, 5:29 pm, Hongyu wrote:
    > Hi,
    >
    > I need to write a C program that allows me to write to a file with
    > full directory to that. I asked the question in the C google group and
    > knew i should create the directory first by system("mkdir testdir") if
    > the directory is not exist, and then I have a question arised from
    > this question. Because I create the directory, I should check whether
    > it is exist or not, its writting permission etc. I knew that I can use
    > ls -l to see the directory permission in Unix, but how can i check
    > that in a C program on whether the directory is exist or not and its
    > writting permission?


    You might want to use the mkdir() function to create your directory
    instead of system("mkdir ..."). It might be simpler.

    Also, it may be unnecessary to do your test. If the directory exists
    then mkdir() will fail (return -1). I presume the reason for wanting
    to check the write permission is you want to create something in the
    directory; if so, just try to create it and see if it fails. You can
    do the test first with stat() if you want, but even if it checks out
    okay, it is possible that in between the check and actually creating
    the directory, some other process creates the directory, and then
    mkdir() will fail anyway, and you'll have to handle it. So doing the
    check first will probably just result in writing the same error
    handling code twice.

  5. Re: How to check the status of a directory in C under Unix?

    As mentioned, you should use mkdir(2) which will tell you if the
    relevant directory was indeed created.

    On Aug 12, 2:29*am, Hongyu wrote:
    > Hi,
    >
    > I need to write a C program that allows me to write to a file with
    > full directory to that. I asked the question in the C google group and
    > knew i should create the directory first by system("mkdir testdir") if
    > the directory is not exist, and then I have a question arised from
    > this question. Because I create the directory, I should check whether
    > it is exist or not, its writting permission etc. I knew that I can use
    > ls -l to see the directory permission in Unix, but how can i check
    > that in a C program on whether the directory is exist or not and its
    > writting permission?
    >
    > Thanks a lot for the help.
    >
    > Hongyu



  6. Re: How to check the status of a directory in C under Unix?

    On Aug 12, 3:15*am, stdazi wrote:
    > As mentioned, you should use mkdir(2) which will tell you if the
    > relevant directory was indeed created.
    >
    > On Aug 12, 2:29*am, Hongyu wrote:
    >
    >
    >
    > > Hi,

    >
    > > I need to write a C program that allows me to write to a file with
    > > full directory to that. I asked the question in the C google group and
    > > knew i should create the directory first by system("mkdir testdir") if
    > > the directory is not exist, and then I have a question arised from
    > > this question. Because I create the directory, I should check whether
    > > it is exist or not, its writting permission etc. I knew that I can use
    > > ls -l to see the directory permission in Unix, but how can i check
    > > that in a C program on whether the directory is exist or not and its
    > > writting permission?

    >
    > > Thanks a lot for the help.

    >
    > > Hongyu- Hide quoted text -

    >
    > - Show quoted text -


    Thanks everyone's help. I think all of you are correct in that I don't
    need to checkt the status and can use the mkdir() directly, because if
    the directory is already exist or if it is failed to create, mkdir()
    will return -1. I have posted my final code in the comp.lang.c group,
    even if the code there still check the directory status using
    access(), but actually I did find if I didn't use it and just use
    mkdir() as you mentioned here, the code still worked.

    But I still learn something from here too such as show to read
    somename(num), more information on stat() and mkdir() etc. Appreciate
    it!

  7. Re: How to check the status of a directory in C under Unix?

    Hongyu writes:

    > Thanks everyone's help. I think all of you are correct in that I don't
    > need to checkt the status and can use the mkdir() directly, because if
    > the directory is already exist or if it is failed to create, mkdir()
    > will return -1. I have posted my final code in the comp.lang.c group,
    > even if the code there still check the directory status using
    > access(), but actually I did find if I didn't use it and just use
    > mkdir() as you mentioned here, the code still worked.


    Due to a mechanism called the file creation mask -- see umask) it is
    possible, though unusual, that the created directory is not writable
    by the user that made it.

    That does not mean that I am advocating that you should check access.
    In many cases the best strategy is to try to do what you need to do
    and simply report that you were not able to do it. I.e. don't check
    that you can -- just try.

    --
    Ben.

  8. Re: How to check the status of a directory in C under Unix?

    On Aug 11, 8:29 pm, Hongyu wrote:
    > Hi,
    >
    > I need to write a C program that allows me to write to a file with
    > full directory to that. I asked the question in the C google group and
    > knew i should create the directory first by system("mkdir testdir") if
    > the directory is not exist, and then I have a question arised from
    > this question. Because I create the directory, I should check whether
    > it is exist or not, its writting permission etc. I knew that I can use
    > ls -l to see the directory permission in Unix, but how can i check
    > that in a C program on whether the directory is exist or not and its
    > writting permission?
    >
    > Thanks a lot for the help.
    >
    > Hongyu


    You should *always* check the directory's existence with 'stat',
    either before or after the call to 'mkdir'. This is because the call
    to 'mkdir' will fail *no matter what type* the entry is with the
    corresponding name. For example, a pipe named "directory" will cause
    the call 'mkdir("directory", 0700);' to fail, but obviously there's no
    directory with the name you want. The result of 'stat' will tell you
    both the type of the entry and its permissions, though the 'access'
    function is a better way to check whether or not the current process
    has the appropriate access permissions with its current euid and
    egid. Additionally, avoid 'system' in cases where there's a libc
    function that does the same thing as your command line (i.e. 'mkdir'.)
    Kevin P. Barry

  9. Re: How to check the status of a directory in C under Unix?

    ta0kira@yahoo.com writes:
    > On Aug 11, 8:29 pm, Hongyu wrote:
    >> Hi,
    >>
    >> I need to write a C program that allows me to write to a file with
    >> full directory to that. I asked the question in the C google group and
    >> knew i should create the directory first by system("mkdir testdir") if
    >> the directory is not exist, and then I have a question arised from
    >> this question. Because I create the directory, I should check whether
    >> it is exist or not, its writting permission etc. I knew that I can use
    >> ls -l to see the directory permission in Unix, but how can i check
    >> that in a C program on whether the directory is exist or not and its
    >> writting permission?
    >>
    >> Thanks a lot for the help.
    >>
    >> Hongyu

    >
    > You should *always* check the directory's existence with 'stat',
    > either before or after the call to 'mkdir'. This is because the call
    > to 'mkdir' will fail *no matter what type* the entry is with the
    > corresponding name. For example, a pipe named "directory" will cause
    > the call 'mkdir("directory", 0700);' to fail, but obviously there's no
    > directory with the name you want. The result of 'stat' will tell you
    > both the type of the entry and its permissions,


    These types of checks are generally of dubious usefulness, because
    another process could create or remove the directory or 'other entry'
    at any time.

  10. Re: How to check the status of a directory in C under Unix?

    On Aug 22, 4:56 am, Rainer Weikusat wrote:

    > These types of checks are generally of dubious usefulness, because
    > another process could create or remove the directory or 'other entry'
    > at any time.


    Would you rather have an error message like "error!" or one that's
    specific such as "error! a pipe exists with the same name!" vs.
    "error! the directory exists but isn't writable by the current
    effective user!"? Also, you really can't rectify the problem
    automatically without the check unless you want to blindly throw
    around 'remove', 'chmod' and 'mkdir'. Your philosophy of "hey,
    someone else might f* it up anyway" isn't good justification for not
    basing all code on sound principles.
    Kevin P. Barry

  11. Re: How to check the status of a directory in C under Unix?

    On Aug 22, 11:25 am, ta0k...@yahoo.com wrote:
    > On Aug 22, 4:56 am, Rainer Weikusat wrote:
    >
    > > These types of checks are generally of dubious usefulness, because
    > > another process could create or remove the directory or 'other entry'
    > > at any time.

    >
    > Would you rather have an error message like "error!" or one that's
    > specific such as "error! a pipe exists with the same name!" vs.
    > "error! the directory exists but isn't writable by the current
    > effective user!"? Also, you really can't rectify the problem
    > automatically without the check unless you want to blindly throw
    > around 'remove', 'chmod' and 'mkdir'. Your philosophy of "hey,
    > someone else might f* it up anyway" isn't good justification for not
    > basing all code on sound principles.
    > Kevin P. Barry


    On the other hand, it seems to make more sense to first just try what
    you want to do, and only do further investigation or correction (if
    appropriate) after it fails. If mkdir/open/whatever succeeds, which
    it will 99% of the time, then the stat() was useless. You might as
    well optimize for the non-error case.

    I dispute that "sound principles" require you to stat() a directory
    before attempting to create it. And actually, I would prefer to have
    an application just use perror() to tell me "/tmp/foo: File exists
    (EEXIST)" than some custom error message about whether it's a pipe or
    a socket or what have you. The former message, I know the situations
    that cause it to occur, and I can figure out for myself which one it
    is, and what I want to do about it. In the latter case, I have to
    read the program's custom message and figure out what it really
    means. More often than not, some random programmer's "friendly" error
    messages are incorrect, because they were thinking of a different
    error case than the one that occurred.

  12. Re: How to check the status of a directory in C under Unix?

    On Aug 22, 7:36 pm, fjbl...@yahoo.com wrote:

    > On the other hand, it seems to make more sense to first just try what
    > you want to do, and only do further investigation or correction (if
    > appropriate) after it fails. If mkdir/open/whatever succeeds, which
    > it will 99% of the time, then the stat() was useless. You might as
    > well optimize for the non-error case.


    An operation without a complex effect on speed such as 'stat' (outside
    of a loop or recursion) is hardly worth optimizing out, especially
    since the time it takes to 'stat' is negligible compared to hardware-
    related variations in other operations. In any case, I like seeing a
    specific error message when debugging and developing, especially if
    I'm doing several back-to-back runs or if I'm sifting through a log
    file after the fact.

    > I dispute that "sound principles" require you to stat() a directory
    > before attempting to create it. And actually, I would prefer to have
    > an application just use perror() to tell me "/tmp/foo: File exists
    > (EEXIST)" than some custom error message about whether it's a pipe or
    > a socket or what have you. The former message, I know the situations
    > that cause it to occur, and I can figure out for myself which one it
    > is, and what I want to do about it. In the latter case, I have to
    > read the program's custom message and figure out what it really
    > means. More often than not, some random programmer's "friendly" error
    > messages are incorrect, because they were thinking of a different
    > error case than the one that occurred.


    Those inaccurate "friendly" messages you're talking about tend to be a
    failure to *obtain* specific information, yet still providing specific
    information in the error message. I'm pretty sure if I 'stat' and
    'S_ISSOCK' is non-zero then I can safely say that the name is
    currently taken by a socket, and the user doesn't have to go check.
    You incorrectly assume that it's always *simple* to check for the
    specific problem. Inability to create a directory isn't always a
    fatal error, and not everyone executes programs from an X terminal;
    therefore, it's very possible that the program will retain control of
    the terminal and *not* terminate, leaving the user to defer to to
    another terminal; not always a trivial thing to do. And as far as I
    know, 1% of the time is generally worth taking into account. 1%
    laziness 100 times makes for one pain-in-the-ass program, which
    strikes me as the opposite of a sound principle.
    Kevin P. Barry

  13. Re: How to check the status of a directory in C under Unix?

    ta0kira@yahoo.com writes:
    > On Aug 22, 4:56 am, Rainer Weikusat wrote:
    >
    >> These types of checks are generally of dubious usefulness, because
    >> another process could create or remove the directory or 'other entry'
    >> at any time.

    >
    > Would you rather have an error message like "error!" or one that's
    > specific such as "error! a pipe exists with the same name!" vs.
    > "error! the directory exists but isn't writable by the current
    > effective user!"?


    I would rather have a correct error message. And except if you
    completely control the system (which is possible), the message from
    'stat' may or may not be correct and the program cannot decide if the
    result of the call has any meaning.

    > Also, you really can't rectify the problem
    > automatically without the check unless you want to blindly throw
    > around 'remove', 'chmod' and 'mkdir'.
    > Your philosophy of "hey, someone else might f* it up anyway" isn't
    > good justification for not basing all code on sound principles.


    That's not a 'philosophy' of mine, but a fact: The filesystem is a
    shared ressource used by all processes running on a system and this
    means that a single application with no knowledge of other activities
    which may be going on at the same time cannot predict what other
    processes may create which directory entries for what purpose at any
    particular time. And 'writing known-to-be-defective code' is not 'a
    sound principle' (except maybe a philosophical one :->). In this
    particular case, the program should try to create the directory, but
    without looking at the return code and then to chdir into it. If this
    succeeds, the directory exists and it won't suddenly go away for as
    long as it is the cwd of the process (it may change its name,
    though). Then, the file can be created. Otherwise, there is an error
    from the chdir call to print, presumably, ENOTDIR. Anything beyond
    that requires either human intervention or proactive guesses made by
    the code author, which may or may not be correct (and will require
    more complicated human intervention when they are not).

    My personal opinion on this is that the guesses should rather be
    avoided because I consider a program which fails in a controlled way
    more desirable than one which 'just does something' with unpredictable
    side effects.

  14. Re: How to check the status of a directory in C under Unix?

    ta0kira@yahoo.com writes:
    > On Aug 22, 7:36 pm, fjbl...@yahoo.com wrote:
    >> On the other hand, it seems to make more sense to first just try what
    >> you want to do, and only do further investigation or correction (if
    >> appropriate) after it fails. If mkdir/open/whatever succeeds, which
    >> it will 99% of the time, then the stat() was useless. You might as
    >> well optimize for the non-error case.

    >
    > An operation without a complex effect on speed such as 'stat' (outside
    > of a loop or recursion) is hardly worth optimizing out,


    No single, useless operation of any program will be worth 'optimizing
    out' (which is technically nonsense here, 'not coding in' would be
    accurate). It is possible to prick someone with needles until he dies.

    [...]

    >> I dispute that "sound principles" require you to stat() a directory
    >> before attempting to create it. And actually, I would prefer to have
    >> an application just use perror() to tell me "/tmp/foo: File exists
    >> (EEXIST)" than some custom error message about whether it's a pipe or
    >> a socket or what have you. The former message, I know the situations
    >> that cause it to occur, and I can figure out for myself which one it
    >> is, and what I want to do about it. In the latter case, I have to
    >> read the program's custom message and figure out what it really
    >> means. More often than not, some random programmer's "friendly" error
    >> messages are incorrect, because they were thinking of a different
    >> error case than the one that occurred.

    >
    > Those inaccurate "friendly" messages you're talking about tend to be a
    > failure to *obtain* specific information, yet still providing specific
    > information in the error message. I'm pretty sure if I 'stat' and
    > 'S_ISSOCK' is non-zero then I can safely say that the name is
    > currently taken by a socket, and the user doesn't have to go check.


    The program can safely conclude that the name was referring to a
    socket at the time of the check and therefore, the user will have to
    check if it still does before doing anything.

  15. Re: How to check the status of a directory in C under Unix?

    Rainer Weikusat writes:

    [...]

    > In this particular case, the program should try to create the
    > directory, but without looking at the return code and then to chdir
    > into it. If this succeeds, the directory exists


    Strictly, this is wrong: The name could also have belonged to a
    symlink pointing to a directory.

  16. Re: How to check the status of a directory in C under Unix?

    ta0kira@yahoo.com wrote:
    > On Aug 22, 7:36 pm, fjbl...@yahoo.com wrote:
    >
    >> On the other hand, it seems to make more sense to first just try what
    >> you want to do, and only do further investigation or correction (if
    >> appropriate) after it fails. If mkdir/open/whatever succeeds, which
    >> it will 99% of the time, then the stat() was useless. You might as
    >> well optimize for the non-error case.

    >
    > An operation without a complex effect on speed such as 'stat' (outside
    > of a loop or recursion) is hardly worth optimizing out, especially
    > since the time it takes to 'stat' is negligible compared to hardware-
    > related variations in other operations. In any case, I like seeing a
    > specific error message when debugging and developing, especially if
    > I'm doing several back-to-back runs or if I'm sifting through a log
    > file after the fact.


    I don't think you need to defend this case. Your earlier post did say
    this check should be made "before or after". Hopefully we can all agree
    that after is better than before, since it avoids race conditions and
    performance costs - however minor - without losing anything.

    >> I dispute that "sound principles" require you to stat() a directory
    >> before attempting to create it. And actually, I would prefer to have
    >> an application just use perror() to tell me "/tmp/foo: File exists
    >> (EEXIST)" than some custom error message about whether it's a pipe or
    >> a socket or what have you. The former message, I know the situations
    >> that cause it to occur, and I can figure out for myself which one it
    >> is, and what I want to do about it. In the latter case, I have to
    >> read the program's custom message and figure out what it really
    >> means. More often than not, some random programmer's "friendly" error
    >> messages are incorrect, because they were thinking of a different
    >> error case than the one that occurred.

    >
    > Those inaccurate "friendly" messages you're talking about tend to be a
    > failure to *obtain* specific information, yet still providing specific
    > information in the error message. I'm pretty sure if I 'stat' and
    > 'S_ISSOCK' is non-zero then I can safely say that the name is
    > currently taken by a socket, and the user doesn't have to go check.
    > You incorrectly assume that it's always *simple* to check for the
    > specific problem. Inability to create a directory isn't always a
    > fatal error, and not everyone executes programs from an X terminal;
    > therefore, it's very possible that the program will retain control of
    > the terminal and *not* terminate, leaving the user to defer to to
    > another terminal; not always a trivial thing to do. And as far as I
    > know, 1% of the time is generally worth taking into account. 1%
    > laziness 100 times makes for one pain-in-the-ass program, which
    > strikes me as the opposite of a sound principle.


    I think you're missing the key principle here, and I very much agree
    with fjblurt. In the case of a *system* error, the kind that occurs in a
    system call, the *only* diagnosis you can believe is that which the
    system gives you. And all the information the kernel gives you is
    generally wrapped up in errno and its string version in strerror().
    Anything added to that can only be blather. My conventional message for
    system errors is basically:

    fprintf(stderr, "%s: Error: %s: %s\n",
    program_name, file_name, strerror(errno));

    Because nothing useful _can_ be added. You see some cases, Microsoft
    being a good example, where an edict apparently came down from on high
    saying "we need more user-friendly error messages" which results in a
    lot of droning about "the system could not open the file specified" or
    "The application was unable to be run. You may be low on memory. Try
    killing some processes and trying again". These add zero value and in
    the latter case can do active harm.

    IN the case of mkdir the system can tell you if something resided at the
    same path, or if directory permissions prevented it, or if it was low
    memory, or not enough inodes, etc. As for whether the thing at that path
    was another directory or a named pipe, (a) it doesn't generally matter
    to the user and (b) it could be a different thing by the time you cehck
    later.

    For better or worse, attempts to improve on what the system tells you
    are doomed to add no value.

    HS

  17. Re: How to check the status of a directory in C under Unix?

    On Aug 23, 4:19 am, Rainer Weikusat wrote:

    > No single, useless operation of any program will be worth 'optimizing
    > out' (which is technically nonsense here, 'not coding in' would be
    > accurate). It is possible to prick someone with needles until he dies.


    Which applies when one does something unnecessary within a highly-
    iterated loop or in a recursive function, but we seem to have agreed
    that this, whether useful or not, constitutes a *single* pin prick.
    Kevin P. Barry

  18. Re: How to check the status of a directory in C under Unix?

    On Aug 23, 4:16 am, Rainer Weikusat wrote:

    > That's not a 'philosophy' of mine, but a fact: The filesystem is a
    > shared ressource used by all processes running on a system and this
    > means that a single application with no knowledge of other activities
    > which may be going on at the same time cannot predict what other
    > processes may create which directory entries for what purpose at any
    > particular time. And 'writing known-to-be-defective code' is not 'a
    > sound principle' (except maybe a philosophical one :->). In this
    > particular case, the program should try to create the directory, but
    > without looking at the return code and then to chdir into it. If this
    > succeeds, the directory exists and it won't suddenly go away for as
    > long as it is the cwd of the process (it may change its name,
    > though). Then, the file can be created. Otherwise, there is an error
    > from the chdir call to print, presumably, ENOTDIR. Anything beyond
    > that requires either human intervention or proactive guesses made by
    > the code author, which may or may not be correct (and will require
    > more complicated human intervention when they are not).


    What about using 'stat' to check for more specific information
    regarding a failure is defective? You seem to forget that 'stat' is
    just as much of a system call as 'mkdir' is, and though wrapped by
    libc, the information comes straight from the file system via the same
    section of kernel code you trust to execute 'mkdir' (as in the file
    system driver itself.)

    "Known to be defective" to me would be trying to 'chdir' to something
    that may or may not be a directory. And 'chdir' *does not* always
    prevent the directory from being removed, though it should prevent the
    file system from being unmounted.

    Anything that can happen between 'stat' and anything that relies on it
    can happen at any time to any other program, but it's "proper" to
    attempt to mitigate as much as possible with the obvious caveat that
    other poorly-designed code might interfere in ways that can't be
    controlled, nor accounted for.
    Kevin P. Barry

  19. Re: How to check the status of a directory in C under Unix?

    ta0kira@yahoo.com writes:
    > On Aug 23, 4:16 am, Rainer Weikusat wrote:
    >> That's not a 'philosophy' of mine, but a fact: The filesystem is a
    >> shared ressource used by all processes running on a system and this
    >> means that a single application with no knowledge of other activities
    >> which may be going on at the same time cannot predict what other
    >> processes may create which directory entries for what purpose at any
    >> particular time. And 'writing known-to-be-defective code' is not 'a
    >> sound principle' (except maybe a philosophical one :->). In this
    >> particular case, the program should try to create the directory, but
    >> without looking at the return code and then to chdir into it. If this
    >> succeeds, the directory exists and it won't suddenly go away for as
    >> long as it is the cwd of the process (it may change its name,
    >> though). Then, the file can be created. Otherwise, there is an error
    >> from the chdir call to print, presumably, ENOTDIR. Anything beyond
    >> that requires either human intervention or proactive guesses made by
    >> the code author, which may or may not be correct (and will require
    >> more complicated human intervention when they are not).

    >
    > What about using 'stat' to check for more specific information
    > regarding a failure is defective? You seem to forget that 'stat' is
    > just as much of a system call as 'mkdir' is, and though wrapped by
    > libc, the information comes straight from the file system via the same
    > section of kernel code you trust to execute 'mkdir' (as in the file
    > system driver itself.)


    The problem is that this information is an anecdote: Story from the
    past with some probability of having been true.

    > "Known to be defective" to me would be trying to 'chdir' to something
    > that may or may not be a directory.


    This would be any use of any filesystem name. Which doesn't make too
    much sense. These calls return errors for a reason.

    > And 'chdir' *does not* always prevent the directory from being
    > removed,


    'chdir' never prevents that. The fact that some process has a
    particular current working directory (which may or may not be
    associated with any particular filesystem name) prevents this
    directory, which isn't name, from being removed.

    > Anything that can happen between 'stat' and anything that relies on it
    > can happen at any time to any other program, but


    The outcome concurrent access to shared resources without locking
    depends on what is called 'a race condition': It is coincidence which
    of the accesses (or combinations of them) will determine the actual
    efffect. You don't need multi-threading for that.


  20. Re: How to check the status of a directory in C under Unix?

    ta0kira@yahoo.com writes:
    > On Aug 23, 4:19 am, Rainer Weikusat wrote:
    >> No single, useless operation of any program will be worth 'optimizing
    >> out' (which is technically nonsense here, 'not coding in' would be
    >> accurate). It is possible to prick someone with needles until he dies.

    >
    > Which applies when one does something unnecessary within a highly-
    > iterated loop or in a recursive function, but we seem to have agreed
    > that this, whether useful or not, constitutes a *single* pin prick.


    Eh ... yes. I would even agree that the 'optimize' argument is moot:
    Assuming stat is called after a failure in order to provide more
    details in an error message, there is (usually) no reason to care for
    the time it takes to execute this call: Assuming the program is going
    to terminate RSN anyway, another system call hardly matters. But
    nevertheless, that something causes only an insigifcant damage when
    viewed in isolation is no argument in favor of it.

+ Reply to Thread