Can a file be deleted even if it is in use. - Unix

This is a discussion on Can a file be deleted even if it is in use. - Unix ; Hi I am using Red Hat Linux 9 and gcc 3.4 I have created an application in C which has some file handling associated to it. The application starts with opening a file using fopen() in binary write mode. The ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 24

Thread: Can a file be deleted even if it is in use.

  1. Can a file be deleted even if it is in use.

    Hi
    I am using Red Hat Linux 9 and gcc 3.4
    I have created an application in C which has some file handling
    associated to it. The application starts with opening a file using
    fopen() in binary write mode. The file is open untill the application
    exits.
    Though my application is running I am able to delete the file created
    using rm -f .
    According to my knowledge the Operating System shouldn't have allowed
    any other application to delete a file if it is in use.

    Please correct me, and give me inputs for clarifying this concept.

    Thanks
    Aditya

  2. Re: Can a file be deleted even if it is in use.

    >I am using Red Hat Linux 9 and gcc 3.4
    >I have created an application in C which has some file handling
    >associated to it. The application starts with opening a file using
    >fopen() in binary write mode. The file is open untill the application
    >exits.
    >Though my application is running I am able to delete the file created
    >using rm -f .


    This is quite normal. It also doesn't prevent the application using
    the file from writing it, reading it, or growing it so big it runs
    the disk out of space. It can't re-open it by name as the file no longer
    has a name.

    >According to my knowledge the Operating System shouldn't have allowed
    >any other application to delete a file if it is in use.


    Why?

    In that case, you'd need rm -f,dammit which
    kills anything using the file, then deletes it, and
    rm -f,dammit,dammit which kills anything using the
    file, then deletes it, and deletes the offending users that were
    using the file.

    The only thing close to this in Unix systems is prohibition of deleting
    or opening for write a running executable.


  3. Re: Can a file be deleted even if it is in use.

    On Mar 31, 10:11*am, gordonb.yi...@burditt.org (Gordon Burditt) wrote:
    > >I am using Red Hat Linux 9 and gcc 3.4
    > >I have created an application in C which has some file handling
    > >associated to it. The application starts with opening a file using
    > >fopen() in binary write mode. The file is open untill the application
    > >exits.
    > >Though my application is running I am able to delete the file created
    > >using rm -f .

    >
    > This is quite normal. *It also doesn't prevent the application using
    > the file from writing it, reading it, or growing it so big it runs
    > the disk out of space. *It can't re-open it by name as the file no longer
    > has a name.
    >
    > >According to my knowledge the Operating System shouldn't have allowed
    > >any other application to delete a file if it is in use.

    >
    > Why?
    >
    > In that case, you'd need rm -f,dammit which
    > kills anything using the file, then deletes it, and
    > rm -f,dammit,dammit which kills anything using the
    > file, then deletes it, and deletes the offending users that were
    > using the file.
    >
    > The only thing close to this in Unix systems is prohibition of deleting
    > or opening for write a running executable.


    Thanks
    Sorry I missed a second thought on the second part. rm -f has to be
    that way.

    But then how can the behaviour of the application be modified so that
    the fwrite() or fseek() calls do give me the indication of the file
    been deleted.

  4. Re: Can a file be deleted even if it is in use.

    Aditya writes:
    > I am using Red Hat Linux 9 and gcc 3.4
    > I have created an application in C which has some file handling
    > associated to it. The application starts with opening a file using
    > fopen() in binary write mode. The file is open untill the application
    > exits. Though my application is running I am able to delete the file
    > created using rm -f .
    >
    > According to my knowledge the Operating System shouldn't have
    > allowed any other application to delete a file if it is in use.


    The file hasn't been deleted. One of the names ('links') pointing to
    it has been removed from the filesystem.

  5. Re: Can a file be deleted even if it is in use.

    On Mar 31, 2:02*pm, Rainer Weikusat wrote:
    > Aditya writes:
    > > I am using Red Hat Linux 9 and gcc 3.4
    > > I have created an application in C which has some file handling
    > > associated to it. The application starts with opening a file using
    > > fopen() in binary write mode. The file is open untill the application
    > > exits. Though my application is running I am able to delete the file
    > > created using rm -f .

    >
    > > According to my knowledge the Operating System shouldn't have
    > > allowed any other application to delete a file if it is in use.

    >
    > The file hasn't been deleted. One of the names ('links') pointing to
    > it has been removed from the filesystem.


    So, The problem still persists. How do I ensure that anything written
    doesn't go anywhere other than the file I open using fopen(), or I get
    some return value from these system calls where I can know that the
    file is not there to be written(or the links has been removed).

  6. Re: Can a file be deleted even if it is in use.

    Aditya wrote:
    > On Mar 31, 2:02 pm, Rainer Weikusat wrote:
    >> Aditya writes:
    >>> I am using Red Hat Linux 9 and gcc 3.4
    >>> I have created an application in C which has some file handling
    >>> associated to it. The application starts with opening a file using
    >>> fopen() in binary write mode. The file is open untill the application
    >>> exits. Though my application is running I am able to delete the file
    >>> created using rm -f .
    >>> According to my knowledge the Operating System shouldn't have
    >>> allowed any other application to delete a file if it is in use.

    >> The file hasn't been deleted. One of the names ('links') pointing to
    >> it has been removed from the filesystem.

    >
    > So, The problem still persists. How do I ensure that anything written
    > doesn't go anywhere other than the file I open using fopen(), or I get
    > some return value from these system calls where I can know that the
    > file is not there to be written(or the links has been removed).


    By using a file locking mechanism. For the concept of file locking:
    http://en.wikipedia.org/wiki/File_lo...ocking_in_UNIX

  7. Re: Can a file be deleted even if it is in use.

    Aditya writes:
    > On Mar 31, 2:02*pm, Rainer Weikusat wrote:
    >> Aditya writes:
    >> > I am using Red Hat Linux 9 and gcc 3.4
    >> > I have created an application in C which has some file handling
    >> > associated to it. The application starts with opening a file using
    >> > fopen() in binary write mode. The file is open untill the application
    >> > exits. Though my application is running I am able to delete the file
    >> > created using rm -f .

    >>
    >> > According to my knowledge the Operating System shouldn't have
    >> > allowed any other application to delete a file if it is in use.

    >>
    >> The file hasn't been deleted. One of the names ('links') pointing to
    >> it has been removed from the filesystem.

    >
    > So, The problem still persists. How do I ensure that anything written
    > doesn't go anywhere other than the file I open using fopen(), or I get
    > some return value from these system calls where I can know that the
    > file is not there to be written(or the links has been removed).


    You are misunderstanding something here. Somewhat simplified, 'a file'
    corresponds to an i-node ('index node') on UNIX(*), which is an
    on-disk data structure containing metainformation regarding the file
    (eg access permissions and a reference count) and pointers to the disk
    blocks containing the file content. When doing I/O-operations on some
    file, a program uses a 'file descriptor' ([usually] small, positive
    integer) to tell the kernel which file to access. This file descriptor
    ultimatively resolves to the i-node of the file.

    So, how does the program acquire a file descriptor for some file? The
    answer to this question is 'by doing an open-syscall, passing a
    certain pathname which identifies the file to access'. The i-node
    itself does not have a name. But multiple directory entries ('links')
    can point to it, each enabling access to the file using a different
    name. The file reference count in the i-node is used to track the
    number of existing links to it and the number of currently open file
    descriptors refering to the file associated with the i-node. When this
    reference count drops to zero, the space occupied by the file is
    deallocated (made available for future use to store the contents of
    different files). If an unlink system calls is executed, eg because
    a users ran the rm-command, a particular link is deleted from the
    filesystem and the reference count of the file the link had referred
    to is decremented. If that is still larger than zero afterwards, eg
    because some program has an open descriptor for the file, nothing else
    happens.

    For your situation, this means that your programm will continue to
    write to the same file you originally openend, but that names
    associated with this file can be created or removed while the program
    is using it.

  8. Re: Can a file be deleted even if it is in use.

    Nikos Chantziaras writes:
    > Aditya wrote:


    [...]

    >> So, The problem still persists. How do I ensure that anything written
    >> doesn't go anywhere other than the file I open using fopen(), or I get
    >> some return value from these system calls where I can know that the
    >> file is not there to be written(or the links has been removed).

    >
    > By using a file locking mechanism. For the concept of file locking:
    > http://en.wikipedia.org/wiki/File_lo...ocking_in_UNIX


    I would be strongly advisable that you read this yourself before
    referring others to it.

  9. Re: Can a file be deleted even if it is in use.

    On Mar 31, 2:24 pm, Aditya wrote:
    > On Mar 31, 2:02 pm, Rainer Weikusat wrote:
    >
    > > Aditya writes:
    > > > I am using Red Hat Linux 9 and gcc 3.4
    > > > I have created an application in C which has some file handling
    > > > associated to it. The application starts with opening a file using
    > > > fopen() in binary write mode. The file is open untill the application
    > > > exits. Though my application is running I am able to delete the file
    > > > created using rm -f .

    >
    > > > According to my knowledge the Operating System shouldn't have
    > > > allowed any other application to delete a file if it is in use.

    >
    > > The file hasn't been deleted. One of the names ('links') pointing to
    > > it has been removed from the filesystem.

    >
    > So, The problem still persists. How do I ensure that anything written
    > doesn't go anywhere other than the file I open using fopen(), or I get
    > some return value from these system calls where I can know that the
    > file is not there to be written(or the links has been removed).

    By setting the permissions (umask(2), open(2), chmod(2))
    Would you imagine how annoying it would be if the OS prevented the
    user from deleting his *own* files?
    I suggest that instead of making sure that the file will be there you
    make sure the behavior of your application is defined *if* the file is
    not there.

  10. Re: Can a file be deleted even if it is in use.

    On Mar 31, 4:24 am, Aditya wrote:

    > So, The problem still persists.


    What *exactly* is the problem? Everything you've described is the
    expected behavior.

    > How do I ensure that anything written
    > doesn't go anywhere other than the file I open using fopen(),


    The system ensures that. Even if the file is unlinked and a new file
    created with the same name, everything you write still goes to the
    file you opened.

    > or I get
    > some return value from these system calls where I can know that the
    > file is not there to be written(or the links has been removed).


    The file is always there to be written once you've opened it for
    writing. It will not go away until you close it. If you want to check
    the directory you used to access the file, you can do that. Google
    'file alteration monitor'.

    However, a file can have more than one name in a filesystem. That the
    name you used to open has gone away does not mean the file cannot be
    accessed by other names.

    DS

  11. Re: Can a file be deleted even if it is in use.

    On 31 Mar, 06:33, Aditya wrote:

    > But then how can the behaviour of the application be modified so that
    > the fwrite() or fseek() calls do give me the indication of the file
    > been deleted.


    The process still has the open file, and any writes/seeks will
    (probably) succeed. The fact that some other process has
    removed the directory entry that your process used to
    originally access the file is irrelevant. When you called
    fopen(), you used one of the names for the file (maybe
    the only one), and once you have the file you don't
    need the name anymore. When someone else executed
    rm to destroy that name....you don't really care. If that
    name happened to be the only name for the file (ie,
    there are no other hard links) there is a good chance that
    when your process is done, any data that it has written
    to the file will be lost because no other process will be
    able to open the file. But this is hardly different than
    someone deleting the file immediately after your
    process finished.


  12. Re: Can a file be deleted even if it is in use.

    On Apr 1, 1:17*am, William Pursell wrote:
    > On 31 Mar, 06:33, Aditya wrote:
    >
    > > But then how can the behaviour of the application be modified so that
    > > the fwrite() or fseek() calls do give me the indication of the file
    > > been deleted.

    >
    > The process still has the open file, and any writes/seeks will
    > (probably) succeed. *The fact that some other process has
    > removed the directory entry that your process used to
    > originally access the file is irrelevant. *When you called
    > fopen(), you used one of the names for the file (maybe
    > the only one), and once you have the file you don't
    > need the name anymore. *When someone else executed
    > rm to destroy that name....you don't really care. *If that
    > name happened to be the only name for the file (ie,
    > there are no other hard links) *there is a good chance that
    > when your process is done, any data that it has written
    > to the file will be lost because no other process will be
    > able to open the file. *But this is hardly different than
    > someone deleting the file immediately after your
    > process finished.


    thanks a lot for the highly informative discussion and answers to you
    all. I got the point and now I will be ensuring the existence of the
    file, instead of relying on the failure of the file handling standard
    C calls .

  13. Re: Can a file be deleted even if it is in use.

    > thanks a lot for the highly informative discussion and answers to you
    > all. I got the point and now I will be ensuring the existence of the
    > file, instead of relying on the failure of the file handling standard
    > C calls .


    I knew about this stuff but there is a good question that comes up:

    Suppose somebody deleted the file that is being accessed by the only
    (hard) link it has, while I am read/write-ing to it. How can I
    generate the link for the file again??

  14. Re: Can a file be deleted even if it is in use.

    Ravi writes:
    >> thanks a lot for the highly informative discussion and answers to you
    >> all. I got the point and now I will be ensuring the existence of the
    >> file, instead of relying on the failure of the file handling standard
    >> C calls .

    >
    > I knew about this stuff but there is a good question that comes up:
    >
    > Suppose somebody deleted the file that is being accessed by the only
    > (hard) link it has, while I am read/write-ing to it. How can I
    > generate the link for the file again??


    Generally, you cannot. link(2) expects two pathnames as arguments,
    meaning, a new link can only be created if an old link still exists.

  15. Re: Can a file be deleted even if it is in use.

    > Generally, you cannot. link(2) expects two pathnames as arguments,
    > meaning, a new link can only be created if an old link still exists.


    I am still looking if it can be done with an inode and a new file
    name. Its quite frustating to know it.

    One way to do it is to create a copy of the file with the new name,
    but it is quite slow and may create problems if the disk has not
    enough space.


  16. Re: Can a file be deleted even if it is in use.

    >> Generally, you cannot. link(2) expects two pathnames as arguments,
    >> meaning, a new link can only be created if an old link still exists.

    >
    >I am still looking if it can be done with an inode and a new file
    >name. Its quite frustating to know it.


    Could you explain why it is necessary to prevent an authorized user
    from intentionally manually deleting this file?

    >One way to do it is to create a copy of the file with the new name,
    >but it is quite slow and may create problems if the disk has not
    >enough space.


    And this is one of the reasons why an authorized user might
    intentionally manually delete the file.


  17. Re: Can a file be deleted even if it is in use.

    > Could you explain why it is necessary to prevent an authorized user
    > from intentionally manually deleting this file?


    This my happen if the security is compromised or by an accident. e.g.
    some systems alias rm command with rm -i while some do not.

    > >One way to do it is to create a copy of the file with the new name,
    > >but it is quite slow and may create problems if the disk has not
    > >enough space.

    >
    > And this is one of the reasons why an authorized user might
    > intentionally manually delete the file.


    I don't understand You here.

  18. Re: Can a file be deleted even if it is in use.

    >> Could you explain why it is necessary to prevent an authorized user
    >> from intentionally manually deleting this file?

    >
    >This my happen if the security is compromised or by an accident. e.g.
    >some systems alias rm command with rm -i while some do not.


    And you're going to all this trouble (re-creating a link to a
    deleted file) because of THAT?

    Why is it necessary to prevent an *AUTHORIZED* user from *INTENTIONALLY*
    manually deleting this file? No, I don't mean "accidentally intentionally"
    or an "authorized security breach".

    If it is more likely that a file deletion is a mistake or a security
    breach than intentional, I think you have a lot more problems than
    the security of one file. Your incompetent administrators might
    spill coffee in the power supply or set the building on fire, too,
    so you need to set up the security system to prevent coffee from
    entering the building.

    Have you considered writing this log file to something non-erasable
    (e.g. CD-ROM? or a hardcopy printer?)

    >> >One way to do it is to create a copy of the file with the new name,
    >> >but it is quite slow and may create problems if the disk has not
    >> >enough space.

    >>
    >> And this is one of the reasons why an authorized user might
    >> intentionally manually delete the file.

    >
    >I don't understand You here.


    When you run low on space, administrators deliberately delete
    low-value files (and log files come to mind here) to make room (with
    or without copying them somewhere else first).




  19. Re: Can a file be deleted even if it is in use.

    > And you're going to all this trouble (re-creating a link to a
    > deleted file) because of THAT?
    >
    > Why is it necessary to prevent an *AUTHORIZED* user from *INTENTIONALLY*
    > manually deleting this file? *No, I don't mean "accidentally intentionally"
    > or an "authorized security breach".
    >
    > If it is more likely that a file deletion is a mistake or a security
    > breach than intentional, I think you have a lot more problems than
    > the security of one file. *Your incompetent administrators might
    > spill coffee in the power supply or set the building on fire, too,
    > so you need to set up the security system to prevent coffee from
    > entering the building.
    >
    > Have you considered writing this log file to something non-erasable
    > (e.g. CD-ROM? *or a hardcopy printer?)
    >
    >
    > When you run low on space, administrators deliberately delete
    > low-value files (and log files come to mind here) to make room (with
    > or without copying them somewhere else first).


    I appreciate Your views. If all loopholes are filled up no way someone
    can delete my files.

    But just for curiosity still I ask,
    Can we create a file out of inode?
    Please don't fin me aggressive.

  20. Re: Can a file be deleted even if it is in use.

    Ravi writes:

    [...]

    > But just for curiosity still I ask,
    > Can we create a file out of inode?


    The answer is still 'no'. Depending on the OS, you can still access
    the contents using 'unrelated programs', eg via opening
    /proc//fd/ on Linux, but there is no way to create a link to
    an i-node.

    > Please don't fin me aggressive.


    'Aggressive' would not usually be the attribute associated with people
    repeatedly asking questions in the hope that answer they didn't like
    would change magically. Except insofar stupid people tend to be
    aggressive as well ...




+ Reply to Thread
Page 1 of 2 1 2 LastLast