Re: (tye)Re: Self Deletion

I checked Bleach.pm and find that it does overwrite the existing script contents (which is what I expected). Perl having the script file open doesn't prevent this from happening.

You mean opening $0 for writing will overwrite the existing file's contents, and although Perl may still have it open, the way it was opened doesn't prevent it from being opened for writing (at least by the same process or same security context). I suppose that the normal ">" mode of Perl truncates the file to zero length.

But, in Win32, the deleting of a file is prohibited if it's open at all, regardless of what sharing modes are specified.

In my experience of saving changes to a PM while it was still running, when the editor saves by writing to a temp file first, then if successful deleting the old and renaming the new, would fail if __DATA__ was being used. The fact that it may close or leave open, depending, explains differing observations on the subject. I thank you for sheding light on this.

So you might have to chdir("..") under Win32 and even that might not be enough.

It should be enough, unless spawned tasks are still using it. It's enough for that script.

Then again, under Win32 you can also use Win32API::File to request that files/directories that are currently in use be deleted during the next reboot.

The mechanism is totally different for NT/2000 than it is for Win 3.1/95/98/ME. The function in Win32API::File is only present on the former.

Finally, the reason that you can't delete the Perl script while Perl still has it open is because the C run-time library under Win32 defaults to specifying sharing of "rw" and not "rwd". I wish they had opted for "rwd", but my time machine is still broken.

Are you sure that's possible on Win32? If it's just a matter of the defaults passed to the underlying functions, you could change the Perl source.

—John

Comment on Re: (tye)Re: Self Deletion

Replies are listed 'Best First'.
(tye)Re2: Self Deletion by tye (Sage) on Jul 08, 2001 at 10:43 UTC
You mean opening $0 for writing will overwrite the existing file's contents, and although Perl may still have it open, the way it was opened doesn't prevent it from being opened for writing (at least by the same process or same security context). Yes. And, no, some other process in a different security context could do exactly the same thing unless you went out of your way to prevent it. But, in Win32, the deleting of a file is prohibited if it's open at all, regardless of what sharing modes are specified. No, the C RTL opens files in such a way that no one (not even you) is allowed to delete them until you close them. You can easily open files such that they can be deleted but you have to not use C's fopen() if you want that. It should be enough, unless spawned tasks are still using it. It's enough for that script. Actually, I was thinking that if one managed to launch the script then in most cases one would have either a shell or Explorer with that directory open. But if the script (or the automated process that launched the script) was also what created the directory, then you have better odds. The mechanism is totally different for NT/2000 than it is for Win 3.1/95/98/ME. The function in Win32API::File is only present on the former. True. Thanks, I'd forgotten that. Are you sure [deleting an open file(?) is] possible on Win32? If it's just a matter of the defaults passed to the underlying functions, you could change the Perl source. Yes, I'm sure. See Win32API::File for more on how. You have to modify Win32 Perl to not use the C RTL's fopen(). Win32 Perl already replaces several bits of the C RTL with its own (because of bugs in common C RTLs) so it could roll its own fopen() as well in order to "fix" this. Hmm... I just noticed that Win32 Perl's implementation of utime() won't work on a file if anyone has it open for writing (perhaps there would be no point?). It looks like Win32 Perl's stat won't work reliably on files that are currently opened by anyone. I blame these problems on Microsoft making you type `FILE_SHARE_READ\|FILE_SHARE_WRITE\|FILE_SHARE_DELETE` in order to be sharing but only `0` in order to be stingy. - tye (but my friends call me "Tye")	[reply] [d/l] [select]

Replies are listed 'Best First'.

(tye)Re2: Self Deletion
by tye (Sage) on Jul 08, 2001 at 10:43 UTC

You mean opening $0 for writing will overwrite the existing file's contents, and although Perl may still have it open, the way it was opened doesn't prevent it from being opened for writing (at least by the same process or same security context).

Yes. And, no, some other process in a different security context could do exactly the same thing unless you went out of your way to prevent it.

But, in Win32, the deleting of a file is prohibited if it's open at all, regardless of what sharing modes are specified.

No, the C RTL opens files in such a way that no one (not even you) is allowed to delete them until you close them. You can easily open files such that they can be deleted but you have to not use C's fopen() if you want that.

It should be enough, unless spawned tasks are still using it. It's enough for that script.

Actually, I was thinking that if one managed to launch the script then in most cases one would have either a shell or Explorer with that directory open. But if the script (or the automated process that launched the script) was also what created the directory, then you have better odds.

The mechanism is totally different for NT/2000 than it is for Win 3.1/95/98/ME. The function in Win32API::File is only present on the former.

True. Thanks, I'd forgotten that.

Are you sure [deleting an open file(?) is] possible on Win32? If it's just a matter of the defaults passed to the underlying functions, you could change the Perl source.

Yes, I'm sure. See Win32API::File for more on how. You have to modify Win32 Perl to not use the C RTL's fopen(). Win32 Perl already replaces several bits of the C RTL with its own (because of bugs in common C RTLs) so it could roll its own fopen() as well in order to "fix" this. Hmm...

I just noticed that Win32 Perl's implementation of utime() won't work on a file if anyone has it open for writing (perhaps there would be no point?). It looks like Win32 Perl's stat won't work reliably on files that are currently opened by anyone. I blame these problems on Microsoft making you type FILE_SHARE_READ|FILE_SHARE_WRITE|FILE_SHARE_DELETE in order to be sharing but only 0 in order to be stingy.

tye

[reply]
[d/l]
[select]