Side effects on attribs on deleting a read-only hardlink

Discussion of bugs and problems found in Altap Salamander. In your reports, please be as descriptive as possible, and report one incident per report. Do not post crash reports here, send us the generated bug report by email instead, please.
wqweto
Posts: 19
Joined: 26 Jul 2010, 18:08

Side effects on attribs on deleting a read-only hardlink

Post by wqweto » 17 Feb 2016, 14:20

There is a a read-only file (e.g. under source control) and I make a hardlink to it with `c:\temp>mklink /h newname.txt c:\path\to\oldname.txt` so `c:\temp\newname.txt` hardlink inherits the read-only attribute which is an expected behavior.

When any of the `newname.txt` attributes are changed with File->Change Attributes (F2) command so are `oldname.txt` attributes and vice versa -- this is normal NTFS behavior.

Couple of issues with AS:
1. A minor one -- when both `c:\temp` and `c:\path\to` directories are open in AS, changing attributes on `newname.txt` in `c:\temp` is not reflected on `oldname.txt` in `c:\path\to` pane
2. A major one -- when deleting the `newname.txt` the attributes of `oldname.txt` get changed -- read-only attribute is cleared

I know why this happens but it's a very unexpected behavior.

Here is a blog entry on how to enumerate all the hardlinks for a file

https://blogs.msdn.microsoft.com/oldnew ... 0/?p=10103

cheers,
</wqw>

Petr Solin
ALTAP Staff
ALTAP Staff
Posts: 1110
Joined: 08 Dec 2005, 09:13
Location: Novy Bor, Czech Republic
Contact:

Re: Side effects on attribs on deleting a read-only hardlink

Post by Petr Solin » 17 Feb 2016, 16:38

Thanks for reporting this! I have tested with Explorer (in Windows 7) and TC and neither solves this problem. Salamander and TC clear more than only read-only (RO) attribute, Explorer clears only RO (other attributes are not changed), it's surely better behavior. Now I'll fix our code to clear also only RO. I will do more complex patch to fully fix this problem sometimes later, currently I'm afraid of slowdown of delete operation and do not want to spend time experimenting with this. Thanks for understanding!

wqweto
Posts: 19
Joined: 26 Jul 2010, 18:08

Re: Side effects on attribs on deleting a read-only hardlink

Post by wqweto » 17 Feb 2016, 17:34

Petr Solin wrote:. . . currently I'm afraid of slowdown of delete operation and do not want to spend time experimenting with this.
The hardlinks enumeration has the potential to slow down deletion of *read-only files only*, provided that there is no need to restore other attributes after deletion for writable files. Also, a possible optimization is to terminate enumeration just after the first alternative file is fetched -- should be enough to restore read-only attrib after the operation.

I'm wondering how can someone design a FS where file attributes are *not* part of the directory entry -- it's completely counter-intuitive. I don't even want to start researching what's the behavior of permissions ACLs with all the file hard/symbolic links, directory junctions and mount points scenarios.

cheers,
</wqw>

Petr Solin
ALTAP Staff
ALTAP Staff
Posts: 1110
Joined: 08 Dec 2005, 09:13
Location: Novy Bor, Czech Republic
Contact:

Re: Side effects on attribs on deleting a read-only hardlink

Post by Petr Solin » 17 Feb 2016, 20:11

Yes, only for read-only files, maybe only on local fixed NTFS drives, it has to be discovered, maybe later. :wink:

You can find some info in MSDN in documention for CreateHardLink function, section Remarks:
https://msdn.microsoft.com/en-us/librar ... 85%29.aspx

User avatar
Ether
Posts: 1459
Joined: 10 May 2007, 16:08
Location: Czech Republic
Contact:

Re: Side effects on attribs on deleting a read-only hardlink

Post by Ether » 05 Jul 2016, 16:53

Or skip the restrictive Win32 layer. :) ZwCreateFile
Ελληνικά rulez.

wqweto
Posts: 19
Joined: 26 Jul 2010, 18:08

Re: Side effects on attribs on deleting a read-only hardlink

Post by wqweto » 11 Apr 2019, 10:53

https://devblogs.microsoft.com/oldnewth ... /?p=102408 -- another useful article from theoldnewthing.

cheers,
</wqw>

Post Reply