forkables: About hardlink creation and NTFS transaction in rename()

Michael Haubenwallner
Tue Nov 29 09:47:00 GMT 2016

On 11/28/2016 10:47 AM, Corinna Vinschen wrote:
> On Nov 25 15:03, Michael Haubenwallner wrote:
>> On 11/21/2016 04:19 PM, Michael Haubenwallner wrote:
>>> Hi Corinna,
>>> now working with the cygfork patches (hardlinks to retain forkability
>>> beyond exe/dll update): when creating the forkable hardlink using the
>>> earlier opened file handle I may get STATUS_TRANSACTION_NOT_ACTIVE.
>>> It turns out that when loaded 'some.dll' was readonly, then
>>> rename("new/some.dll", "some.dll") uses an NTFS-transaction to drop
>>> the readonly attribute, breaking the subsequent hardlink creation
>>> of "/var/run/cygfork/.../soname.dll" via the original file handle.
>> I've been wrong here about the readonly flag:
>> The transaction is started in rename() where the initial
>> NtSetInformationFile (Rename) returns STATUS_ACCESS_DENIED,
>> simply because the target "some.dll" is in use.
> No, wait.  If the DLL is in use, the return code should be

Hmm, no:
In rename() the first try for NtSetInformationFile(FileRenameInformation)
Also, rename() won't handle STATUS_SHARING_VIOLATION right now.

It is unlink_nt() that would handle STATUS_SHARING_VIOLATION, but
NtOpenFile(FILE_SHARE_DELETE) succeeds even for a dll in use,
although a dll cannot be used while open with FILE_SHARE_DELETE.

Anyway: Looking at the /proc/pid/maps handler I've learned that
NtQueryVirtualMemory(hmodule, MemorySectionName) yields the current
dll's filename (as \Device\HarddiskVolume...) - even after renaming,
at least on Server 2012r2.

So for creating the hardlink I could open the current MemorySectionName,
rather than early open the GetModuleFileNameW(), so I won't be affected
by rename's transaction at all.

But what do you think about NtQueryVirtualMemory(MemorySectionName) here?


More information about the Cygwin-developers mailing list