Working with links

[ccb]

TCC 15.01.51 x64 Windows 7 [Version 6.1.7601]

Hello,
I create a link like this:

MKLNK c:\skydrive\bin\msbld12.bat c:\bin\msbld12.bat

- In c:\bin, is there a way to list all the links? 'dir' doesn't seem to be able to do it.
- Once I know that c:\bin\msbld12.bat is a link, is there a way to determine what it is linked to?

Thanks for any insights...

(I found reference to INODE in another thread, but that seemed to be used to compare two objects to see if they are the same. @links[<file>] returns the number of links to the <file>, but nothing else.)

UPDATE:
'dir' identifies soft links ('<SYMLINK>') and their target, but not hard links.

 

[Joe Caverly]

Have a look at http://technet.microsoft.com/en-ca/sysinternals/bb896768

Use junction to list junctions:
 
Usage: [-s]
 
-s    Recurse subdirectories
 
Examples:
 
To determine if a file is a junction, specify the file name:
 
junction c:\test
 
To list junctions beneath a directory, include the –s switch:
 
junction -s c:\

Joe

 

[vefatica]

Hard links? I wrote a LISTLINKS.EXE a long time ago and recently have been working on a version of DU.EXE (which doesn't count bytes/allocation for more than one link to the same thing). It's pretty easy to determine if a file has more than one link but, as far as I know, the only way to determine what other files may be linked to a file with multiple links is to search for them starting with the name of one of them (which is slow).

I read the SysInternals blurb. I don't think that program deals with hard links (but rather with junctions, reparse points).

 

[vefatica]

P.S. There are thousands of hard links on the Win7 system drive. Just for example, here's a file with 7 links.

l:\projects\mydu\release> mydu.exe c:\ | grep 00065536:00011061
00065536:00011061 (7)    c:\Windows\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\prc.nlp::$DATA
00065536:00011061 (7)    c:\Windows\Microsoft.NET\Framework\v2.0.50727\prc.nlp::$DATA
00065536:00011061 (7)    c:\Windows\winsxs\x86_mscorlib_b77a5c561934e089_6.1.7601.17514_none_9c12e14f7dfecaf8\prc.nlp::$DATA
00065536:00011061 (7)    c:\Windows\winsxs\x86_mscorlib_b77a5c561934e089_6.1.7601.17587_none_9c199efd7df8c93c\prc.nlp::$DATA
00065536:00011061 (7)    c:\Windows\winsxs\x86_mscorlib_b77a5c561934e089_6.1.7601.17648_none_9c1586e97dfc7dd2\prc.nlp::$DATA
00065536:00011061 (7)    c:\Windows\winsxs\x86_mscorlib_b77a5c561934e089_6.1.7601.21693_none_854d53a7979edc15\prc.nlp::$DATA
00065536:00011061 (7)    c:\Windows\winsxs\x86_mscorlib_b77a5c561934e089_6.1.7601.21768_none_8549e0bd97a21086\prc.nlp::$DATA

It took about 25 seconds to do that (but it got **all** the multiple link info).

 

[vefatica]

MYDU.EXE is very much a work in progress, requires >= Vista, and so far only exists in a 32-bit version. But it might be fun to play with. I added an option to send inode/link info to a file. If a file has more than one hard link you'll only find all of them if you specify a high enough starting directory.
When I do "mydu.exe /l vlinks.txt v:\" and sort the resulting file, I see the one hard link I made as a test.

(snip)
00A30000:00006376 1 v:\4utilcopy\dynalink\oniguruma.obj
00A50000:00000FBF 2 v:\linkbg.cpp
00A50000:00000FBF 2 v:\4utilcopy\bg.cpp
00A50000:00002401 1 v:\tcsh\tcsh-6.18.01\config.rpath
(snip)

FWIW, I'm attaching a ZIP of it. It works like this.

l:\projects\mydu\release> mydu.exe /?
Show size/allocation; requires NTFS
 
MYDU [/S(treams)] [/D(ebug)] [/V(erbose)] [/E(xplorer)] [/L(inks) file] dirname
 
  /S  show non-default streams
  /D  show Failures (stderr)
  /V  show (recursive) byte/alloc for each directory
  /E  use Explorer style byte counts
  /L  send inode/link info to file
      *quote dirnames containing whitespace
      *hard-linked files counted only once
      *junctions/reparse points are not followed

 

[samintz]

P.S. There are thousands of hard links on the Win7 system drive. Just for example, here's a file with 7 links.

l:\projects\mydu\release> mydu.exe c:\ | grep 00065536:00011061
00065536:00011061 (7)    c:\Windows\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\prc.nlp::$DATA
00065536:00011061 (7)    c:\Windows\Microsoft.NET\Framework\v2.0.50727\prc.nlp::$DATA
00065536:00011061 (7)    c:\Windows\winsxs\x86_mscorlib_b77a5c561934e089_6.1.7601.17514_none_9c12e14f7dfecaf8\prc.nlp::$DATA
00065536:00011061 (7)    c:\Windows\winsxs\x86_mscorlib_b77a5c561934e089_6.1.7601.17587_none_9c199efd7df8c93c\prc.nlp::$DATA
00065536:00011061 (7)    c:\Windows\winsxs\x86_mscorlib_b77a5c561934e089_6.1.7601.17648_none_9c1586e97dfc7dd2\prc.nlp::$DATA
00065536:00011061 (7)    c:\Windows\winsxs\x86_mscorlib_b77a5c561934e089_6.1.7601.21693_none_854d53a7979edc15\prc.nlp::$DATA
00065536:00011061 (7)    c:\Windows\winsxs\x86_mscorlib_b77a5c561934e089_6.1.7601.21768_none_8549e0bd97a21086\prc.nlp::$DATA

It took about 25 seconds to do that (but it got **all** the multiple link info).

Does that mean all those files have their streams hard linked? Is a stream actually a separate file? Aside from the fact that streams are normally hidden is there any difference between a stream a regular file?

-Scott

 

[vefatica]

Does that mean all those files have their streams hard linked? Is a stream actually a separate file? Aside from the fact that streams are normally hidden is there any difference between a stream a regular file?

-Scott

You can't make a hard link to a stream per se. When you make a hard link to a file the hard link has the same streams. A stream is not "separate"; by that I mean all the streams of all links to the same thing have the same inode (file index). As for the actual storage of the data, I haven't figured it all out. For small streams (small files (default stream) and small alternate streams) on NTFS the APIs say that allocation is less than one cluster. I take that to mean the data is small enough to fit in the file's MFT entry. An MFT entry is typically 1024 bytes and must include the file's attributes, times, name, and info about where it can be found ("runs" of clusters). I have read that sufficiently fragmented files can require additional 1024-byte chunks in the MFT to accommodate all the necessary "run" info. I don't know how to tell when that happens.
I'm trying to figure out how to accurately compute "allocation". I have not found two tools that agree. The 8,192 below is almost certainly wrong on NTFS.

2009-06-10  17:42              24  autoexec.bat
2009-06-10  17:42              10  config.sys
                34 bytes in 2 files and 7 dirs    8,192 bytes allocated

For these files, GetFileInformationByHandleEx (requires Vista+) reports allocations of only a few bytes more than their sizes. I suspect that no 4096-byte clusters are used and that the data is contained in the MFT record. I'm not complaining. Utilities should work on various file systems and on various OSs.