[19987] in Perl-Users-Digest
Perl-Users Digest, Issue: 2182 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Nov 22 11:10:31 2001
Date: Thu, 22 Nov 2001 08:10:08 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Message-Id: <1006445408-v10-i2182@ruby.oce.orst.edu>
Content-Type: text
Perl-Users Digest Thu, 22 Nov 2001 Volume: 10 Number: 2182
Today's topics:
Re: How can you do a safe unlink? (Helgi Briem)
Re: How can you do a safe unlink? <admin@asarian-host.net>
Re: How can you do a safe unlink? (Anno Siegel)
Re: How can you do a safe unlink? <5l259r001@sneakemail.com>
Re: How can you do a safe unlink? <5l259r001@sneakemail.com>
Re: How can you do a safe unlink? <5l259r001@sneakemail.com>
Re: How can you do a safe unlink? <5l259r001@sneakemail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 22 Nov 2001 14:18:38 GMT
From: helgi@decode.is (Helgi Briem)
Subject: Re: How can you do a safe unlink?
Message-Id: <3bfd07dc.3041603234@News.CIS.DFN.DE>
On Thu, 22 Nov 2001 13:31:14 GMT, "Mark"
<admin@asarian-host.net> wrote:
>Meanwhile, the grizzly bear has, despite any number of cheap personal
>attacks, not given a solution to the problem.
You started the CPAs. Anyway, MJD, who has forgotten
more about Perl, OSs and file locking this morning than you
and I know combined, does not need me to defend him.
>The grizzly bear has growled that flock is not a Perl function,
>that he did not know what OS I was using,
It matters because Unix and NT implement file locks
in different ways. Perl does not implement file locks
at all, it asks the system to do it. Hence, what OS
are you using?
Regards,
Helgi Briem
------------------------------
Date: Thu, 22 Nov 2001 14:40:52 GMT
From: "Mark" <admin@asarian-host.net>
Subject: Re: How can you do a safe unlink?
Message-Id: <U78L7.44532$8q.6789589@bin2.nnrp.aus1.giganews.com>
"Helgi Briem" <helgi@decode.is> wrote in message
news:3bfd07dc.3041603234@News.CIS.DFN.DE...
> On Thu, 22 Nov 2001 13:31:14 GMT, "Mark"
> <admin@asarian-host.net> wrote:
>
> >The grizzly bear has growled that flock is not a Perl
> >function, that he did not know what OS I was using,
>
> It matters because Unix and NT implement file locks
> in different ways. Perl does not implement file locks
> at all, it asks the system to do it. Hence, what OS
> are you using?
So far, Ilya Martynov has given me a few very useful answers. I was afraid
OS might reclaim disk space once the file is unlinked. Him telling me this
only occurs when there is no longer a filehandle open for it, is quite a
reassurance. Since the program will be running on FreeBSD 4.1.1 (I only use
XP to do home-testing), only on Windows platforms will I not be able to
acquire a lock first. As far as I can tell, and I honestly do not think I am
wrong about this, it seems that under NT (and XP) there is really no way to
get a lock before unlinking. I wish it were different. But I can live with
that.
- Mark
------------------------------
Date: 22 Nov 2001 15:05:23 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: How can you do a safe unlink?
Message-Id: <9tj47j$jdp$1@mamenchi.zrz.TU-Berlin.DE>
According to Mark <admin@asarian-host.net>:
> "Helgi Briem" <helgi@decode.is> wrote in message
> news:3bfceca2.3034632911@News.CIS.DFN.DE...
>
> > On Thu, 22 Nov 2001 02:07:30 GMT, "Mark"
> > <admin@asarian-host.net> wrote:
> >
> > >"Mark Jason Dominus" <mjd@plover.com> wrote in message
> > >news:3bfc52ab.5e7a$338@news.op.net...
> >
> > Reading this thread is like watching a little
> > fluffy white bunny wabbit (Mark@asarian) venturing
> > out of its hole for the first time, attacking a
> > not very hungry grizzly bear (Mark JD) that
> > likes to play with its food before eating it.
> >
> > Let the games begin.
>
>
> Meanwhile, the grizzly bear has, despite any number of cheap personal
> attacks, not given a solution to the problem.
What makes you think you are entitled to be given a solution? You
post a problem, people discuss it. Sometimes a solution ensues.
> The grizzly bear has growled
> that flock is not a Perl function, that he did not know what OS I was using,
> etc.
Both pertinent to the question at hand.
> But as to the main question, in all its simplicity, as how to obtain a
> lock on a file before unlinking it, without having to create a handle for it
> first -- a handle to an open file that will prevent the file from being
> unlinked in the first place (or will allow it to be unlinked, but still
> allows it to be readable for already open filehandles to it) -- to that
> quandary this white bunny has yet to hear a decent answer.
A question that, in all its simplicity, takes a six-line paragraph full
of but's and if's?
Reduced it to its core, the question is "how to obtain a lock on a
file ... without having to create a handle for it". Just one look
at the documentation shows that this question is absurd. You *must*
have a filehandle to create a lock, because that's what the lock
function expects as its first argument. End of story.
File locks are concerned with integrity of file contents. They have
nothing to do with its visibility in the file system, and trying to
lock a file to make its deletion "safer" is futile.
[...]
> to read from / write to it. It may not bother the grizzly bear that
> processes can continue to read from files that have been unlinked from the
> FS, but I call it pretty darn unsafe.
You have been asked before, and I'm asking again: What, exactly, is
unsafe about the scenario you describe. Some OSes explicitly support
files of an "evanescent" type which are never visible in the file system.
Apparently you perceive a risk that is connected with deleting a file,
and you have set your mind that you must lock the file to avoid it.
Explain the risk, and we may either be able to find a way to avoid
it or show that the risk doesn't exist. File locking will most likely
not be involved.
[rest snipped]
Anno
------------------------------
Date: Thu, 22 Nov 2001 16:07:48 +0100
From: "Steffen Müller" <5l259r001@sneakemail.com>
Subject: Re: How can you do a safe unlink?
Message-Id: <9tj4b7$ri0$01$1@news.t-online.com>
"Mark" <admin@asarian-host.net> schrieb im Newsbeitrag
news:C67L7.12897$YD.1245758@news2.aus1.giganews.com...
| "Helgi Briem" <helgi@decode.is> wrote in message
| news:3bfceca2.3034632911@News.CIS.DFN.DE...
|
| > On Thu, 22 Nov 2001 02:07:30 GMT, "Mark"
| > <admin@asarian-host.net> wrote:
| >
| > >"Mark Jason Dominus" <mjd@plover.com> wrote in message
| > >news:3bfc52ab.5e7a$338@news.op.net...
| >
| > Reading this thread is like watching a little
| > fluffy white bunny wabbit (Mark@asarian) venturing
| > out of its hole for the first time, attacking a
| > not very hungry grizzly bear (Mark JD) that
| > likes to play with its food before eating it.
| >
| > Let the games begin.
Just about right. In this case, size is proportional to the state of sanity
and patience.
I'll try to avoid this kind of pun in this post, so please, Mark, keep calm
when reading and answering.
| Meanwhile, the grizzly bear has, despite any number of cheap personal
| attacks, not given a solution to the problem.
About the cheap personal attacks, either see Bernard's post or look at the
digest below.
| The grizzly bear has growled
| that flock is not a Perl function, that he did not know what OS I was
using,
| etc. But as to the main question, in all its simplicity, as how to obtain
a
| lock on a file before unlinking it, without having to create a handle for
it
| first -- a handle to an open file that will prevent the file from being
| unlinked in the first place (or will allow it to be unlinked, but still
| allows it to be readable for already open filehandles to it) -- to that
| quandary this white bunny has yet to hear a decent answer.
For once, if the problem is just so simple, why don't you answer it by
digging into the docs? Finding the place to start should be straightforward
if the problem is fully understood because Perl itself is very well
documented.
Now, either you decided it would be less work to ask than to read or you
have no idea where to start with your research. If the former is the case,
you violated the newsgroup charter and do not deserve help. However, I'll
assume it's the latter, just because I do not want to doubt you have read &
understood the newsgroup's charter.
As you seem to be unsure where to start your research on the problem, you
might need to invest some thought on rephrasing the problem - perhaps it was
not as clear as you thought?
More on that below.
| At the end of the day, when all put-downs subside, the grizzly bear will,
in
| my estimation, still be stumped for a decent answer. History will likely
| prove the white bunny right:
How can you be right if you are asking a question?
Besides, MJD does know a decent answer. He even somewhat gave it to you, but
you either chose to flame him or ignore his help because it is not the type
of help you were looking for. You should never expect to get a certain
answer if you ask a question. If you do, don't ask.
The last possibility could be that you did not understand what MJD pointed
out. That's not telling anything bad about you, some answer require certain
previous knowledge of OS's and/or languages and concepts.
| that acquiring a lock on a file before
| unlinking it, is not safe
"safe" is not a concise term to be used in this context. However, just as
MJD *kindly* asked you to *before*, you provide some rephrasing below:
| because either the file will not unlink, as you
| would want it to (which means you have to unlink without the lock), or it
| will unlink, but not prevent open filehandles to that file from continuing
| to read from / write to it.
So you are using the term "safe" to say that you cannot use unlink and
expect it to delete the file regardless of all circumstances.
Well, if you use it that way, you are right: unlink is not "safe".
However, this makes the question in itself troublesome. It shows that you
have not done what is good coding practice: Check the success of all system
interactions. This is the case for Perl just as for any other language. The
reason why you should do that is because *all* system interactions are not
"safe" in the way you define it. open may fail, close, system(),
read/write/seek/truncate - hell, all of them! Again, that is not a problem
with Perl. This stems from the fact that whatever OS you're running, the
system interaction functions just use some functions provided (or not
provided->w9x) by the OS.
Then, it was previously pointed out by various persons that flock and unlink
are unrelated. THE OS implements these. The unlink function does not care
about the flock-ed state. This, again, is OS implementation. No Perl
question involved other than that you did not check the error codes of your
system interaction.
If you do check them, you can easily implement a "safe" unlink call!
As this is all OS related, it *is* madly important to know what OS you are
using. MJD told you so before; and again, he did so *calmly*. This is
because depending on which OS you are using, the unlink behaviour will
differ. No Perl involved.
| It may not bother the grizzly bear that
| processes can continue to read from files that have been unlinked from the
| FS, but I call it pretty darn unsafe.
Unsafe as in "not reliable without checking", yes. Violation of good coding
practice, yes.
| At the risk of giving you some more food for laughter, I was actually
| mistaken about the unlinked file being recommitted to disk again. It
simply
| does not get unlinked at all (XP).
This is the first time you actually say you are specifically looking at XP.
Previously, you mentioned XP, but did not clearly state it. You were talking
about w9x just as well.
| But that really only makes it worse. In
| fact, this merely only poignantly underlines my point: that getting a
| filehandle, in order to get a lock, is not an act without consequence.
Nobody ever doubted that. locking has consequences, but again, locking does
not make sense for unlinking! This, again, is OS related.
|I
| thought the consequence was that the file was being recommitted to disk on
| close of the filehandle. Instead, getting a filehandle for it totally
| prevents the unlinking of the file at all! (XP).
You stated that above. OS related. (see above)
| That makes getting a lock
| for it first even a total impossibility!
Check the system interactions for errors using $!
| So, my initial question therefore
| stands firmer than ever: how to do a safe unlink?
Check for errors. People told you so.
| To little white bunnies,
| concurrent processes indiscriminately unlinking files that I might be
| working on, that we find very unsafe indeed.
Because flock and unlink are implemented differently on different OS's,
people cannot tell you the exact behaviour of the functions. You had
previously not stated your OS.
| To grumpy old grizzly bears, a
| file more or less may not matter; but to this small bunny, I only feel
safe
| when all my concurrent processes neatly wait in line (using the flock)
| before messing with shared files.
Well, flock in itself is unsafe if you don't check for errors.
| This white bunny will stick around a bit, and see whether the grizzly bear
| will actually come up with a solution to the problem, or whether it will
| further degenerate into more personal putdowns.
Like yours? See below.
| I hope the first, but I fear
| the latter. Which is a shame, actually. Acquiring a lock for a file in
order
| to safely unlink it, that is, granted, not the world's most enticing
| problem;
No, it's a problem that springs from insufficient knowledge of file systems
and OS's. No Pelr involved.
| nor does this white bunny expect an enticing answer; just a normal
| one would do.
Well, you got an answer before.
<flame on>
Now, here is a little digest of your personal attacks against MJD.
MJD> One is what you mean by 'safe'. You never say what you think the
MJD> problem will be. You just say either 'it will not work' or 'it is
MJD> unsafe'.
M> I think I pretty much outlined what I meant with "safe": using the flock
M> mechanism to read/write to files.
You think? The people you are seeking answers from do not. Using flock in
combination with unlink is not sensible.
MJD> The other problem is the phrase 'in Perl'. You appear to be
MJD> describing a generic problem that is independent of language.
MJD>
MJD> All this makes me feel like I haven't gotten your point.
M> True enough.
MJD says you "appear to be" in order not to insult you by using definite
statements about your knowledge. You don't, however.
MJD> On Windows system, the delete operation will fail. On a Unix system,
MJD> the delete operation will succeed, and the file will be removed from
MJD> the file system, but its data will remain intact until the reading
MJD> process closes it.
M> Not entirely accurate. For starters, there is no "windows". Win9x, for
M> instance, does not support flock (Or, I should say: ActivePerl did not
M> support flock for Win9x, presumably because Win9x has no locking
mechanism.)
M> On WinXP, to my joy, this function is fully implemented. Furthermore, on
XP
M> the data also remains available for read, even if unlinked in-between.
And,
M> in XP, the unlink does not fail either.
There is no sense in talking about a flock-issue for an OS that doesn't
support flock. Therefore it was obvious that MJD was talking about win32's
which includes XP. Using "For starters" is like telling MJD he has no clue
about windoze. A personal attack. The truth is, he does, but does not care
about Windows.
M> You see, the problem you're not getting, is that the unlink works just
fine,
M> except that the "close (ARTICLE)" will make the file reappear again, as
if
M> it were never unlinked. You seem to be missing your own point: that data
M> remains available for read; hence, the "close (ARTICLE)" closes the file
as
M> if it were never deleted! Therefore, the problem: you can get a flock for
M> the file before you unlink it; but close the handle used to open the file
M> (to get the lock) and the file reappears again!
You did realize that you were wrong about the file reappearing. You said so.
But you telling MJD that he did not "get" the problem? Don't you feel
ashamed?
M> What you constantly fail to understand, is my point that requiring
M> a filehandle to lock, is not an action without consequence.
a) MJD never said it was without consequences.
b) He cannot possibly have "constantly" failed to understand something if he
only replied *once* to your post up to this time. It's an insult.
M> So, my point remains
You never had a *valid* point because you assumed something that isn't the
case: unlink/flock are related and they're Perl.
M> And you should try and grasp the nature of the problem before you say
there
M> is no problem. It works better that way.
Have you considered that *he* grasped the problem and you did not? After
all, *you* sought help. You got it, but could not bear that the help is the
subtle point that the problem is your misunderstanding of underlying
concepts.
M> to that quandary this white bunny has yet to hear a decent answer.
You got a decent answer. You did not understand it.
M> History will likely prove the white bunny right:
One cannot be right if one demonstrates cluelessness by asking a question
that does not make sense to be asked. It's like asking "Why does Windows not
behave like Unix?" And then state "They are both OS's, so they should behave
the same." In fact, you problem isn't far from that.
Enough. If you don't get it now, you won't ever. My sincere and honest
suggestion would be to either apologize (unlikely, that takes a *lot* of
self-control after your cheap attacks) or leave. The former would likely
result in the folks around here helping you with other problems again, the
latter...
Steffen
--
$_=q;0cb212c210b0bb010c0113bb0c410c0b516c0bb3d212c2b0b0b016b6cb2b2c21010c0
b41110b3bba0e0c0d2c4b2b6bc013d2c0d0b01012b0b0;;s/\n//g;s/(\d)/$1<2?$1:'0'x
$1/ge;s/([a-f])/'1'x(ord($1)-97)/ge;$o=$_;push@o,substr($o,$_*8,8) for(0..
24);for(@o){print"\0"x(26-$i).chr(oct('0b'.($_)))."\r";$i++};print"\n"#stm
------------------------------
Date: Thu, 22 Nov 2001 16:07:48 +0100
From: "Steffen Müller" <5l259r001@sneakemail.com>
Subject: Re: How can you do a safe unlink?
Message-Id: <9tj4ao$fi1$05$1@news.t-online.com>
"Mark" <admin@asarian-host.net> schrieb im Newsbeitrag
news:C67L7.12897$YD.1245758@news2.aus1.giganews.com...
| "Helgi Briem" <helgi@decode.is> wrote in message
| news:3bfceca2.3034632911@News.CIS.DFN.DE...
|
| > On Thu, 22 Nov 2001 02:07:30 GMT, "Mark"
| > <admin@asarian-host.net> wrote:
| >
| > >"Mark Jason Dominus" <mjd@plover.com> wrote in message
| > >news:3bfc52ab.5e7a$338@news.op.net...
| >
| > Reading this thread is like watching a little
| > fluffy white bunny wabbit (Mark@asarian) venturing
| > out of its hole for the first time, attacking a
| > not very hungry grizzly bear (Mark JD) that
| > likes to play with its food before eating it.
| >
| > Let the games begin.
Just about right. In this case, size is proportional to the state of sanity
and patience.
I'll try to avoid this kind of pun in this post, so please, Mark, keep calm
when reading and answering.
| Meanwhile, the grizzly bear has, despite any number of cheap personal
| attacks, not given a solution to the problem.
About the cheap personal attacks, either see Bernard's post or look at the
digest below.
| The grizzly bear has growled
| that flock is not a Perl function, that he did not know what OS I was
using,
| etc. But as to the main question, in all its simplicity, as how to obtain
a
| lock on a file before unlinking it, without having to create a handle for
it
| first -- a handle to an open file that will prevent the file from being
| unlinked in the first place (or will allow it to be unlinked, but still
| allows it to be readable for already open filehandles to it) -- to that
| quandary this white bunny has yet to hear a decent answer.
For once, if the problem is just so simple, why don't you answer it by
digging into the docs? Finding the place to start should be straightforward
if the problem is fully understood because Perl itself is very well
documented.
Now, either you decided it would be less work to ask than to read or you
have no idea where to start with your research. If the former is the case,
you violated the newsgroup charter and do not deserve help. However, I'll
assume it's the latter, just because I do not want to doubt you have read &
understood the newsgroup's charter.
As you seem to be unsure where to start your research on the problem, you
might need to invest some thought on rephrasing the problem - perhaps it was
not as clear as you thought?
More on that below.
| At the end of the day, when all put-downs subside, the grizzly bear will,
in
| my estimation, still be stumped for a decent answer. History will likely
| prove the white bunny right:
How can you be right if you are asking a question?
Besides, MJD does know a decent answer. He even somewhat gave it to you, but
you either chose to flame him or ignore his help because it is not the type
of help you were looking for. You should never expect to get a certain
answer if you ask a question. If you do, don't ask.
The last possibility could be that you did not understand what MJD pointed
out. That's not telling anything bad about you, some answer require certain
previous knowledge of OS's and/or languages and concepts.
| that acquiring a lock on a file before
| unlinking it, is not safe
"safe" is not a concise term to be used in this context. However, just as
MJD *kindly* asked you to *before*, you provide some rephrasing below:
| because either the file will not unlink, as you
| would want it to (which means you have to unlink without the lock), or it
| will unlink, but not prevent open filehandles to that file from continuing
| to read from / write to it.
So you are using the term "safe" to say that you cannot use unlink and
expect it to delete the file regardless of all circumstances.
Well, if you use it that way, you are right: unlink is not "safe".
However, this makes the question in itself troublesome. It shows that you
have not done what is good coding practice: Check the success of all system
interactions. This is the case for Perl just as for any other language. The
reason why you should do that is because *all* system interactions are not
"safe" in the way you define it. open may fail, close, system(),
read/write/seek/truncate - hell, all of them! Again, that is not a problem
with Perl. This stems from the fact that whatever OS you're running, the
system interaction functions just use some functions provided (or not
provided->w9x) by the OS.
Then, it was previously pointed out by various persons that flock and unlink
are unrelated. THE OS implements these. The unlink function does not care
about the flock-ed state. This, again, is OS implementation. No Perl
question involved other than that you did not check the error codes of your
system interaction.
If you do check them, you can easily implement a "safe" unlink call!
As this is all OS related, it *is* madly important to know what OS you are
using. MJD told you so before; and again, he did so *calmly*. This is
because depending on which OS you are using, the unlink behaviour will
differ. No Perl involved.
| It may not bother the grizzly bear that
| processes can continue to read from files that have been unlinked from the
| FS, but I call it pretty darn unsafe.
Unsafe as in "not reliable without checking", yes. Violation of good coding
practice, yes.
| At the risk of giving you some more food for laughter, I was actually
| mistaken about the unlinked file being recommitted to disk again. It
simply
| does not get unlinked at all (XP).
This is the first time you actually say you are specifically looking at XP.
Previously, you mentioned XP, but did not clearly state it. You were talking
about w9x just as well.
| But that really only makes it worse. In
| fact, this merely only poignantly underlines my point: that getting a
| filehandle, in order to get a lock, is not an act without consequence.
Nobody ever doubted that. locking has consequences, but again, locking does
not make sense for unlinking! This, again, is OS related.
|I
| thought the consequence was that the file was being recommitted to disk on
| close of the filehandle. Instead, getting a filehandle for it totally
| prevents the unlinking of the file at all! (XP).
You stated that above. OS related. (see above)
| That makes getting a lock
| for it first even a total impossibility!
Check the system interactions for errors using $!
| So, my initial question therefore
| stands firmer than ever: how to do a safe unlink?
Check for errors. People told you so.
| To little white bunnies,
| concurrent processes indiscriminately unlinking files that I might be
| working on, that we find very unsafe indeed.
Because flock and unlink are implemented differently on different OS's,
people cannot tell you the exact behaviour of the functions. You had
previously not stated your OS.
| To grumpy old grizzly bears, a
| file more or less may not matter; but to this small bunny, I only feel
safe
| when all my concurrent processes neatly wait in line (using the flock)
| before messing with shared files.
Well, flock in itself is unsafe if you don't check for errors.
| This white bunny will stick around a bit, and see whether the grizzly bear
| will actually come up with a solution to the problem, or whether it will
| further degenerate into more personal putdowns.
Like yours? See below.
| I hope the first, but I fear
| the latter. Which is a shame, actually. Acquiring a lock for a file in
order
| to safely unlink it, that is, granted, not the world's most enticing
| problem;
No, it's a problem that springs from insufficient knowledge of file systems
and OS's. No Pelr involved.
| nor does this white bunny expect an enticing answer; just a normal
| one would do.
Well, you got an answer before.
<flame on>
Now, here is a little digest of your personal attacks against MJD.
MJD> One is what you mean by 'safe'. You never say what you think the
MJD> problem will be. You just say either 'it will not work' or 'it is
MJD> unsafe'.
M> I think I pretty much outlined what I meant with "safe": using the flock
M> mechanism to read/write to files.
You think? The people you are seeking answers from do not. Using flock in
combination with unlink is not sensible.
MJD> The other problem is the phrase 'in Perl'. You appear to be
MJD> describing a generic problem that is independent of language.
MJD>
MJD> All this makes me feel like I haven't gotten your point.
M> True enough.
MJD says you "appear to be" in order not to insult you by using definite
statements about your knowledge. You don't, however.
MJD> On Windows system, the delete operation will fail. On a Unix system,
MJD> the delete operation will succeed, and the file will be removed from
MJD> the file system, but its data will remain intact until the reading
MJD> process closes it.
M> Not entirely accurate. For starters, there is no "windows". Win9x, for
M> instance, does not support flock (Or, I should say: ActivePerl did not
M> support flock for Win9x, presumably because Win9x has no locking
mechanism.)
M> On WinXP, to my joy, this function is fully implemented. Furthermore, on
XP
M> the data also remains available for read, even if unlinked in-between.
And,
M> in XP, the unlink does not fail either.
There is no sense in talking about a flock-issue for an OS that doesn't
support flock. Therefore it was obvious that MJD was talking about win32's
which includes XP. Using "For starters" is like telling MJD he has no clue
about windoze. A personal attack. The truth is, he does, but does not care
about Windows.
M> You see, the problem you're not getting, is that the unlink works just
fine,
M> except that the "close (ARTICLE)" will make the file reappear again, as
if
M> it were never unlinked. You seem to be missing your own point: that data
M> remains available for read; hence, the "close (ARTICLE)" closes the file
as
M> if it were never deleted! Therefore, the problem: you can get a flock for
M> the file before you unlink it; but close the handle used to open the file
M> (to get the lock) and the file reappears again!
You did realize that you were wrong about the file reappearing. You said so.
But you telling MJD that he did not "get" the problem? Don't you feel
ashamed?
M> What you constantly fail to understand, is my point that requiring
M> a filehandle to lock, is not an action without consequence.
a) MJD never said it was without consequences.
b) He cannot possibly have "constantly" failed to understand something if he
only replied *once* to your post up to this time. It's an insult.
M> So, my point remains
You never had a *valid* point because you assumed something that isn't the
case: unlink/flock are related and they're Perl.
M> And you should try and grasp the nature of the problem before you say
there
M> is no problem. It works better that way.
Have you considered that *he* grasped the problem and you did not? After
all, *you* sought help. You got it, but could not bear that the help is the
subtle point that the problem is your misunderstanding of underlying
concepts.
M> to that quandary this white bunny has yet to hear a decent answer.
You got a decent answer. You did not understand it.
M> History will likely prove the white bunny right:
One cannot be right if one demonstrates cluelessness by asking a question
that does not make sense to be asked. It's like asking "Why does Windows not
behave like Unix?" And then state "They are both OS's, so they should behave
the same." In fact, you problem isn't far from that.
Enough. If you don't get it now, you won't ever. My sincere and honest
suggestion would be to either apologize (unlikely, that takes a *lot* of
self-control after your cheap attacks) or leave. The former would likely
result in the folks around here helping you with other problems again, the
latter...
Steffen
--
$_=q;0cb212c210b0bb010c0113bb0c410c0b516c0bb3d212c2b0b0b016b6cb2b2c21010c0
b41110b3bba0e0c0d2c4b2b6bc013d2c0d0b01012b0b0;;s/\n//g;s/(\d)/$1<2?$1:'0'x
$1/ge;s/([a-f])/'1'x(ord($1)-97)/ge;$o=$_;push@o,substr($o,$_*8,8) for(0..
24);for(@o){print"\0"x(26-$i).chr(oct('0b'.($_)))."\r";$i++};print"\n"#stm
------------------------------
Date: Thu, 22 Nov 2001 16:07:48 +0100
From: "Steffen Müller" <5l259r001@sneakemail.com>
Subject: Re: How can you do a safe unlink?
Message-Id: <9tj4bl$tbf$00$1@news.t-online.com>
"Mark" <admin@asarian-host.net> schrieb im Newsbeitrag
news:C67L7.12897$YD.1245758@news2.aus1.giganews.com...
| "Helgi Briem" <helgi@decode.is> wrote in message
| news:3bfceca2.3034632911@News.CIS.DFN.DE...
|
| > On Thu, 22 Nov 2001 02:07:30 GMT, "Mark"
| > <admin@asarian-host.net> wrote:
| >
| > >"Mark Jason Dominus" <mjd@plover.com> wrote in message
| > >news:3bfc52ab.5e7a$338@news.op.net...
| >
| > Reading this thread is like watching a little
| > fluffy white bunny wabbit (Mark@asarian) venturing
| > out of its hole for the first time, attacking a
| > not very hungry grizzly bear (Mark JD) that
| > likes to play with its food before eating it.
| >
| > Let the games begin.
Just about right. In this case, size is proportional to the state of sanity
and patience.
I'll try to avoid this kind of pun in this post, so please, Mark, keep calm
when reading and answering.
| Meanwhile, the grizzly bear has, despite any number of cheap personal
| attacks, not given a solution to the problem.
About the cheap personal attacks, either see Bernard's post or look at the
digest below.
| The grizzly bear has growled
| that flock is not a Perl function, that he did not know what OS I was
using,
| etc. But as to the main question, in all its simplicity, as how to obtain
a
| lock on a file before unlinking it, without having to create a handle for
it
| first -- a handle to an open file that will prevent the file from being
| unlinked in the first place (or will allow it to be unlinked, but still
| allows it to be readable for already open filehandles to it) -- to that
| quandary this white bunny has yet to hear a decent answer.
For once, if the problem is just so simple, why don't you answer it by
digging into the docs? Finding the place to start should be straightforward
if the problem is fully understood because Perl itself is very well
documented.
Now, either you decided it would be less work to ask than to read or you
have no idea where to start with your research. If the former is the case,
you violated the newsgroup charter and do not deserve help. However, I'll
assume it's the latter, just because I do not want to doubt you have read &
understood the newsgroup's charter.
As you seem to be unsure where to start your research on the problem, you
might need to invest some thought on rephrasing the problem - perhaps it was
not as clear as you thought?
More on that below.
| At the end of the day, when all put-downs subside, the grizzly bear will,
in
| my estimation, still be stumped for a decent answer. History will likely
| prove the white bunny right:
How can you be right if you are asking a question?
Besides, MJD does know a decent answer. He even somewhat gave it to you, but
you either chose to flame him or ignore his help because it is not the type
of help you were looking for. You should never expect to get a certain
answer if you ask a question. If you do, don't ask.
The last possibility could be that you did not understand what MJD pointed
out. That's not telling anything bad about you, some answer require certain
previous knowledge of OS's and/or languages and concepts.
| that acquiring a lock on a file before
| unlinking it, is not safe
"safe" is not a concise term to be used in this context. However, just as
MJD *kindly* asked you to *before*, you provide some rephrasing below:
| because either the file will not unlink, as you
| would want it to (which means you have to unlink without the lock), or it
| will unlink, but not prevent open filehandles to that file from continuing
| to read from / write to it.
So you are using the term "safe" to say that you cannot use unlink and
expect it to delete the file regardless of all circumstances.
Well, if you use it that way, you are right: unlink is not "safe".
However, this makes the question in itself troublesome. It shows that you
have not done what is good coding practice: Check the success of all system
interactions. This is the case for Perl just as for any other language. The
reason why you should do that is because *all* system interactions are not
"safe" in the way you define it. open may fail, close, system(),
read/write/seek/truncate - hell, all of them! Again, that is not a problem
with Perl. This stems from the fact that whatever OS you're running, the
system interaction functions just use some functions provided (or not
provided->w9x) by the OS.
Then, it was previously pointed out by various persons that flock and unlink
are unrelated. THE OS implements these. The unlink function does not care
about the flock-ed state. This, again, is OS implementation. No Perl
question involved other than that you did not check the error codes of your
system interaction.
If you do check them, you can easily implement a "safe" unlink call!
As this is all OS related, it *is* madly important to know what OS you are
using. MJD told you so before; and again, he did so *calmly*. This is
because depending on which OS you are using, the unlink behaviour will
differ. No Perl involved.
| It may not bother the grizzly bear that
| processes can continue to read from files that have been unlinked from the
| FS, but I call it pretty darn unsafe.
Unsafe as in "not reliable without checking", yes. Violation of good coding
practice, yes.
| At the risk of giving you some more food for laughter, I was actually
| mistaken about the unlinked file being recommitted to disk again. It
simply
| does not get unlinked at all (XP).
This is the first time you actually say you are specifically looking at XP.
Previously, you mentioned XP, but did not clearly state it. You were talking
about w9x just as well.
| But that really only makes it worse. In
| fact, this merely only poignantly underlines my point: that getting a
| filehandle, in order to get a lock, is not an act without consequence.
Nobody ever doubted that. locking has consequences, but again, locking does
not make sense for unlinking! This, again, is OS related.
|I
| thought the consequence was that the file was being recommitted to disk on
| close of the filehandle. Instead, getting a filehandle for it totally
| prevents the unlinking of the file at all! (XP).
You stated that above. OS related. (see above)
| That makes getting a lock
| for it first even a total impossibility!
Check the system interactions for errors using $!
| So, my initial question therefore
| stands firmer than ever: how to do a safe unlink?
Check for errors. People told you so.
| To little white bunnies,
| concurrent processes indiscriminately unlinking files that I might be
| working on, that we find very unsafe indeed.
Because flock and unlink are implemented differently on different OS's,
people cannot tell you the exact behaviour of the functions. You had
previously not stated your OS.
| To grumpy old grizzly bears, a
| file more or less may not matter; but to this small bunny, I only feel
safe
| when all my concurrent processes neatly wait in line (using the flock)
| before messing with shared files.
Well, flock in itself is unsafe if you don't check for errors.
| This white bunny will stick around a bit, and see whether the grizzly bear
| will actually come up with a solution to the problem, or whether it will
| further degenerate into more personal putdowns.
Like yours? See below.
| I hope the first, but I fear
| the latter. Which is a shame, actually. Acquiring a lock for a file in
order
| to safely unlink it, that is, granted, not the world's most enticing
| problem;
No, it's a problem that springs from insufficient knowledge of file systems
and OS's. No Pelr involved.
| nor does this white bunny expect an enticing answer; just a normal
| one would do.
Well, you got an answer before.
<flame on>
Now, here is a little digest of your personal attacks against MJD.
MJD> One is what you mean by 'safe'. You never say what you think the
MJD> problem will be. You just say either 'it will not work' or 'it is
MJD> unsafe'.
M> I think I pretty much outlined what I meant with "safe": using the flock
M> mechanism to read/write to files.
You think? The people you are seeking answers from do not. Using flock in
combination with unlink is not sensible.
MJD> The other problem is the phrase 'in Perl'. You appear to be
MJD> describing a generic problem that is independent of language.
MJD>
MJD> All this makes me feel like I haven't gotten your point.
M> True enough.
MJD says you "appear to be" in order not to insult you by using definite
statements about your knowledge. You don't, however.
MJD> On Windows system, the delete operation will fail. On a Unix system,
MJD> the delete operation will succeed, and the file will be removed from
MJD> the file system, but its data will remain intact until the reading
MJD> process closes it.
M> Not entirely accurate. For starters, there is no "windows". Win9x, for
M> instance, does not support flock (Or, I should say: ActivePerl did not
M> support flock for Win9x, presumably because Win9x has no locking
mechanism.)
M> On WinXP, to my joy, this function is fully implemented. Furthermore, on
XP
M> the data also remains available for read, even if unlinked in-between.
And,
M> in XP, the unlink does not fail either.
There is no sense in talking about a flock-issue for an OS that doesn't
support flock. Therefore it was obvious that MJD was talking about win32's
which includes XP. Using "For starters" is like telling MJD he has no clue
about windoze. A personal attack. The truth is, he does, but does not care
about Windows.
M> You see, the problem you're not getting, is that the unlink works just
fine,
M> except that the "close (ARTICLE)" will make the file reappear again, as
if
M> it were never unlinked. You seem to be missing your own point: that data
M> remains available for read; hence, the "close (ARTICLE)" closes the file
as
M> if it were never deleted! Therefore, the problem: you can get a flock for
M> the file before you unlink it; but close the handle used to open the file
M> (to get the lock) and the file reappears again!
You did realize that you were wrong about the file reappearing. You said so.
But you telling MJD that he did not "get" the problem? Don't you feel
ashamed?
M> What you constantly fail to understand, is my point that requiring
M> a filehandle to lock, is not an action without consequence.
a) MJD never said it was without consequences.
b) He cannot possibly have "constantly" failed to understand something if he
only replied *once* to your post up to this time. It's an insult.
M> So, my point remains
You never had a *valid* point because you assumed something that isn't the
case: unlink/flock are related and they're Perl.
M> And you should try and grasp the nature of the problem before you say
there
M> is no problem. It works better that way.
Have you considered that *he* grasped the problem and you did not? After
all, *you* sought help. You got it, but could not bear that the help is the
subtle point that the problem is your misunderstanding of underlying
concepts.
M> to that quandary this white bunny has yet to hear a decent answer.
You got a decent answer. You did not understand it.
M> History will likely prove the white bunny right:
One cannot be right if one demonstrates cluelessness by asking a question
that does not make sense to be asked. It's like asking "Why does Windows not
behave like Unix?" And then state "They are both OS's, so they should behave
the same." In fact, you problem isn't far from that.
Enough. If you don't get it now, you won't ever. My sincere and honest
suggestion would be to either apologize (unlikely, that takes a *lot* of
self-control after your cheap attacks) or leave. The former would likely
result in the folks around here helping you with other problems again, the
latter...
Steffen
--
$_=q;0cb212c210b0bb010c0113bb0c410c0b516c0bb3d212c2b0b0b016b6cb2b2c21010c0
b41110b3bba0e0c0d2c4b2b6bc013d2c0d0b01012b0b0;;s/\n//g;s/(\d)/$1<2?$1:'0'x
$1/ge;s/([a-f])/'1'x(ord($1)-97)/ge;$o=$_;push@o,substr($o,$_*8,8) for(0..
24);for(@o){print"\0"x(26-$i).chr(oct('0b'.($_)))."\r";$i++};print"\n"#stm
------------------------------
Date: Thu, 22 Nov 2001 16:38:14 +0100
From: "Steffen Müller" <5l259r001@sneakemail.com>
Subject: Re: How can you do a safe unlink?
Message-Id: <9tj63a$ie9$05$1@news.t-online.com>
Sorry for posting this multiple times. My connection seemed screwed!
--
$_=q;0cb212c210b0bb010c0113bb0c410c0b516c0bb3d212c2b0b0b016b6cb2b2c21010c0
b41110b3bba0e0c0d2c4b2b6bc013d2c0d0b01012b0b0;;s/\n//g;s/(\d)/$1<2?$1:'0'x
$1/ge;s/([a-f])/'1'x(ord($1)-97)/ge;$o=$_;push@o,substr($o,$_*8,8) for(0..
24);for(@o){print"\0"x(26-$i).chr(oct('0b'.($_)))."\r";$i++};print"\n"#stm
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
The Perl-Users Digest is a retransmission of the USENET newsgroup
comp.lang.perl.misc. For subscription or unsubscription requests, send
the single line:
subscribe perl-users
or:
unsubscribe perl-users
to almanac@ruby.oce.orst.edu.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
To request back copies (available for a week or so), send your request
to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
where x is the volume number and y is the issue number.
For other requests pertaining to the digest, send mail to
perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
sending perl questions to the -request address, I don't have time to
answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V10 Issue 2182
***************************************
