forkables: About hardlink creation and NTFS transaction in rename()
Tue Nov 29 13:47:00 GMT 2016
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.
It turns out that when NTFS transactions are involved with the dll,
creating a hardlink requires the FILE_WRITE_ATTRIBUTES access.
Strange enough, this also applies when the file handle used to create
the hardlink is opened _after_ the rename transaction has finished.
On the other hand, opening the file handle with FILE_WRITE_ATTRIBUTES
access _before_ the rename(), the transactional unlink_nt fails with
> Now I can see these options:
> * As using NTFS transactions seems not to be recommended any more,
> might we drop the NTFS transaction from rename() and _unlink_nt ()?
> * Or do I need to create an NTFS-transaction in dll_list::alloc()
> when opening the original dll file handle?
some more now:
* Just for creating the hardlink open the file by id, determined
in dll_list::alloc(), with immediately closing the file handle.
However, I've not managed yet to open a file by id...
* When checking for, hardlinks are needed when the MemorySectionName
resolves different than the (Get)ModuleFileName, and just for
creating the hardlink open the file by current MemorySectionName.
More information about the Cygwin-developers