The drive doesn’t have a say. The permissions surrounding the TrustedInstaller account have a say. The account existed on your first Windows install and also on your new one hence the permissions and associated restrictions persevere. This is expected behavior.
And prevents people from doing stupid things, as well as prevents malware running under administrator permissions from doing malware things (see also; people doing stupid things).
ACL’s are an integral part of most filesystems.
So yes the drive absolutely has a say in this (technically the NTFS filesystem) in combination with the OS’s filesystem driver.
The Windows folder is set to be owned by the TrustedInstaller SID (S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464) which is a “well known” Security Identifier.
This identifier is the same accross Windows systems in a similar way root is UID 0 on Linux.
Therefore the access rights for TrustedInstaller persists across Windows installs, and also other rights that are defined on the filesystem object.
Linux uses mainly POSIX ACL which is “fairy simple”, while NTFS ACL can be very complex.
Should also note that the the UNIX and UNIX-like world there is also NFSv4 ACL which is comparable to NTFS ACL.
But the basic idea persists across almost all filesytem ACL.
The user that is running the command must have the right user ID (that is UID/GID in Linux and SID in Windows) that has the correct access rights to do the action you want.
With Windows administrator rights you can indeed delete everything if you really want.
But then you have to give your administrator account the right access tokens or you need to impersonate the account in question (both of which are possible if you have an local administrator account, but does require the techincal know-how).
In Windows a lot of these things are in place both to prevent users from shooting themselves in the foot, but also to provide defence-in-depth against malware.
That’s really bad logic and you’re missing the point here. trusted installer is the owner of the folder. The fact that it’s an old windows drive or that your an admin makes absolutely no difference. It’s a file system ACL, those ACLs don’t just magically disappear from the drive when it’s no longer the system drive.
Take ownership of the folder, add your account or the everyone security identifier with full access permissions and then delete it.
I’m sorry to say this but the fact that you’re complaining about this is more a reflection on your lack of understanding of how file system ACLs work, in any OS, than anything else.
The braincells were not there to begin with, you didn’t lose them. <= that’s a joke, I’m not trying to be mean.
but i am administrator on this computer
How is Windows in the 2nd drive supposed to know that?
the drive shouldnt have a say in the first place…
The drive doesn’t have a say. The permissions surrounding the TrustedInstaller account have a say. The account existed on your first Windows install and also on your new one hence the permissions and associated restrictions persevere. This is expected behavior.
its very annoying and wastes time
Insecurity is annoying too 🤷♂️
And prevents people from doing stupid things, as well as prevents malware running under administrator permissions from doing malware things (see also; people doing stupid things).
¯(ツ)/¯
Then why does it matter that your an admin if the drive should have no say?
because a non administrator shouldnt be able to mount drives and other admin operations. an admin should be able to do anything on that machine
ACL’s are an integral part of most filesystems.
So yes the drive absolutely has a say in this (technically the NTFS filesystem) in combination with the OS’s filesystem driver.
The Windows folder is set to be owned by the TrustedInstaller SID (S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464) which is a “well known” Security Identifier.
This identifier is the same accross Windows systems in a similar way root is UID 0 on Linux.
Therefore the access rights for TrustedInstaller persists across Windows installs, and also other rights that are defined on the filesystem object.
Linux uses mainly POSIX ACL which is “fairy simple”, while NTFS ACL can be very complex.
Should also note that the the UNIX and UNIX-like world there is also NFSv4 ACL which is comparable to NTFS ACL.
But the basic idea persists across almost all filesytem ACL.
The user that is running the command must have the right user ID (that is UID/GID in Linux and SID in Windows) that has the correct access rights to do the action you want.
With Windows administrator rights you can indeed delete everything if you really want.
But then you have to give your administrator account the right access tokens or you need to impersonate the account in question (both of which are possible if you have an local administrator account, but does require the techincal know-how).
In Windows a lot of these things are in place both to prevent users from shooting themselves in the foot, but also to provide defence-in-depth against malware.
You can do anything, you just need to own the files first.
Removed by mod
Linux is exactly the same for file access. Unless you run your session as root, which is a bad idea.
That’s really bad logic and you’re missing the point here. trusted installer is the owner of the folder. The fact that it’s an old windows drive or that your an admin makes absolutely no difference. It’s a file system ACL, those ACLs don’t just magically disappear from the drive when it’s no longer the system drive.
Take ownership of the folder, add your account or the everyone security identifier with full access permissions and then delete it.
I’m sorry to say this but the fact that you’re complaining about this is more a reflection on your lack of understanding of how file system ACLs work, in any OS, than anything else.
The braincells were not there to begin with, you didn’t lose them. <= that’s a joke, I’m not trying to be mean.
Removed by mod
Lol, you’ve got such a good sens of humour. Hope you have a good day today.
You have to right click Explorer when you open it to open it as an admin.