This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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
> STATUS_SHARING_VIOLATION.

Hmm, no:
In rename() the first try for NtSetInformationFile(FileRenameInformation)
returns STATUS_ACCESS_DENIED.
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?

/haubi/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]