This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: forkables: About hardlink creation and NTFS transaction in rename()
On 11/22/2016 06:22 PM, Corinna Vinschen wrote:
> On Nov 21 16:19, 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.
>
> Do not use the DOS R/O attribute on non-FAT in a POSIX context. Only
> Cygwin symlinks of the Windows shortcut type should do that, and then
> only for historical reasons. And don't get me started how bad an idea
> Windows shortcut symlinks were in the first place...
While I have not checked yet why the FILE_ATTRIBUTE_READONLY is set:
Is there a difference between the "DOS R/O attribute" and the pc.attribute
FILE_ATTRIBUTE_READONLY?
Combined with FILE_SUPPORTS_TRANSACTIONS this triggers start_transaction()
in rename() in syscalls.cc, breaking the previously opened file handle.
And there are no symlinks involved - I'm talking about hardlinks here.
What am I missing?
/haubi/