Bug #81259 [Asn]: Long execution causes unlink function to give wrong result

Edit report at https://bugs.php.net/bug.php?id=81259&edit=1 ID: 81259 User updated by: raincomplain at outlook dot com Reported by: raincomplain at outlook dot com Summary: Long execution causes unlink function to give wrong result Status: Assigned 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: 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. Previous Comments: ------------------------------------------------------------------------ [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 ------------------------------------------------------------------------ [2021-07-15 11:45:18] rtrtrtrtrt at dfdfdfdf dot dfd https://www.php.net/supported-versions.php ------------------------------------------------------------------------ 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