10 out of 10 rated this helpful Rate this topic

CreateHardLink function

Establishes a hard link between an existing file and a new file. This function is only supported on the NTFS file system, and only for files, not directories.

To perform this operation as a transacted operation, use the CreateHardLinkTransacted function.

Syntax

BOOL WINAPI CreateHardLink(
  __in        LPCTSTR lpFileName,
  __in        LPCTSTR lpExistingFileName,
  __reserved  LPSECURITY_ATTRIBUTES lpSecurityAttributes
);

Parameters

lpFileName [in]

The name of the new file.

This parameter cannot specify the name of a directory.

lpExistingFileName [in]

The name of the existing file.

This parameter cannot specify the name of a directory.

lpSecurityAttributes

Reserved; must be NULL.

Return value

If the function succeeds, the return value is nonzero.

If the function fails, the return value is zero (0). To get extended error information, call GetLastError.

The maximum number of hard links that can be created with this function is 1023 per file. If more than 1023 links are created for a file, an error results.

Remarks

Any directory entry for a file that is created with CreateFile or CreateHardLink is a hard link to an associated file. An additional hard link that is created with the CreateHardLink function allows you to have multiple directory entries for a file, that is, multiple hard links to the same file, which can be different names in the same directory, or the same or different names in different directories. However, all hard links to a file must be on the same volume.

Because hard links are only directory entries for a file, many changes to that file are instantly visible to applications that access it through the hard links that reference it. However, the directory entry size and attribute information is updated only for the link through which the change was made.

The security descriptor belongs to the file to which a hard link points. The link itself is only a directory entry, and does not have a security descriptor. Therefore, when you change the security descriptor of a hard link, you a change the security descriptor of the underlying file, and all hard links that point to the file allow the newly specified access. You cannot give a file different security descriptors on a per-hard-link basis.

This function does not modify the security descriptor of the file to be linked to, even if security descriptor information is passed in the lpSecurityAttributes parameter.

Use DeleteFile to delete hard links. You can delete them in any order regardless of the order in which they are created.

Flags, attributes, access, and sharing that are specified in CreateFile operate on a per-file basis. That is, if you open a file that does not allow sharing, another application cannot share the file by creating a new hard link to the file.

When you create a hard link on the NTFS file system, the file attribute information in the directory entry is refreshed only when the file is opened, or when GetFileInformationByHandle is called with the handle of a specific file.

Symbolic link behavior—If the path points to a symbolic link, the function creates a hard link to the target.

Examples

The following code snippet shows you how to call CreateHardLink so that it does not modify the security descriptor of a file. The pszExistingFileName parameter can be the original file name, or any existing link to a file. After this code is executed, pszNewLinkName refers to the file.


  BOOL fCreatedLink = CreateHardLink( pszNewLinkName, 
                                      pszExistingFileName, 
                                      NULL ); // reserved, must be NULL

  if ( fCreatedLink == FALSE )
   {
    ;// handle error condition
   }


Requirements

Minimum supported client

Windows XP

Minimum supported server

Windows Server 2003

Header

WinBase.h (include Windows.h)

Library

Kernel32.lib

DLL

Kernel32.dll

Unicode and ANSI names

CreateHardLinkW (Unicode) and CreateHardLinkA (ANSI)

See also

CreateFile
CreateHardLinkTransacted
DeleteFile
File Management Functions
Hard Links and Junctions
Symbolic Links

 

 

Send comments about this topic to Microsoft

Build date: 9/10/2011

Did you find this helpful?
(2000 characters remaining)
Community Content Add
Annotations FAQ
lpExistingFileName remains relative
- double post -
if lpExistingFileName is relative, target remains relative
Whatever path is specified as lpExistingFileName will remain as the target path even if it is relative. This can create undesired and unexpected behaviour when specifying relative paths, for example:
If you wish to create a link to "X:\a\b.txt" as "X:\y\z.txt" and your current directory is "X:\a\", then specifying relative path "b.txt" as lpExistingFileName will not link to "X:\a\b.txt" but in fact create a link with target "X:\y\b.txt" (which does not exist).
Delete Existing File
Hello,

After deleting the existing file, the hardlink still is able to open the file which was already deleted.

Is it correct?

Regards,
lpFileName cannot name an existing file
It should be noted that lpFileName cannot name an existing file, in other words, an attempt to create a hardlink with a name of an existing file (whether or not it is a hardlink) will fail (i.e. it will not overwrite files).
problem

when i use this function, it actually copie the whole file, not just create the shortcut,
any idea what will cause it..?


[tfl - 28 08 09] Hi - and thanks for your post. You should post questions like this to the MSDN Forums at http://forums.microsoft.com/msdn or the MSDN Newsgroups at

http://www.microsoft.com/communities/newsgroups/en-us/ . You are much more likely get a quicker response using the forums than through the Community Content. For specific help about:
Visual Studio :
http://groups.google.com/groups/dir?sel=usenet%3Dmicrosoft.public.vstudio%2C &
SQL Server :
http://groups.google.com/groups/dir?sel=usenet%3Dmicrosoft.public.sqlserver%2C &
.NET Framework :
http://groups.google.com/groups/dir?sel=usenet%3Dmicrosoft.public.dotnet.framework
PowerShell : http://groups.google.com/group/microsoft.public.windows.powershell/topics?pli=1
All Public : http://groups.google.com/groups/dir?sel=usenet%3Dmicrosoft.public%2C &

Bug
This method does not work if the file and link are on different disk parititons.

-- Answer by J Ross, Malta:

Not a bug!

It specifically states above: " However, all hard links to a file must be on the same volume.", otherwise the functionality is compromised if the drive holding the actual data were to be removed.

As far as I know volume refers to a logical drive (partition, for example F:\) and not a physical drive (for example \\.\PhysicalDisk0)

Possibly bug
On links created with this method GetShortPathName returns an unchanged file name ,even if it does not fit in 8.3 format; FindFirst/NextFile also leaves WIN32_FIND_DATA::cAlternateFileName clear.

The reason: CreateHardLink creates names in the POSIX namespace of NTFS, while other file APIs make names in the Win32 namespace.

Usual behavior: when a name is not in 8.3 format and the system policy on creating short names is enabled, system makes the second name in the DOS namespace for the file; however this does not happen with CreateHardLink.

Is this a bug?


See also
To retrieve the number of hard links of a file, use the GetFileInformationByHandle function: http://msdn2.microsoft.com/en-us/library/aa364952(VS.85).aspx