forkables: About hardlink creation and NTFS transaction in rename()
Thu Nov 24 08:45:00 GMT 2016
On Nov 23 10:08, Michael Haubenwallner wrote:
> 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
No, it's one and the same.
> 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.
I know. The question is why was FILE_ATTRIBUTE_READONLY set at all?
There's no good reason for that, unless you're on a "noacl" mount and
the file permissions are set to R/O for the supposed owner. In theory
those files should be left alone anyway.
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: not available
More information about the Cygwin-developers