«

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

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/

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/ar...5/8397753.aspx

Sinan

--
A. Sinan Unur <>
(remove .invalid and reverse each component for email address)

comp.lang.perl.misc guidelines on the WWW:
http://www.rehabitation.com/clpmisc/

Joost Diepenmaat <> wrote in
news::

> 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/Win...999831033.mspx

Sinan

--
A. Sinan Unur <>
(remove .invalid and reverse each component for email address)

comp.lang.perl.misc guidelines on the WWW:
http://www.rehabitation.com/clpmisc/

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

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

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.

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

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