[2 days left] What’s wrong with your cloud strategy? Learn why multicloud solutions matter with Nimble Storage.Register Now

x
?
Solved

Any problem with unlinking a file without closing it

Posted on 2004-09-17
7
Medium Priority
?
248 Views
Last Modified: 2010-04-15
Hi,
         Will there be any problem if a file is not closed before unlinking it.
For eg, if we have a file called myFile,

myfilePointer = fopen(myFile, ...);

/* do some read/write processing */

unlink(myFile);

Actually, this is how it is in some code and when run, found a message like "Too many open files" in the log. So i doubt its because of not closing the file though we are unlinking it.. Am I right? or is there any other reason?
0
Comment
Question by:dkamdar
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
7 Comments
 
LVL 86

Expert Comment

by:jkr
ID: 12087727
The worst thing that could happen is that 'unlink()' will fail.
0
 

Author Comment

by:dkamdar
ID: 12088074
Additional Info: I was getting an error while opening a file and the error message is as mentioned earlier "Cannot open file. Too many open files". The above pattern (i.e opening the file , and not closing it) is inside a while loop and it loops for long.
0
 
LVL 86

Accepted Solution

by:
jkr earned 2000 total points
ID: 12088312
That explains the problem. Just make it read

myfilePointer = fopen(myFile, ...);

/* do some read/write processing */

fclose(myFile);
unlink(myFile);

the number of file descriptors will be exhausted at some point, unlinking a file will not close it automatically. Closing file descriptors is not only good practise, it is a sheer *must*
0
What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

 
LVL 22

Expert Comment

by:grg99
ID: 12089161
This may be operating system dependent.  

In general, you MUST close files, otherwise they stay open and use up system resources.

It's just possible though, that in the particular OS the prorgam was written on, unlinking a file jsut happens to do an effective flcose().

That is NOT true in Windows NT or Unix, an unlinked file still exists until the last user has closed it.

I woul ddo as jkr suggests and explicitly close the file, unless there's some overwhelming reason to do otherwise.

0
 
LVL 23

Expert Comment

by:brettmjohnson
ID: 12089436
The practice of unlinking opened files is common on Unix systems.
Typically it is used for temporary [scratch] files.  The files disappear
as soon as they are closed or the process exits (even premature exits).

However, your condition seems more like a programming error, leaking
a system resource (in this case a file handle).

0
 
LVL 9

Expert Comment

by:ankuratvb
ID: 12089977
Hi,

From the man pages for unlink:
>>>
       unlink  deletes  a  name from the filesystem. If that name
       was the last link to a file and no processes have the file
       open  the  file  is  deleted and the space it was using is
       made available for reuse.

       If the name was the last link to a file but any  processes
       still have the file open the file will remain in existence
       until the last file descriptor referring to it is  closed.

       If  the  name  referred  to  a  symbolic  link the link is
       removed.
<<<

refer to your compiler's documentation for unlink().
For e.g.,my dos compiler's(turboC) help says to make sure that the file is closed before calling unlink() on it.

In your case atleast,the unlink() call does not release the file handle so close the file before unlinking it.

As grg said,this IS OS dependent.
Here's an example:
http://sources.redhat.com/ml/cygwin/2004-08/msg00222.html

Its always safer to close a file before unlinking it,otherwise you'd be relying on unlink() to release the file handle which is not a sure possibility.
0
 
LVL 7

Expert Comment

by:aib_42
ID: 12091067
I guess *nix and Windows semantics differ here. On Win*, you cannot delete (or even rename) a file that is open by a process. On *nix, you can, and the file will be removed from the filesystem (ie unlinked), but will be a valid "storage area" for whichever processes hold a handle to it. (Note that, similarly, you can delete a process' main executable after it has been read and launched in *nix, whereas you cannot even hope to rename the file until the process has exited on Windows)

Although it is a valid behaviour to unlink a file without releasing its handle (ie closing it) in *nix, I suspect it is not the behaviour you want in this case. On top of that, you are in a loop, which means that there are lots of files being deleted but left open. Too much of anything is a problem; just think what would happen if the OS allocated 4kb of cache for every file! And actually this is the problem that is giving you the error message, you are excedding the "number of maximum file descriptors [files, pipes, sockets, etc] open by a process at any given time" limit hard-coded into both gcc/stdlib and the OS/kernel itself. Changing them is a solution, but cleaning up the code and having it close the files is a much more clean one.
0

Featured Post

Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Summary: This tutorial covers some basics of pointer, pointer arithmetic and function pointer. What is a pointer: A pointer is a variable which holds an address. This address might be address of another variable/address of devices/address of fu…
Windows programmers of the C/C++ variety, how many of you realise that since Window 9x Microsoft has been lying to you about what constitutes Unicode (http://en.wikipedia.org/wiki/Unicode)? They will have you believe that Unicode requires you to use…
The goal of this video is to provide viewers with basic examples to understand and use pointers in the C programming language.
Video by: Grant
The goal of this video is to provide viewers with basic examples to understand and use nested-loops in the C programming language.

656 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question