Open ssubroda opened 4 years ago
Do you have a link to documentation describing the OS behavior change?
Hi, no I could not find anything concrete. However, Windows 10 1903 was one of the earlier versions to start offering better Linux Subsystem on Windows (LSW), and my guess is that making the file system more POSIX compliant means native Linux utilities will work more reliably. The POSIX requirements for unlink do actually state that it should unlink the file immediately (i.e. not show in directory listings etc.), when tested all prior versions of Windows do not do this and only remove the directory entry when the last handle is released. This basically means that until Windows 10 1903, unlink is not quite POSIX compliant.I am prepared to do some more digging into release notes if needed, but Microsoft do not always go into that much detail. Regards, David
On Wed, 22 Apr 2020, 10:20 pm Adam Mitz, notifications@github.com wrote:
Do you have a link to documentation describing the OS behavior change?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/DOCGroup/ACE_TAO/issues/1082#issuecomment-618046345, or unsubscribe https://github.com/notifications/unsubscribe-auth/API5Z6E74TYVLKTL5BPWHSDRN5NQDANCNFSM4MNK2HQQ .
Version
6.5.8
Host machine and operating system
Windows 10 (version 1903)
Target machine and operating system (if different from host)
Compiler name and version (including patch level)
Visual Studio 2017 15.9.7
The $ACE_ROOT/ace/config.h file
via vcpkg
The $ACE_ROOT/include/makeinclude/platform_macros.GNU file
via vcpkg
Contents of $ACE_ROOT/bin/MakeProjectCreator/config/default.features
via vcpkg
AREA/CLASS/EXAMPLE AFFECTED:
Change in behaviour of ACE::open_temp_file between Windows 10 1809 and Windows 10 1903
The problem effects:
It would affect any program that uses open_temp_file to create a (temporary) file in one process to signal to another process that the first process is still running. It does not affect the actual functioning of the first program - although checking for the presence of the file in the first process would also fail. This is a change in behaviour due to an OS change - not necessarily a bug in ACE - but may cause portability issues in otherwise standard ACE library usage..
Synopsis
The method ACE::open_temp_file (specifically the unlink call) does not exhibit the same behaviour when run on Windows 10 1903 as on previous Windows operating systems (XP, 2000, 7, 8, 8.1 and 10 up to 1809).
Description
In the function, ACE::open_temp_file, it calls unlink so the file can 'automagically' be deleted when the program exits. On Windows 10 1809 (and prior Windows versions), the file the method creates can be seen while the calling process continues to run. When the program exits, then this temporary file is deleted automatically. On Windows 10 1903, the file is removed as soon as the unlink call is made, hiding the file from other programs (for instance explorer.exe)
Repeat by
The behaviour can be seen by running a program that calls open_temp_file and continues to run (e.g. sleep(10000); on both of the affected operating systems.
Sample fix/ workaround
A partial fix is to use ACE_OS::open(, | O_TEMPORARY ) and not closing the returned handle, which will then be deleted when the program exits normally - it may not work if the program terminates abnormally.