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/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/


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