Underneath the file system, files are represented by inodes. (Or is it multiple inodes? Not sure.)
A file in the file system is basically a link to an inode.
A hard link, then, just creates another file with a link to the same underlying inode.
When you delete a file, it removes one link to the underlying inode. The inode is only deleted (or deletable/over-writable) when all links to the inode have been deleted.
A symbolic link is a link to another name in the file system.
Once a hard link has been made the link is to the inode. Deleting, renaming, or moving the original file will not affect the hard link as it links to the underlying inode. Any changes to the data on the inode is reflected in all files that refer to that inode.
Note: Hard links are only valid within the same File System. Symbolic links can span file systems as they are simply the name of another file.
Since there is so much confusion about functionality of standard service accounts, I'll try to give a quick run down.
First the actual accounts:
LocalService account (preferred)
A limited service account that is very similar to Network Service and meant to run standard least-privileged services. However, unlike Network Service it accesses the network as an Anonymous user.
- Name:
NT AUTHORITY\LocalService
- the account has no password (any password information you provide is ignored)
- HKCU represents the LocalService user account
- has minimal privileges on the local computer
- presents anonymous credentials on the network
- SID: S-1-5-19
- has its own profile under the HKEY_USERS registry key (
HKEY_USERS\S-1-5-19
)
NetworkService account
Limited service account that is meant to run standard privileged services. This account is far more limited than Local System (or even Administrator) but still has the right to access the network as the machine (see caveat above).
NT AUTHORITY\NetworkService
- the account has no password (any password information you provide is ignored)
- HKCU represents the NetworkService user account
- has minimal privileges on the local computer
- presents the computer's credentials (e.g.
MANGO$
) to remote servers
- SID: S-1-5-20
- has its own profile under the HKEY_USERS registry key (
HKEY_USERS\S-1-5-20
)
- If trying to schedule a task using it, enter
NETWORK SERVICE
into the Select User or Group dialog
LocalSystem account (dangerous, don't use!)
Completely trusted account, more so than the administrator account. There is nothing on a single box that this account cannot do, and it has the right to access the network as the machine (this requires Active Directory and granting the machine account permissions to something)
- Name:
.\LocalSystem
(can also use LocalSystem
or ComputerName\LocalSystem
)
- the account has no password (any password information you provide is ignored)
- SID: S-1-5-18
- does not have any profile of its own (
HKCU
represents the default user)
- has extensive privileges on the local computer
- presents the computer's credentials (e.g.
MANGO$
) to remote servers
Above when talking about accessing the network, this refers solely to SPNEGO (Negotiate), NTLM and Kerberos and not to any other authentication mechanism. For example, processing running as LocalService
can still access the internet.
The general issue with running as a standard out of the box account is that if you modify any of the default permissions you're expanding the set of things everything running as that account can do. So if you grant DBO to a database, not only can your service running as Local Service or Network Service access that database but everything else running as those accounts can too. If every developer does this the computer will have a service account that has permissions to do practically anything (more specifically the superset of all of the different additional privileges granted to that account).
It is always preferable from a security perspective to run as your own service account that has precisely the permissions you need to do what your service does and nothing else. However, the cost of this approach is setting up your service account, and managing the password. It's a balancing act that each application needs to manage.
In your specific case, the issue that you are probably seeing is that the the DCOM or COM+ activation is limited to a given set of accounts. In Windows XP SP2, Windows Server 2003, and above the Activation permission was restricted significantly. You should use the Component Services MMC snapin to examine your specific COM object and see the activation permissions. If you're not accessing anything on the network as the machine account you should seriously consider using Local Service (not Local System which is basically the operating system).
In Windows Server 2003 you cannot run a scheduled task as
NT_AUTHORITY\LocalService
(aka the Local Service account), or
NT AUTHORITY\NetworkService
(aka the Network Service account).
That capability only was added with Task Scheduler 2.0, which only exists in Windows Vista/Windows Server 2008 and newer.
A service running as NetworkService
presents the machine credentials on the network. This means that if your computer was called mango
, it would present as the machine account MANGO$
:
Best Answer
Symbolic links have more functionality, while junctions almost seem to be a legacy feature because of their limitations, but the security implications of these limitations are specifically why a junction might be preferred over a symbolic link. Remote targeting makes symbolic links more functional, but also raises their security profile, while junctions are safer because they are constrained to local paths. So, if you want a local link and can live with an absolute path, you're probably better off with a junction; otherwise, consider a symbolic link for its added abilities.
*The statement of difference in speed/complexity comes from an unverified statement in the Wikipedia entry on NTFS reparse points (a good read).
**Ever since the Windows 10 Creators Update, one can enable Developer Mode to remove the admin restriction for NTFS symbolic links.
Other NTFS Link Comparisons
Here are some other comparisons on the topic, but these can be misleading when considering junctions because they don't list the benefits I list above.
Taken from here (a good introductory read)
From SS64 page on MKLink
Comments about Terminology
Junctions are Reparse Points (may be described as symbolic links)
NTFS Junctions and NTFS Symbolic links are really doing the same thing in the same way (reparse points), aside from the aforementioned differences in how they're processed. In fact, technically, a Junction is a "symbolic link" in the more general sense of the word, and sometimes documentation might call a Junction a symbolic link, as is the case here. In such cases, "symbolic link" does not mean NTFS Symbolic Link which is different than a junction (see below).
NTFS
Even though the OP specifies this, it's worth pointing out that "symbolic link" is a very general term that is not specific to NTFS. So, to be specific, this comparison is about NTFS Junctions vs. NTFS Symbolic Links.