Microsoft's "fsutil hardlink create" command requires that the user is a
member of Administrators -- and spews out a meaningless confirmation.

The administrator requirement is a severe security risk because it
forces the programmer to be logged on as administrator. Perhaps some
idiot at Microsoft thought this severe risk was a reasonable price to
pay to avoid the microscopic risk of possibly not finding some specific
file name in the audit trail (because the file was accessed via some
other hardlink than the one searched for). Whatever the unreason for
the restriction, I'd like hardlink creation that doesn't require being
logged on as administrator.

The Windows 2000 CreateHardLink API function isn't documented as
requiring administrator account, but failed for non-administrator user
(system: Windows XP Professional).

Reaching down in my old toolbox I then tried BackupWrite, but while that
works fine for administrator accounts it fails for non-administrators
with error code 2 "The system cannot find the file specified.", even
when the user in question is a member of Backup Operators.

How can I get around this unreasonable restriction?

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Alf P. Steinbach wrote:

It should not require administrator privileges, only write access to the
directory where the new link is created and when I test it right now I
can use it when running under an ordinary user account.

BackupWrite() seams to have problems creating links in some cases. I
don't know exactly in which cases but I have found out that in some
directories it always fails with error code 2 (even for administrators).
The solution for me have been to use CreateHardLink() or
NtSetInformationFile() instead.

--
Olof Lagerkvist
ICQ: 724451
Web: http://here.is/olof

* Olof Lagerkvist:
Thanks.

I discovered now that it also requires access to change attributes of
the file linked to, even if the attributes aren't actually changed.

Which shouldn't have suprised me because that was the access I specified
when using BackupWrite, except, that as I recall CreateFile then
succeeded in opening the file... But I don't want to take the time to
test that again. Perhaps I recall incorrectly.

Btw., I discovered now also that CreateHardLink in Windows XP is happy
with \\?\ paths, at least for the source, which my notes from
very-long-ago said it didn't accept in Windows 2000.

X:\> whoami
SPRINGFLOWER\Student

X:\> cacls ln.exe
X:\ln.exe BUILTIN\Administrators:F
NT AUTHORITY\SYSTEM:F
SPRINGFLOWER\Alf:F
BUILTIN\Users:R

X:\> ln ln.exe qwerty.uio
!CreateHardLink failed

X:\> copy ln.exe a.exe >nul

X:\> cacls a.exe
X:\a.exe BUILTIN\Administrators:F
NT AUTHORITY\SYSTEM:F
SPRINGFLOWER\Student:F
BUILTIN\Users:R

X:\> ln a.exe qwerty.uio

X:\> qwerty.uio
!Usage: ln EXISTINGNAME NEWNAME

X:\> _

Just for the record, the above CreateHardLink failure is not because
it's trying to create a link to a running program; using ln to create a
link to itself works just fine, when the user has the required rights.

So, we have a situation where you can freely copy a file, but can't link
to it... :-(


I haven't used NtSetInformationFile: does that solve the above, do you
think?

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

cygwin has a ln tool, that can do symbilic links (junktion points) on
NTFS I think. Did you try that and look at the code?

Alf P. Steinbach wrote:

The file must be opened with FILE_WRITE_ATTRIBUTES access, correct. The
FILE_WRITE_ATTRIBUTES access is not only used to change file attributes,
it is required to change other filesystem information about the file,
such as file modification times etc, and in this case, to create a new
link to the file.

It should work on all versions because the names are in all cases
translated to native paths using RtlDosPathNameToNtPathName_U() function.

Yes because you need more than read access to create a new link, you
need access to write attributes. Copy only requires read access. Both
operations require write access to the directory where the link is created.

No.

--
Olof Lagerkvist
ICQ: 724451
Web: http://here.is/olof