Unlink command for opened files
Unlink command for opened files
am 16.04.2008 15:06:51 von Prasanth
When a file is open does unlink automatically deletes the file or it
generates an error. Because I wrote a program to delete a file and
regenerate the file. if the file is not deleted the data simply gets
appended to the existing file. which results in wrong results
Re: Unlink command for opened files
am 16.04.2008 15:21:27 von Joost Diepenmaat
Prasanth writes:
> When a file is open does unlink automatically deletes the file or it
> generates an error. Because I wrote a program to delete a file and
> regenerate the file. if the file is not deleted the data simply gets
> appended to the existing file. which results in wrong results
Unlink removes inodes, and it should succeed in that even if the file is
opened by any process. It does not empty files, if that's what you mean.
--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
Re: Unlink command for opened files
am 16.04.2008 15:25:16 von 1usa
Prasanth wrote in
news:270a0c78-9d5e-4486-8b35-b429c4d61755
@u36g2000prf.googlegroups.co
m:
> When a file is open does unlink automatically deletes the file or
> it generates an error. Because I wrote a program to delete a file
> and regenerate the file. if the file is not deleted the data
> simply gets appended to the existing file. which results in wrong
> results
Hmmmm ... What is the question?
If you script opened the file, close it before calling unlink.
If the file is opened in exclusive mode by another process, I am not
sure deleting it is the correct action in the first place.
If you don't want your script to continue if unlink failed, you
should check the return value of unlink.
On the other hand, not that this will solve whatever problem you are
having, I would not have messed with unlink at all:
open my $out_h, '>', 'report.txt'
or die "Cannot open 'report.txt': $!";
That truncates the file if it can be opened and would die if it
cannot. Beats appending junk to a file.
There are just two many combinations of problems and solutions that
might apply to your post. Please elaborate after reading the posting
guidelines for this group and may be taking a look at the following
page:
http://blogs.msdn.com/oldnewthing/archive/2008/04/15/8397753 .aspx
Sinan
--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(remove .invalid and reverse each component for email address)
comp.lang.perl.misc guidelines on the WWW:
http://www.rehabitation.com/clpmisc/
Re: Unlink command for opened files
am 16.04.2008 15:29:19 von 1usa
Joost Diepenmaat wrote in
news:87hce2gcko.fsf@zeekat.nl:
> Prasanth writes:
>
>> When a file is open does unlink automatically deletes the file or
>> it generates an error. Because I wrote a program to delete a file
>> and regenerate the file. if the file is not deleted the data
>> simply gets appended to the existing file. which results in wrong
>> results
>
> Unlink removes inodes, and it should succeed in that even if the
> file is opened by any process. It does not empty files, if that's
> what you mean.
I am guessing the OP is on Windows where
http://windowshelp.microsoft.com/Windows/en-US/help/47b3ce2b -3aec-401d-8be3-74434a1999831033.mspx
Sinan
--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(remove .invalid and reverse each component for email address)
comp.lang.perl.misc guidelines on the WWW:
http://www.rehabitation.com/clpmisc/
Re: Unlink command for opened files
am 16.04.2008 15:56:23 von Ben Morrow
Quoth Joost Diepenmaat :
> Prasanth writes:
>
> > When a file is open does unlink automatically deletes the file or it
> > generates an error. Because I wrote a program to delete a file and
> > regenerate the file. if the file is not deleted the data simply gets
> > appended to the existing file. which results in wrong results
>
> Unlink removes inodes, and it should succeed in that even if the file is
> opened by any process. It does not empty files, if that's what you mean.
Unlink removes *filenames*. Inodes are refcounted, and self-destruct
when there are no refs to them (including open file descriptors).
This only applies to Unixish filesystems, of course. Win32 won't let
you unlink an open file (under normal circumstances).
Ben
Re: Unlink command for opened files
am 16.04.2008 17:08:40 von jurgenex
Prasanth wrote:
>When a file is open does unlink automatically deletes the file or it
>generates an error.
That depends on the file system and/or operating system that you are
using.
jue
Re: Unlink command for opened files
am 16.04.2008 17:46:40 von Chris Mattern
On 2008-04-16, Prasanth wrote:
> When a file is open does unlink automatically deletes the file or it
> generates an error. Because I wrote a program to delete a file and
> regenerate the file. if the file is not deleted the data simply gets
> appended to the existing file. which results in wrong results
This is not a Perl question, this is a question about the filesystem
semantics for your particular operating system; the answer can differ
from OS to OS. I'll talk about Unix/Linux, because that's the one I
understand :-). In Unix/Linux, when you delete the file, you actually
only delete the directory entry for the file. If there are other directory
entries for the file (that is what a hard link is) it will continue to
exist and be accessible under the other pathnames. If you are holding the
file open, the file will continue to exist and it will accessible by the
file handle you have. You will not get any error message or code because
no error has occured; the directory entry was deleted without error. The
file will not actually be marked as free space until all directory entries
are unlinked and no process holds it open. However, the file has no association
with the old name any more: if you create a new file with the same name, you
will not get the old file back, you will get a new, empty file.
--
Christopher Mattern
NOTICE
Thank you for noticing this new notice
Your noticing it has been noted
And will be reported to the authorities
Re: Unlink command for opened files
am 16.04.2008 18:39:43 von xhoster
Prasanth wrote:
> When a file is open does unlink automatically deletes the file or it
> generates an error. Because I wrote a program to delete a file and
> regenerate the file. if the file is not deleted the data simply gets
> appended to the existing file. which results in wrong results
This depends on your OS.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.
Re: Unlink command for opened files
am 16.04.2008 18:56:36 von jurgenex
Chris Mattern wrote:
>On 2008-04-16, Prasanth wrote:
>> When a file is open does unlink automatically deletes the file or it
>> generates an error. Because I wrote a program to delete a file and
>> regenerate the file. if the file is not deleted the data simply gets
>> appended to the existing file. which results in wrong results
>
>This is not a Perl question, this is a question about the filesystem
>semantics for your particular operating system; the answer can differ
>from OS to OS. I'll talk about Unix/Linux, because that's the one I
>understand :-). In Unix/Linux, when you delete the file, you actually
>only delete the directory entry for the file.
This is getting somewhat off topic, but now you triggered my curiousity.
Does the behaviour really depend on the OS (as you seem to imply) or
does it depend on the file system? Or on both?
Example: FAT32 mounted on Linux. FAT32 does not have inodes or link
counts and I would guess that Linux would not allow deletion of a file
from a FAT32 partition as long as there is an open file descriptor
dangling. Is this true or does Linux simulate an inode and link count
structure on top of FAT?
jue
jue
Re: Unlink command for opened files
am 16.04.2008 19:27:19 von Ben Morrow
Quoth Jürgen Exner :
>
> This is getting somewhat off topic, but now you triggered my curiousity.
> Does the behaviour really depend on the OS (as you seem to imply) or
> does it depend on the file system? Or on both?
> Example: FAT32 mounted on Linux. FAT32 does not have inodes or link
> counts and I would guess that Linux would not allow deletion of a file
> from a FAT32 partition as long as there is an open file descriptor
> dangling. Is this true or does Linux simulate an inode and link count
> structure on top of FAT?
For both FAT and NFS (which doesn't support close-behind either) Linux
will fake the unlink by renaming the file to something 'unique', and
really deleting it after it's closed. Grep the kernel source for
'sillyrename'.
I don't know if all OSen provide (or attempt to provide) consistent
semantics across all filesystems they support.
Ben