1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Hardlinks, Softlinks

Discussion in 'Suggestions' started by Stephen Howe, May 6, 2009.

  1. Stephen Howe

    Joined:
    Jun 7, 2008
    Messages:
    121
    Likes Received:
    0
    Hi

    Could v11 support something in DIR, PDIR and/or ATTRIB so it is possible to see hardlink and softlink files (and possibly (P)DIR /A: so that they can be filtered in/out)?

    It is not easy to be sure of what files are

    normal files
    softlinked
    hardlinked

    If anyone wants to argue for sensible extension behaviour of DIR, PDIR and/or ATTRIB, please feel free (or alternatively what should not be done).

    Essentially I am arguing that invisible things (like hidden streams) are made visible in the interface.

    Cheers

    Stephen Howe
     
  2. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    Stephen Howe wrote:
    | Hi
    |
    | Could v11 support something in DIR, PDIR and/or ATTRIB so it is
    | possible to see hardlink and softlink files (and possibly (P)DIR /A:
    | so that they can be filtered in/out)?
    |
    | It is not easy to be sure of what files are
    |
    | normal files
    | softlinked
    | hardlinked

    Hard linked files were identifiable since V6 via @inode ( and @links to know
    how many directory entries for the same file). There is no possible way to
    "filter them out" if by this you mean to list them by only one of their
    directory entries (and this is also true for *nix file systems), because
    once two or more directory entries reference the same file body, those
    directory entries are totally equivalent, so the only way to distinguish
    "normal files" from "hard linked files" is via @links - and the same is true
    in *nix file systems.

    I would consider a file filtering option of @links=1 or @links>1 a nice
    feature, however, there may be a major performance penalty. The *nix FS
    stores only one piece of information about a file in the local directory,
    its "inode" identification; all other properties of the file are stored in
    the "inode" (timestamps, size, attributes, ownership, link count, etc.).
    AFAIK NTFS stores most of the above file properties in the (extended)
    directory entry, but the link count and the inode identifier may be
    somewhere else. This results in delayed updates of hard linked files'
    properties in all entries except the one explicitly handled. In particular,
    I wanted to avoid a backup procedure to copy a hard linked files' body more
    than once, using the automatic update of the A attribute, and filtering on
    the A attribute; did not prevent multiple copies being generated - the
    attribute update was delayed beyond accessing the file by alternate names.

    "Soft linked" files (cf. soft linked directories = symbolic links =
    junctions ) are a different story, and having an OS which does not support
    them (WinXP SP3), even though the file system (NTFS) itself does, I have no
    experience with them in the MS world. Did you try using the attribute L
    (link) or J (junction) in an attribute selection switch, e.g., /a:j-d ?

    | Essentially I am arguing that invisible things (like hidden streams)
    | are made visible in the interface.

    Do you want invisible things to become visible, or do you want to keep them
    hidden?
    --
    Steve
     
  3. Stephen Howe

    Joined:
    Jun 7, 2008
    Messages:
    121
    Likes Received:
    0
    Thanks for the explanation Steve.

    I did dimly know about Unix inodes and forgot.
    For Unix there is a difference between unlink and remove.
    Presumably, like Unix if the link count reaches 0, the file is removed.

    I see that what I am asking for is somewhat crazy.
    Mind you, knowing the link count > 1 means the file is referenced somewhere else.

    Cheers

    Stephen Howe
     
  4. Jim Cook

    Joined:
    May 20, 2008
    Messages:
    604
    Likes Received:
    0
    If the @links function shows differences where you want them, it may
    be that my timedir program will suffice. It has many of the features
    of TCC's DIR, but does behave differently in a few key areas.

    http://jcook.info/timedir

    To show only linked files: timedir /&@
    To hide all linked files: timedir /&-@

    Email me privately if you need help using the utility.

    On Wed, May 6, 2009 at 3:41 PM, Stephen Howe <> wrote:



    --
    Jim Cook
    2009 Saturdays: 4/4, 6/6, 8/8, 10/10, 12/12 and 5/9, 9/5, 7/11, 11/7.
    Next year they're Sunday.
     

Share This Page