rmdir/del change read-only state of src hard links

Question

rmdir/del change read-only state of src hard links

Alec Miller 0

We have assets backed by Perforce that we need to duplicate into another folder hiearchy. To do this we use mklink /H to create hard links to the source files. Our makefile deletes this folder hierarchy every build, and relinks the files that are present. But I'm seeing that rmdir (or del) both change the read-only state of the source files when deleting the hard links. This then messes with Perforce's read-only tracking state, and it can't clobber the files as a result.

How is it that rmdir/del can't just delete the hardlink without modifying the attribute state?

This is on Win10.

Version 10.0.19045 Build 19045

Here's an easy repro. Create src/test.txt file and set it read-only. Then run this script 2x. Note that the rmdir changes the src/test.txt read-only state to false. That should not happen.

test.bat

rmdir /S /Q dst

mkdir dst

mklink test.txt ..\src.test\text.txt

Also why does mklink symlink creation fail for the same dual workingDir case that hard links only work for. This whole realtive to link also breaks any code that was using ln -s for posix. I don't have a path relative to the link, I just have the two folders of where the files are.

rem this succeeds, but has the read-only bug
rem mklink /H dst\test.txt src\test.txt

rem this succeeds, but creates an invalid link
rem mklink dst\test.txt src\test.txt

rem this works, but means a massive change to code using ln -s or mklink /H
rem mklink dst\test.txt ..\src\test.txt

Viorel 126.9K Reputation points

2023-09-02T07:44:49.6+00:00

Maybe you should implement your own “rmdir”, which enumerates and tries to delete files. If a file is read-only and cannot be deleted, then probably FindFirstFileName can be used to keep a link to restore the read-only attribute.
Alec Miller 0 Reputation points

2023-09-06T18:44:55.0166667+00:00

Good idea. Seems like that would work, since it doesn't matter which hard link so long as it's not the one about to be deleted.

Another idea is just to make a mklink replacement that can take 2 working directory relative paths, instead of a working and symlink relative path like mklink currently does.
Alec Miller 0 Reputation points

2023-09-08T16:38:04.4033333+00:00

I think we have to move to symbolic links. Explorer has the same bug.

3 answers

Your answer

Viorel 126.9K Reputation points

2023-09-02T07:44:49.6+00:00

Maybe you should implement your own “rmdir”, which enumerates and tries to delete files. If a file is read-only and cannot be deleted, then probably FindFirstFileName can be used to keep a link to restore the read-only attribute.
Alec Miller 0 Reputation points

2023-09-06T18:44:55.0166667+00:00

Good idea. Seems like that would work, since it doesn't matter which hard link so long as it's not the one about to be deleted.

Another idea is just to make a mklink replacement that can take 2 working directory relative paths, instead of a working and symlink relative path like mklink currently does.
Alec Miller 0 Reputation points

2023-09-08T16:38:04.4033333+00:00

I think we have to move to symbolic links. Explorer has the same bug.

Answer 1

This is even worse.

Create a file test.txt and make it read-only
Create a folder test
mklink /H test\test.txt test.txt
delete test folder from Explorer
test.txt is still read-only
Empty recycle bin
test.txt is no longer read-only

So this bug exists in Explorer as well. I have a custom tool to search and delete a hardlink and restore read-only state to one of the other hardlinks. Unfortunately, this also finds any hardlinks in the recycle bin.

So this is something Microsoft has to fix. This totally breaks use of read-only state, and the way Perforce identifies changed files.

Answer 2

Alec Miller 0

Also since this is rmdir/del recursively wiping out the source read-only state, that makes it hard since we'd have to preserve the read-only state of all files prior to the call, and then restore the state. Some content is checked out and not read-only. This is a pretty horrible bug that seems to have been in rmdir/del for years.

MotoX80 37,681 Reputation points

2023-09-09T01:00:25.7+00:00
we'd have to preserve the read-only state of all files prior to the call, and then restore the state.

That should be fairly easy with Powershell. You just need to point the Get-Childitem to the correct path.

Get-ChildItem -Path TestFldr -Recurse -File -Attributes readonly | foreach { 'attrib.exe +r "{0}"' -f $_.fullname } | Out-File SaveRead.bat -Encoding ascii"

And then call SaveRead.bat to reset the attribute on the files.
Alec Miller 0 Reputation points

2023-09-09T22:18:17.42+00:00
Not sure how that would work. The folder and files are destroyed and recreated every frame. I just recurse the folder, find a hardlink with count > 1, and set the state of any other hardlink back after deleting the file. That seems to work, but this feels like something Microsoft should fix and users shouldn't suffer.

There are 2 options:

fix rmdir and del to preserve the read-only state of hardlinks > 1 link.

Allow read-only hardlinks to be deleted without changing their read-only state.
MotoX80 37,681 Reputation points

2023-09-10T12:52:31.6766667+00:00

Powershell's New-Item can create an -ItemType HardLink.

https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/new-item?view=powershell-5.1

See if that has different behavior.

Answer 3

Alec Miller 0

Sorry typo in the script above.

rmdir /S /Q dst
mkdir dst

mklink dst\test.txt ..\src\text.txt

Alec Miller 0 Reputation points

2023-08-29T23:29:41.8333333+00:00

And this is the hardlink version that fails to preserve read-only state of the src files. Note the difference in syntax of the second src\text.txt arg.

rmdir /S /Q dst
mkdir dst

mklink /H dst\test.txt src\text.txt

Share via

rmdir/del change read-only state of src hard links

3 answers

Your answer