Bug #81259 [Asn->Wfx]: Long execution causes unlink function to give wrong result
Edit report at https://bugs.php.net/bug.php?id=81259&edit=1
ID: 81259
Updated by: cmb@php.net
Reported by: raincomplain at outlook dot com
Summary: Long execution causes unlink function to give wrong
result
-Status: Assigned
+Status: Wont fix
Type: Bug
Package: Filesystem function related
Operating System: Windows
PHP Version: 8.0
Assigned To: cmb
Block user comment: N
Private report: N
New Comment:
> I think the handle should be closed by PHP on behalf of the
> programmer right before unlinking since the only process that owns
> the file is PHP itself.
Besides that that's hard to accomplish (we would need to keep a
map of file names to open file handles per process/thread), the
semantics would be even more unexpected. It seems to be way
easier to keep track of that in the application, if even needed.
Previous Comments:
------------------------------------------------------------------------
[2021-07-16 03:31:04] raincomplain at outlook dot com
From Windows OS point of view it makes sense when a process wants to delete a file to put that file
in a delete-pending state if it's opened by another process. However, it doesn't make
sense for PHP to still keeps a handle open if the file in question is to be deleted. I think the
handle should be closed by PHP on behalf of the programmer right before unlinking since the only
process that owns the file is PHP itself. We then should worry only about other things like Windows
indexing service or antiviruses that might have a hold on that file at that particular moment of
time which if you ask me I don't think it's something to be worried about.
------------------------------------------------------------------------
[2021-07-15 13:18:36] cmb@php.net
The respective changes in PHP 7.3 are an attempt to more closely
match POSIX semantics regarding unlinking of files. On Windows,
unlinking is not possible if there are open file handles, so
putting the file in a delete-pending state is the closest
equivalent, and that means that the file will be deleted after the
last handle to it has been closed, and it is no longer possible to
access the file in any way (permission denied). It seems to me
that under this semantics having unkink() returning true is
actually correct â this still allows to check whether the file was
put in delete-pending state or not.
However, files in delete-pending state behave pretty inconsistently
wrt. other file functions; while file_exist() and friends return
false, scandir() and friends still report the file to be there. If
we were putting the file in delete-on-close state, the results of
these functions would be consistent (file_exist() and friends would
return true), but even if it is possible to implement that, the
file will eventually move to the delete-pending state, and the
inconsistency would show up again.
I'm not sure what to do here. unlink()ing by putting the file in
the delete-pending state appears generally more useful than just
letting the unlink() attempt fail, so we likely will not revert
this (besides that it is a bit late; PHP 7.3.0 was released more
than 30 months ago). Fixing the inconsistencies between
file_exists() and scandir() is likely not possible (or worth the
trouble). So it might be best to clearly document the exact
behavior.
Still, it seems to me there is no (clean) way to detect whether a
file is in delete-pending state, and at least that appears to be
an unfortunate omission. If such a function was available,
userland code could do something like
if (unlink('data.txt') && !file_is_delete_pending('data.txt)) {
fopen('data2.txt', 'w');
}
From what I can tell, writing such a function in C should be
possible and not too hard.
Further reading: <https://go.microsoft.com/fwlink/?LinkId=140636>
(particularly chapter 4, File deletion semantics).
------------------------------------------------------------------------
[2021-07-15 12:42:33] raincomplain at outlook dot com
8.0
------------------------------------------------------------------------
[2021-07-15 11:57:56] raincomplain at outlook dot com
Tested on 7.3 and 8
------------------------------------------------------------------------
[2021-07-15 11:55:49] raincomplain at outlook dot com
This bug started at 7.3 and is reproducible in version 8
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=81259
--
Edit this bug report at https://bugs.php.net/bug.php?id=81259&edit=1
Thread (9 messages)