cancel
Showing results for 
Search instead for 
Did you mean: 
oldbenko
Moderator
Moderator
  • 3,549 Views

Ever wanted to get rid of hundreds of dead symlinks?

Jump to solution

It's easier than you thought and it relies on a simple trick with the find command - the -L option will dereference symbolic links, so the -type test will never match symlink... unless they are dead!

$ find -L /some/where -type l -delete

This will only delete symbolic links that are referencing a non-existent file, hence they can not be dereferenced to another type.

A black cat crossing the street signifies that the animal is going somewhere.
[don't forget to kudo a helpful post or mark it as a solution!]
Labels (3)
1 Solution

Accepted Solutions
mic_grivas
Mission Specialist
Mission Specialist
  • 3,509 Views

@oldbenko, the approach has a flaw, as Ravi correctly pointed.

In general, following symlinks in find commands is a bad approach due to loops in filesystems.

However, there is a better solution, which will not fall in the loop:

$ find /some/where -xtype l -delete

This will only delete symbolic links that are referencing a non-existent file, without running into any loop.

View solution in original post

4 Replies
Ravi_Shanker
Flight Engineer
Flight Engineer
  • 3,521 Views

This command without the delete option creates a loop on my debian system.. Redirecting output does give a short list of files as expected in above command.

find: File system loop detected; ‘/home/ravi/.googleearth/instance-running-lock/task/3967/cwd/sys/devices/pci0000:00/0000:00:1f.3/subsystem/devices/0000:00:1c.1/driver/0000:00:1c.2/pci_bus/0000:08/subsystem/0000:09/device/0000:09:00.0/net/wlan0/subsystem/eth0/device/firmware_node/subsystem/devices/PNP0103:00/physical_node/subsystem/devices/PNP0C0B:02/driver/PNP0C0B:03/thermal_cooling/subsystem/cooling_device3/device/physical_node/subsystem/devices/cpu1/driver/cpu2/node0/memory19/subsystem/devices/memory33/subsystem’ is part of the same file system loop as ‘/home/ravi/.googleearth/instance-running-lock/task/3967/cwd/sys/devices/pci0000:00/0000:00:1f.3/subsystem/devices/0000:00:1c.1/driver/0000:00:1c.2/pci_bus/0000:08/subsystem/0000:09/device/0000:09:00.0/net/wlan0/subsystem/eth0/device/firmware_node/subsystem/devices/PNP0103:00/physical_node/subsystem/devices/PNP0C0B:02/driver/PNP0C0B:03/thermal_cooling/subsystem/cooling_device3/device/physical_node/subsystem/devices/cpu1/driver/cpu2/node0/memory19/subsystem’.

Certification ID: 111-010-393
0 Kudos
mic_grivas
Mission Specialist
Mission Specialist
  • 3,510 Views

@Ravi_Shanker wrote:

This command without the delete option creates a loop on my debian system.. Redirecting output does give a short list of files as expected in above command.

find: File system loop detected; [...]


It is  not the find command that produces the loop. It is that it shows an existing loop !  Likely, the  instance-running-lock/task  points to some task under /proc . Therefore the loop exists and you will have issues with whichever run of find, if you dereference links (-L or -follow).

mic_grivas
Mission Specialist
Mission Specialist
  • 3,510 Views

@oldbenko, the approach has a flaw, as Ravi correctly pointed.

In general, following symlinks in find commands is a bad approach due to loops in filesystems.

However, there is a better solution, which will not fall in the loop:

$ find /some/where -xtype l -delete

This will only delete symbolic links that are referencing a non-existent file, without running into any loop.

oldbenko
Moderator
Moderator
  • 3,417 Views

I argue that it's the loop that is the problem, not the command.

But thanks for suggesting an alternative (although this is GNU find specific, it's not found in BSD fileutils).

A black cat crossing the street signifies that the animal is going somewhere.
[don't forget to kudo a helpful post or mark it as a solution!]
0 Kudos
Join the discussion
You must log in to join this conversation.