forkables: About hardlink creation and NTFS transaction in rename()
Michael Haubenwallner
michael.haubenwallner@ssi-schaefer.com
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
STATUS_TRANSACTIONAL_CONFLICT.
> 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.
> Thoughts?
Thanks!
/haubi/
More information about the Cygwin-developers
mailing list