Removing a file in C

Discussion in 'C Programming' started by Kuhl, Apr 7, 2009.

  1. Kuhl

    Kuhl Guest

    Hi, I am writing Linux C program. How to remove a file with C command?
    My book only shows how to remove a hard link or a directory.

    Remove a hard link:

    #include <unistd.h>
    .... ...
    int unlink(const char *pathname);
    .... ...
    if(unlink("test2.txt")==-1){
    ....
    }

    Remove a directory:

    #include <unistd.h>
    .... ...
    int rmdir(const char *pathname);
    ....

    My questions:

    (1) It does not describe how to remove a regular file. How to do that?
    (2) Both removing a hard link and removing a directory has the inputs
    of (const char *pathname). Why it's const?

    Thank you in advance.
     
    Kuhl, Apr 7, 2009
    #1
    1. Advertising

  2. Kuhl wrote:
    > Hi, I am writing Linux C program. How to remove a file with C command?
    > My book only shows how to remove a hard link or a directory.
    >
    > Remove a hard link:
    >
    > #include <unistd.h>
    > ... ...
    > int unlink(const char *pathname);


    This is a POSIX API, not Standard C, hence topical in comp.unix.programmer,
    not here. remove() is Standard C, topical here and does the about same
    thing.
    It removes a file, in UNIX a file is deleted whan it's last hardlink is gone
    (unlinked).

    7.19.4.1:
    Synopsis

    1 #include <stdio.h>

    int remove(const char *filename);

    Description

    2 The remove function causes the file whose name is the string pointed to by
    filename

    to be no longer accessible by that name. A subsequent attempt to open that
    file using that

    name will fail, unless it is created anew. If the file is open, the behavior
    of the remove

    function is implementation-defined.

    function is implementation-defined.


    > ... ...
    > if(unlink("test2.txt")==-1){
    > ...
    > }
    >
    > Remove a directory:
    >
    > #include <unistd.h>
    > ... ...
    > int rmdir(const char *pathname);
    > ...


    There's no rmdir in Standard C, but in POSIX, see above. Only this time
    there's no Standard C equivalent...

    > My questions:
    >
    > (1) It does not describe how to remove a regular file. How to do that?


    By unlinking all it's hardlinks

    > (2) Both removing a hard link and removing a directory has the inputs
    > of (const char *pathname). Why it's const?


    This promises you (and your compiler) that these functions don't modify the
    pointer you pass it.

    Bye, Jojo
     
    Joachim Schmitz, Apr 7, 2009
    #2
    1. Advertising

  3. Richard Heathfield wrote:
    > Joachim Schmitz said:
    >
    >> Kuhl wrote:

    > <snip>
    >
    >>> (2) Both removing a hard link and removing a directory has the
    >>> inputs of (const char *pathname). Why it's const?

    >>
    >> This promises you (and your compiler) that these functions don't
    >> modify the pointer you pass it.

    >
    > Close, but no banana. The pointer you pass is a *value*, and it's
    > copied into a local object in the called function, and nobody cares
    > two hoots whether the called function modifies it.
    >
    > The promise is that the /string/ will not be modified.


    I knew I'd screw this up. Thanks for the correction.

    Bye, Jojo
     
    Joachim Schmitz, Apr 7, 2009
    #3
  4. Kuhl wrote:
    > Hi, I am writing Linux C program. How to remove a file with C command?


    The Standard C function to remove a file is, not surprisingly, called
    remove(). Be sure to #include <stdio.h>.

    > My book only shows how to remove a hard link or a directory.


    Get a better book, e.g. K&R2.

    <OT>
    > Remove a hard link:
    >
    > #include <unistd.h>
    > ... ...
    > int unlink(const char *pathname);
    > ... ...
    > if(unlink("test2.txt")==-1){
    > ...
    > }


    In POSIX, a file is represented by an inode, and a file name aka "hard
    link" is a directory entry that points to the inode. There may be zero
    or more hard links to an inode. When there are no hard links to an
    inode, and no process has an open descriptor for the inode, the inode
    and associated file cease to exist, i.e. it is deleted.

    (This is often abused in interesting ways; you can create a file, open
    it, unlink it, and the result is a file that nobody else can see which
    will be automatically erased when your program exits -- unless you do
    something tricky like pass the fd to another process via IPC.)

    You will most likely find that, on any POSIX system, remove() simply
    calls unlink().

    > Remove a directory:
    >
    > #include <unistd.h>
    > ... ...
    > int rmdir(const char *pathname);
    > ...


    In POSIX, a directory is just a special file that contains pointers to
    other files or directories. rmdir() most likely recursively unlinks the
    contents of the specified directory, then the directory itself.

    > My questions:
    >
    > (1) It does not describe how to remove a regular file. How to do that?


    See above. A "regular file" is a hard link.

    > (2) Both removing a hard link and removing a directory has the inputs
    > of (const char *pathname). Why it's const?


    They're const because they don't change the string pointed to by pathname.

    </OT>

    S

    --
    Stephen Sprunk "Stupid people surround themselves with smart
    CCIE #3723 people. Smart people surround themselves with
    K5SSS smart people who disagree with them." --Isaac Jaffe
     
    Stephen Sprunk, Apr 7, 2009
    #4
  5. Stephen Sprunk <> writes:
    > <OT>

    [POSIX-specific stuff deleted]
    > </OT>


    I saw at least three minor errors in Stephen's followup -- which is
    why redirecting the discussion to comp.unix.programmer is better than
    trying to answer it here. I'd be more specific but (a) if I did so it
    would inevitably spawn a long off-topic thread, and (b) I could easily
    be mistaken myself.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Apr 7, 2009
    #5
  6. Keith Thompson wrote:
    > Stephen Sprunk <> writes:
    >> <OT>

    > [POSIX-specific stuff deleted]
    >> </OT>

    >
    > I saw at least three minor errors in Stephen's followup -- which is
    > why redirecting the discussion to comp.unix.programmer is better than
    > trying to answer it here. I'd be more specific but (a) if I did so it
    > would inevitably spawn a long off-topic thread, and (b) I could easily
    > be mistaken myself.


    I'm curious what "minor errors" you think you found in my response.

    S


    --
    Stephen Sprunk "Stupid people surround themselves with smart
    CCIE #3723 people. Smart people surround themselves with
    K5SSS smart people who disagree with them." --Isaac Jaffe
     
    Stephen Sprunk, Apr 7, 2009
    #6
  7. In article <kqJCl.26022$>,
    Stephen Sprunk <> wrote:

    >In POSIX, a file is represented by an inode, and a file name aka "hard
    >link" is a directory entry that points to the inode. There may be zero
    >or more hard links to an inode. When there are no hard links to an
    >inode, and no process has an open descriptor for the inode, the inode
    >and associated file cease to exist, i.e. it is deleted.


    >(This is often abused in interesting ways; you can create a file, open
    >it, unlink it, and the result is a file that nobody else can see which
    >will be automatically erased when your program exits -- unless you do
    >something tricky like pass the fd to another process via IPC.)


    Why do you describe this as "abuse"? Surely it is an intended use.

    -- Richard
    --
    Please remember to mention me / in tapes you leave behind.
     
    Richard Tobin, Apr 7, 2009
    #7
  8. Richard Tobin wrote:
    > In article <kqJCl.26022$>,
    > Stephen Sprunk <> wrote:
    >
    >> In POSIX, a file is represented by an inode, and a file name aka "hard
    >> link" is a directory entry that points to the inode. There may be zero
    >> or more hard links to an inode. When there are no hard links to an
    >> inode, and no process has an open descriptor for the inode, the inode
    >> and associated file cease to exist, i.e. it is deleted.

    >
    >> (This is often abused in interesting ways; you can create a file, open
    >> it, unlink it, and the result is a file that nobody else can see which
    >> will be automatically erased when your program exits -- unless you do
    >> something tricky like pass the fd to another process via IPC.)

    >
    > Why do you describe this as "abuse"? Surely it is an intended use.


    I'm certainly that it was intended that, if one process unlinked a file
    that another was still using, the file would continue to exist until the
    second process closed it. Ditto for renaming a file, moving it,
    changing its permissions, etc.

    I have trouble believing that it was originally intended that a process
    would deliberately unlink its own files to keep other processes from
    being able to see/manipulate them, though that capability (and having
    those temporary files automatically garbage-collected) is the logical
    result. The myriad ways this can be complicated by passing an fd for
    such a file via IPC were certainly not intended, but were again logical
    results.

    S

    --
    Stephen Sprunk "Stupid people surround themselves with smart
    CCIE #3723 people. Smart people surround themselves with
    K5SSS smart people who disagree with them." --Isaac Jaffe
     
    Stephen Sprunk, Apr 7, 2009
    #8
  9. On 7 Apr 2009 at 17:12, Stephen Sprunk wrote:
    > Keith Thompson wrote:
    >> I'd be more specific but (a) if I did so it would inevitably spawn a
    >> long off-topic thread, and (b) I could easily be mistaken myself.

    >
    > I'm curious what "minor errors" you think you found in my response.


    Keith is using you as a pawn in his topicality games - it's not worth
    rising to the bait.

    Several times people have claimed there are errors in replies of mine,
    but that they won't tell me what because they think it's "off topic".
    Never once have they then come out and stated their points openly -
    maybe the supposed errors are just moonshine, or maybe there really was
    something that I and others could learn from. If so, too bad - there's
    no chance of finding out (because they're playing their silly little
    points-scoring game), so there's no point thinking about it.
     
    Antoninus Twink, Apr 7, 2009
    #9
  10. jacob navia <> writes:
    [...]
    > Yes. The same tactics have been used against me.
    > "There is an error but I will not tell you what is that error"
    >
    > Just empty talk.


    When I point out your errors, you tend to take it as a personal attack
    anyway.

    But I don't recall ever telling you "There is an error but I will not
    tell you what is that error". If I did, it was probably for the same
    reason as in this thread, just trying to avoid a lengthy off-topic
    discussion.

    But if you can point me to a specific case where I've told you this,
    I'll be glad to go into more detail in e-mail (or here if it's
    relevant to the topic of this newsgroup).

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Apr 7, 2009
    #10
  11. Kuhl

    jacob navia Guest

    Antoninus Twink wrote:
    > On 7 Apr 2009 at 17:12, Stephen Sprunk wrote:
    >> Keith Thompson wrote:
    >>> I'd be more specific but (a) if I did so it would inevitably spawn a
    >>> long off-topic thread, and (b) I could easily be mistaken myself.

    >> I'm curious what "minor errors" you think you found in my response.

    >
    > Keith is using you as a pawn in his topicality games - it's not worth
    > rising to the bait.
    >
    > Several times people have claimed there are errors in replies of mine,
    > but that they won't tell me what because they think it's "off topic".
    > Never once have they then come out and stated their points openly -
    > maybe the supposed errors are just moonshine, or maybe there really was
    > something that I and others could learn from. If so, too bad - there's
    > no chance of finding out (because they're playing their silly little
    > points-scoring game), so there's no point thinking about it.
    >


    Yes. The same tactics have been used against me.
    "There is an error but I will not tell you what is that error"

    Just empty talk.

    --
    jacob navia
    jacob at jacob point remcomp point fr
    logiciels/informatique
    http://www.cs.virginia.edu/~lcc-win32
     
    jacob navia, Apr 7, 2009
    #11
  12. Stephen Sprunk <> writes:
    > Keith Thompson wrote:
    >> Stephen Sprunk <> writes:
    >>> <OT>

    >> [POSIX-specific stuff deleted]
    >>> </OT>

    >>
    >> I saw at least three minor errors in Stephen's followup -- which is
    >> why redirecting the discussion to comp.unix.programmer is better than
    >> trying to answer it here. I'd be more specific but (a) if I did so it
    >> would inevitably spawn a long off-topic thread, and (b) I could easily
    >> be mistaken myself.

    >
    > I'm curious what "minor errors" you think you found in my response.


    I've replied by e-mail. (Incidentally, Stephen told me that he
    intended the above followup to be a private e-mail reply.)

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Apr 7, 2009
    #12
  13. In article <7xMCl.11713$>,
    Stephen Sprunk <> wrote:

    >I have trouble believing that it was originally intended that a process
    >would deliberately unlink its own files to keep other processes from
    >being able to see/manipulate them


    But that - temporary files for use by a single process - is a standard
    feature provided by any reasonable operating system. Some operating
    systems have system calls specifically for creating unnamed temporary
    files; it's an elegant feature of unix that it doesn't need any
    separate mechanism.

    The following is from "Unix Implementation" (Thompson, 1978):

    Reference counts are kept on the open file table entries and the
    i-node table entries to free these structures after the last reference
    goes away. unlink simply decrements the count of the number of
    directories pointing at the given i-node. When the last reference to
    an i-node table entry goes away, if the i-node has no directories
    pointing to it, then the file is removed and the i-node is freed. This
    delayed removal of files prevents problems arising from removing
    active files. A file may be removed while still open. The resulting
    unnamed file vanishes when the file is closed. This is a method of
    obtaining temporary files.

    >The myriad ways this can be complicated by passing an fd for
    >such a file via IPC were certainly not intended, but were again logical
    >results.


    File descriptor passing was certainly a much later addition; it came
    with sockets in 4.3 BSD (or maybe 4.2c).

    -- Richard
    --
    Please remember to mention me / in tapes you leave behind.
     
    Richard Tobin, Apr 7, 2009
    #13
  14. Kuhl

    Flash Gordon Guest

    jacob navia wrote:
    > Antoninus Twink wrote:
    >> On 7 Apr 2009 at 17:12, Stephen Sprunk wrote:
    >>> Keith Thompson wrote:
    >>>> I'd be more specific but (a) if I did so it would inevitably spawn a
    >>>> long off-topic thread, and (b) I could easily be mistaken myself.
    >>> I'm curious what "minor errors" you think you found in my response.

    >>
    >> Keith is using you as a pawn in his topicality games - it's not worth
    >> rising to the bait.
    >>
    >> Several times people have claimed there are errors in replies of mine,
    >> but that they won't tell me what because they think it's "off topic".


    <snip>

    > Yes. The same tactics have been used against me.
    > "There is an error but I will not tell you what is that error"
    >
    > Just empty talk.


    The man pages on one of my Unix boxes (which agrees with my Linux boxes
    and my memory) state a number of things which contradict what was
    originally claimed. If you want to know what was wrong read the man
    pages or ask in comp.unix.programmer
    --
    Flash Gordon
     
    Flash Gordon, Apr 7, 2009
    #14
  15. On 7 Apr 2009 at 19:36, Richard Heathfield wrote:
    > He has in the past posted erroneous material to which I have posted
    > corrections.


    I don't remember you ever providing a valid correction to any of my
    posts.

    If I'm wrong, you'll have no trouble producing the message IDs to prove
    your assertion.

    Otherwise, let's just chalk it down to one more Heathfield lie in a vast
    sea of Heathfield lies that has nearly drowned this group over several
    years.
     
    Antoninus Twink, Apr 7, 2009
    #15
  16. On 7 Apr 2009 at 21:04, Han from China wrote:
    > One objectionable thing I saw in Stephen's post was the following:
    >
    > rmdir() most likely recursively unlinks the contents of the
    > specified directory, then the directory itself.
    >
    > On most systems, the directory must be empty.


    Quite right - good spot.

    It's good to have decent Usenet citizens (unlike Keith Thomson) who
    correct misinformation generously, instead of playing games to promote
    their own agendas.
     
    Antoninus Twink, Apr 7, 2009
    #16
  17. Kuhl

    CBFalconer Guest

    jacob navia wrote:
    > Antoninus Twink wrote:
    >> Stephen Sprunk wrote:
    >>> Keith Thompson wrote:
    >>>
    >>>> I'd be more specific but (a) if I did so it would inevitably
    >>>> spawn a long off-topic thread, and (b) I could easily be
    >>>> mistaken myself.
    >>>
    >>> I'm curious what "minor errors" you think you found in my
    >>> response.

    >>
    >> Keith is using you as a pawn in his topicality games - it's
    >> not worth rising to the bait.
    >>
    >> Several times people have claimed there are errors in replies
    >> of mine, but that they won't tell me what because they think
    >> it's "off topic". Never once have they then come out and
    >> stated their points openly - maybe the supposed errors are
    >> just moonshine, or maybe there really was something that I
    >> and others could learn from. If so, too bad - there's no
    >> chance of finding out (because they're playing their silly
    >> little points-scoring game), so there's no point thinking
    >> about it.

    >
    > Yes. The same tactics have been used against me. "There is
    > an error but I will not tell you what is that error"
    >
    > Just empty talk.


    This is so wrong that it requires a reply. First, Keith gave a
    perfectly good reason for not responding to the "minor errors" on
    c.l.c. Note that the Twinkletroll simply ignored that
    explanation. Second, you are responding to a troll, and expanding
    on the trolls error. There are no tactics being used against
    anyone, except Twinkletrolls attempt to disrupt c.l.c. Correction,
    by your faulty response you are also attempting to disrupt c.l.c.

    --
    [mail]: Chuck F (cbfalconer at maineline dot net)
    [page]: <http://cbfalconer.home.att.net>
    Try the download section.
     
    CBFalconer, Apr 8, 2009
    #17
  18. On Apr 7, 2:00 pm, Stephen Sprunk <> wrote:
    > Richard Tobin wrote:
    > > In article <kqJCl.26022$>,
    > > Stephen Sprunk <> wrote:

    >
    > >> In POSIX, a file is represented by an inode, and a file name aka "hard
    > >> link" is a directory entry that points to the inode. There may be zero
    > >> or more hard links to an inode. When there are no hard links to an
    > >> inode, and no process has an open descriptor for the inode, the inode
    > >> and associated file cease to exist, i.e. it is deleted.

    >
    > >> (This is often abused in interesting ways; you can create a file, open
    > >> it, unlink it, and the result is a file that nobody else can see which
    > >> will be automatically erased when your program exits -- unless you do
    > >> something tricky like pass the fd to another process via IPC.)

    >
    > > Why do you describe this as "abuse"? Surely it is an intended use.

    >
    > I'm certainly that it was intended that, if one process unlinked a file
    > that another was still using, the file would continue to exist until the
    > second process closed it. Ditto for renaming a file, moving it,
    > changing its permissions, etc.
    >
    > I have trouble believing that it was originally intended that a process
    > would deliberately unlink its own files to keep other processes from
    > being able to see/manipulate them, though that capability (and having
    > those temporary files automatically garbage-collected) is the logical
    > result. The myriad ways this can be complicated by passing an fd for
    > such a file via IPC were certainly not intended, but were again logical
    > results.
    >


    Well, abuse is an irregular verb

    I use the language in novel ways
    You use questionable coding practices
    He abuses the language

    You seem to be using the defintion "using a feature for some other
    purpose than the designed purpose is abuse of the feature".
    While I would agree with you as to the probable rational for
    the behviour of unix when unlinking an open file, I would not
    characterize
    a process opening a temporary file then unliking it as abuse.
    I would only talk about abuse if there was another more
    direct and obvious way of getting the same result (E.g. the use
    of bit shift operators to perform multiplication is an abuse
    (There is an awful lot of abuse performed in the name of efficiency.
    In some cases it has been known to speed up code))

    - William Hughes
     
    William Hughes, Apr 8, 2009
    #18
  19. William Hughes wrote:
    > On Apr 7, 2:00 pm, Stephen Sprunk <> wrote:
    >> Richard Tobin wrote:
    >>> In article <kqJCl.26022$>,
    >>> Stephen Sprunk <> wrote:
    >>>> (This is often abused in interesting ways; you can create a file, open
    >>>> it, unlink it, and the result is a file that nobody else can see which
    >>>> will be automatically erased when your program exits -- unless you do
    >>>> something tricky like pass the fd to another process via IPC.)
    >>>
    >>> Why do you describe this as "abuse"? Surely it is an intended use.

    >>
    >> I'm certainly that it was intended that, if one process unlinked a file
    >> that another was still using, the file would continue to exist until the
    >> second process closed it. Ditto for renaming a file, moving it,
    >> changing its permissions, etc.
    >>
    >> I have trouble believing that it was originally intended that a process
    >> would deliberately unlink its own files to keep other processes from
    >> being able to see/manipulate them, though that capability (and having
    >> those temporary files automatically garbage-collected) is the logical
    >> result. The myriad ways this can be complicated by passing an fd for
    >> such a file via IPC were certainly not intended, but were again logical
    >> results.
    >>

    >
    > Well, abuse is an irregular verb
    >
    > I use the language in novel ways
    > You use questionable coding practices
    > He abuses the language


    Sure, there's that...

    > You seem to be using the defintion "using a feature for some other
    > purpose than the designed purpose is abuse of the feature".


    I usually write it as (ab)use, but since the word was already in a
    parenthetical comment and I can never remember whether [] or () is
    correct in that instance, I left them out entirely. Sheesh.

    S

    --
    Stephen Sprunk "Stupid people surround themselves with smart
    CCIE #3723 people. Smart people surround themselves with
    K5SSS smart people who disagree with them." --Isaac Jaffe
     
    Stephen Sprunk, Apr 8, 2009
    #19
  20. Han from China wrote:
    > One objectionable thing I saw in Stephen's post was the following:
    >
    > rmdir() most likely recursively unlinks the contents of the
    > specified directory, then the directory itself.
    >
    > On most systems, the directory must be empty.


    And, if I had reflected a bit longer before hitting "Send", I would have
    remembered that as well. Oh well, if the OP wanted perfect answers he
    should have gone to the proper place (comp.unix.programmer) where
    answers would be on-topic and properly peer-reviewed. Don't order a
    steak at a seafood restaurant and expect it to be perfect.

    > As for Keith's alleged errors, I have no doubt he could point them out if
    > pressed.


    He did, privately, when asked. While I don't see what's wrong with
    correcting me here, as many others have done, he's at least consistent
    about his topicality pedantry.

    > The hint is in the phrase "minor errors". Technically, it's
    > possible to find "minor errors" in any post submitted to this newsgroup.


    True, as is regularly demonstrated in attacks on even the most pedantic
    of the regulars. However, IMHO they invite such attacks when making
    their own pedantic attacks on others.

    > Kenny has called it "infinite reducibility". The tools at one's disposal
    > include nitpicking on irrelevancies, pointing out extreme cases and
    > obscure exceptions, and distorting a poster's meaning by exploiting the
    > ambiguities that arise in natural discourse. I see a few cases open to
    > that form of attack with the inode-deletion stuff. But the easiest case to
    > demonstrate is with the sentence that occurs before the one I quoted
    > above:
    >
    > In POSIX, a directory is just a special file that contains pointers to
    > other files or directories.
    >
    > You see, you could pick the less charitable interpretation of "pointers"
    > in that sentence and distort Stephen's patently obvious meaning.
    >
    > Infinite reducibility.


    Well, at least he called them "minor", though I'd say that the first one
    above wasn't so minor -- but it is easily fixed by RTFMing.

    What annoys me here isn't the nit-picking per se, since I learn from
    that; it's the cascade of oneupmanship that ensues as each of the
    nitpickers insists on correcting (or duplicating) each others'
    corrections, completely drowning out the useful answers.

    S

    --
    Stephen Sprunk "Stupid people surround themselves with smart
    CCIE #3723 people. Smart people surround themselves with
    K5SSS smart people who disagree with them." --Isaac Jaffe
     
    Stephen Sprunk, Apr 8, 2009
    #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. Tom
    Replies:
    5
    Views:
    433
  2. Chad

    Removing \n from a file

    Chad, Nov 14, 2003, in forum: C++
    Replies:
    4
    Views:
    348
  3. bart_nessux
    Replies:
    6
    Views:
    991
    Peter Hansen
    Apr 29, 2004
  4. Replies:
    17
    Views:
    595
    Anthra Norell
    Sep 5, 2006
  5. Chris  Chiasson
    Replies:
    6
    Views:
    624
    Richard Tobin
    Nov 14, 2006
Loading...

Share This Page