[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.c

file descriptor

Wang WolfLouis

8/24/2011 2:27:00 AM

hi all,
I have a question about file descriptor. consider this
situation, one process wirte a log file using vfprintf function,
sometimes I deleted this log file on the disk. The process seams hold
the same log file file descriptor as before, notheing error message
print.
As I know process treat the log file as COPY-ON-WRITE
technique, however, if the file descriptor does not exist,
vfprintf function should print some error message. So, should access
file every time if want to write contents ?
6 Answers

James Kuyper

8/24/2011 2:42:00 AM

0

On 08/23/2011 10:26 PM, Wang WolfLouis wrote:
> hi all,
> I have a question about file descriptor. consider this
> situation, one process wirte a log file using vfprintf function,
> sometimes I deleted this log file on the disk. The process seams hold
> the same log file file descriptor as before, notheing error message
> print.
> As I know process treat the log file as COPY-ON-WRITE
> technique, however, if the file descriptor does not exist,
> vfprintf function should print some error message. So, should access
> file every time if want to write contents ?

The C standard doesn't cover such issues; it depends mainly upon the
operating system, and you haven't specified which one you're using.

On some operating systems, the fact that a process has deleted a file
just means it can no longer be accessed by name, it can still be
accessed by any process that had already opened it before the deletion,
and had not yet closed it. In particular, it's not an error to try to
write to the file. The space set aside for the file won't be reclaimed
for other uses until all such processes have closed the file. That would
be consistent with the symptoms you've seen.
--
James Kuyper

Keith Thompson

8/24/2011 3:03:00 AM

0

Wang WolfLouis <wolflouiswang@gmail.com> writes:
> I have a question about file descriptor. consider this
> situation, one process wirte a log file using vfprintf function,
> sometimes I deleted this log file on the disk. The process seams hold
> the same log file file descriptor as before, notheing error message
> print.
> As I know process treat the log file as COPY-ON-WRITE
> technique, however, if the file descriptor does not exist,
> vfprintf function should print some error message. So, should access
> file every time if want to write contents ?

The behavior you're seeing is specific to Unix-like systems, not to C.
Try asking in comp.unix.programmer. (I don't think the concept of
copy-on-write applies here.)

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.ne...
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Joe Pfeiffer

8/24/2011 3:42:00 AM

0

Wang WolfLouis <wolflouiswang@gmail.com> writes:

> hi all,
> I have a question about file descriptor. consider this
> situation, one process wirte a log file using vfprintf function,
> sometimes I deleted this log file on the disk. The process seams hold
> the same log file file descriptor as before, notheing error message
> print.
> As I know process treat the log file as COPY-ON-WRITE
> technique, however, if the file descriptor does not exist,
> vfprintf function should print some error message. So, should access
> file every time if want to write contents ?

This isn't a C question, it's an OS question.

In the case of Unix-derived operating systems (and all filesystems I'm
familiar with, but at this point I'm sure there are more that I've never
heard of than the number I'm familiar with), a file isn't actually
deleted until there is nothing left anywhere the system that has a
link to it. So... when you open a file and get a file descriptor
to it, there is no way to actually delete it until that program closes
it (which may happen explicitly, or may happen implicitly when the
program terminates).

In the situation you're describing, you'll also notice that no
additional filesystem space opened up when you deleted the file. That's
because you deleted a link to it, but the program still had a link.

Wang WolfLouis

8/24/2011 3:43:00 AM

0

On Aug 24, 11:02 am, Keith Thompson <ks...@mib.org> wrote:
> Wang WolfLouis <wolflouisw...@gmail.com> writes:
> >          I have a question about file descriptor. consider this
> > situation, one process wirte a log file using vfprintf function,
> > sometimes I deleted this log file on the disk. The process seams hold
> > the same log file file descriptor as before, notheing error message
> > print.
> >         As I know process treat the log file as COPY-ON-WRITE
> > technique, however, if the file descriptor does not exist,
> >  vfprintf function should print some error message. So, should access
> > file every time if want to write contents ?
>
> The behavior you're seeing is specific to Unix-like systems, not to C.
> Try asking in comp.unix.programmer.  (I don't think the concept of
> copy-on-write applies here.)
>
> --
> Keith Thompson (The_Other_Keith) ks...@mib.org  <http://www.ghoti.ne...
> Nokia
> "We must do something.  This is something.  Therefore, we must do this."
>     -- Antony Jay and Jonathan Lynn, "Yes Minister"

I got it, file descriptor and process is realted to the implement of
operating system,
different one have different results. Yes, I am programming under Unix-
like system,

process file descriptor is just point to real file device, so multiply
process can access
same file, no copy-on-write,
thanks

John Doe

8/24/2011 5:06:00 AM

0

On Tue, 23 Aug 2011 19:26:51 -0700, Wang WolfLouis wrote:

> I have a question about file descriptor. consider this
> situation, one process wirte a log file using vfprintf function,
> sometimes I deleted this log file on the disk.

Misconception. On Unix, you don't "delete" files, you "unlink" them. This
removes a specific filename from a specific directory. The files
themselves are reference-counted. A file is deleted by the kernel once its
link count reaches zero and no process has it open.

If the link count reaches zero but some process has it open, the file
still exists on disk, but it can no longer be open()ed.

[On Linux, if you list the /proc/<pid>/fd directory for the process, the
file will be listed with " (deleted)" after its name.]

Windows is different; it won't allow you to delete, move or rename a file
(or directory) while any process has it open. This is one reason why
installers often tell you to close any applications before continuing;
they can't replace files (e.g. to update system DLLs) if those files are
in use. Updating particularly important DLLs requires a reboot, as that's
the only practical way to terminate "system" processes which may be using
those DLLs.

> The process seams hold the same log file file descriptor as before,
> notheing error message print.

Correct. There is no error here.

> As I know process treat the log file as COPY-ON-WRITE
> technique,

Copy-on-write isn't related to this.

> however, if the file descriptor does not exist,
> vfprintf function should print some error message. So, should access
> file every time if want to write contents ?

There is no error. The file still exists, it's still open. If you have
opened the file for read-write, you will be able to rewind the file
pointer with lseek() and read what you had written. Similarly, any
child processes which are created will inherit the descriptor.

For temporary files, it's quite common to unlink() them as soon as they
are created. This ensures that the file will automatically be deleted if
the process terminates unexpectedly (e.g. crashes).

Roberto Waltman

8/24/2011 2:58:00 PM

0

Wang WolfLouis wrote:
>
>> I have a question about file descriptor. consider this
>> situation, one process wirte a log file using vfprintf function,
>> sometimes I deleted this log file on the disk.

To summarize what others wrote, in most systems, the concepts of
"directory entry" and "file" are two very different things. (Not true
for CP/M, where the list of blocks allocated to a file was stored in
the directory. MS FAT systems need info from the directory entry to
locate the beginning of th file in the FAT.)

Some operating systems allow creating and using temporary files
without ever creating a name or directory entry for them. (VAX/VMS for
example)

The fact that, in Unix like systems, a file is not really deleted
until nobody is using it or referring to it, helps occasionally to
recover files that were deleted accidentally.
In your example, if you delete (unlink) and then want to restore that
log file (knowing that at least on process is still using it,) you can
get information on the file using the lsof command (Linux) and then
create a link to it using the inode number (the one thing that
identifies the file)
--
Roberto Waltman

[ Please reply to the group.
Return address is invalid ]