Removing recursively hard linked directory - SUN

This is a discussion on Removing recursively hard linked directory - SUN ; I've got a Solaris 8 filesystem with a directory that's a hard link to its parent. Can I safely clean this up with unlink(1m)? Do I need to unmount the filesystem and run fsck afterwards? -- Jeff Wieland...

+ Reply to Thread
Results 1 to 5 of 5

Thread: Removing recursively hard linked directory

  1. Removing recursively hard linked directory

    I've got a Solaris 8 filesystem with a directory that's a hard link to
    its parent. Can I safely clean this up with unlink(1m)? Do I need to
    unmount the filesystem and run fsck afterwards?
    --
    Jeff Wieland

  2. Re: Removing recursively hard linked directory

    On 2005-12-07 16:11, Jeff Wieland wrote:
    > I've got a Solaris 8 filesystem with a directory that's a hard link to
    > its parent. Can I safely clean this up with unlink(1m)? Do I need to
    > unmount the filesystem and run fsck afterwards?
    > --
    > Jeff Wieland


    You can use unlink, but the link counter must be fixed with fsck.
    If this is not the / filesystem, you can maybe fix it online by doing error lock first.

    lockfs -e /mount
    fsck /mount

    Maybe dangerous, but can work.

    (is it still possible to hard link a directory in Solaris8 ? )

    /birre

  3. Re: Removing recursively hard linked directory

    In comp.unix.solaris Birre wrote:

    > You can use unlink, but the link counter must be fixed with fsck.
    > If this is not the / filesystem, you can maybe fix it online by doing error lock first.


    > lockfs -e /mount
    > fsck /mount


    Nooo....

    > Maybe dangerous, but can work.


    Too dangerous. Don't fsck filesystems that are mounted for writing.
    The cached data in the mount can go back and change the stuff "fixed" by
    fsck. Unmount, then fsck.

    > (is it still possible to hard link a directory in Solaris8 ? )


    It looks like 'ln' won't let you but link(2) will.

    Unlinking confused me for a minute.

    $ ls -lai parent
    total 6
    108859 drwxr-xr-x 3 root other 512 Dec 7 18:33 .
    2 drwxr-xr-x 43 root root 1024 Dec 7 18:33 ..
    108859 drwxr-xr-x 3 root other 512 Dec 7 18:33 child
    $ unlink parent/child
    unlink: Invalid argument

    Truss confirms that it's returning EINVAL, which is not mentioned in the
    man page as a possible error.

    $ unlink parent

    So you'd have to depopulate it and remove the parent. The fs was clean
    after this.

    $ ls -lai parent
    parent: No such file or directory
    $ cd ..
    $ umount /mnt
    $ fsck /dev/vx/rdsk/testvol
    ** /dev/vx/rdsk/testvol
    ** Last Mounted on /mnt
    ** Phase 1 - Check Blocks and Sizes
    ** Phase 2 - Check Pathnames
    ** Phase 3 - Check Connectivity
    ** Phase 4 - Check Reference Counts
    ** Phase 5 - Check Cyl groups
    2 files, 9 used, 385174 free (14 frags, 48145 blocks, 0.0% fragmentation)

    --
    Darren Dunham ddunham@taos.com
    Senior Technical Consultant TAOS http://www.taos.com/
    Got some Dr Pepper? San Francisco, CA bay area
    < This line left intentionally blank to confuse you. >

  4. Re: Removing recursively hard linked directory

    On 2005-12-08 03:48, Darren Dunham wrote:
    > In comp.unix.solaris Birre wrote:
    >
    >
    >>You can use unlink, but the link counter must be fixed with fsck.
    >>If this is not the / filesystem, you can maybe fix it online by doing error lock first.

    >
    >
    >>lockfs -e /mount
    >>fsck /mount

    >
    >
    > Nooo....
    >
    >
    >>Maybe dangerous, but can work.

    >
    >
    > Too dangerous. Don't fsck filesystems that are mounted for writing.
    > The cached data in the mount can go back and change the stuff "fixed" by
    > fsck. Unmount, then fsck.
    >
    >


    Well, when it's error locked , it's not mounted for writing any more,
    and the lock will be cleared after a successful fsck.
    (this is apparently the method to use if you have to fsck a mounted file system)

    man lockfs:
    -e Error-lock (elock) the specified file-system. elock
    blocks all local access to the locked file system and
    returns EWOULDBLOCK on all remote access. File systems
    are elocked by UFS on detection of internal incon-
    sistency. They may only be unlocked after successful
    repair by fsck, which is usually done automatically
    (see mount_ufs(1M)). elocked file systems can be
    unmounted.


    But if you can umount it, you are much safer.


    /birre

  5. Re: Removing recursively hard linked directory

    In article Birre writes:
    >On 2005-12-08 03:48, Darren Dunham wrote:
    >> In comp.unix.solaris Birre wrote:
    >>
    >>
    >>>You can use unlink, but the link counter must be fixed with fsck.
    >>>If this is not the / filesystem, you can maybe fix it online by doing error lock first.

    >>
    >>
    >>>lockfs -e /mount
    >>>fsck /mount

    >>
    >>
    >> Nooo....
    >>
    >>
    >>>Maybe dangerous, but can work.

    >>
    >>
    >> Too dangerous. Don't fsck filesystems that are mounted for writing.
    >> The cached data in the mount can go back and change the stuff "fixed" by
    >> fsck. Unmount, then fsck.
    >>
    >>

    >
    >Well, when it's error locked , it's not mounted for writing any more,
    >and the lock will be cleared after a successful fsck.
    >(this is apparently the method to use if you have to fsck a mounted file system)
    >
    >man lockfs:
    > -e Error-lock (elock) the specified file-system. elock
    > blocks all local access to the locked file system and
    > returns EWOULDBLOCK on all remote access. File systems
    > are elocked by UFS on detection of internal incon-
    > sistency. They may only be unlocked after successful
    > repair by fsck, which is usually done automatically
    > (see mount_ufs(1M)). elocked file systems can be
    > unmounted.
    >
    >
    >But if you can umount it, you are much safer.
    >
    >
    >/birre


    We were able to fix the file system with fsck in single user mode.
    It did take several passes, and it did remove the hard-linked directory.
    --
    Jeff Wieland

+ Reply to Thread