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] |
On Nov 29 10:47, Michael Haubenwallner wrote: > 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 does, just not in terms of transactions. STATUS_SHARING_VIOLATION is not supposed to start a transaction. > NtOpenFile(FILE_SHARE_DELETE) succeeds even for a dll in use, > although a dll cannot be used while open with FILE_SHARE_DELETE. That's unfortunate. > 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? Well, if it does its job... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Attachment:
signature.asc
Description: PGP signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |