Removing a file in C

[Kuhl]

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.

 

[Joachim Schmitz]

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]

Joachim Schmitz said:


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

 

[Stephen Sprunk]

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

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

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

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

 

[Keith Thompson]

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

 

[Stephen Sprunk]

<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

 

[Richard Tobin]

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

 

[Stephen Sprunk]

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

 

[Antoninus Twink]

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.

 

[Keith Thompson]

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

 

[jacob navia]

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.

 

[Keith Thompson]

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

 

[Richard Tobin]

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

 

[Flash Gordon]

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

 

[Antoninus Twink]

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]

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.

 

[CBFalconer]

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.

 

[William Hughes]

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

 

[Stephen Sprunk]

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]

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