Bug #81259 [Opn]: 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: Open Type: Bug Package: Filesystem function related Operating System: Windows PHP Version: 8.0 -Assigned To: +Assigned To: cmb Block user comment: N Private report: N New Comment: 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). Previous Comments: ------------------------------------------------------------------------ [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 ------------------------------------------------------------------------ [2021-07-15 11:42:36] raincomplain at outlook dot com Version 7.3 ------------------------------------------------------------------------ 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