Another dumb Linux question -- telling if a file is linked to

The inode contains a reference count indicating the number of /hard/ links to the inode. I suspect soft links pose considerably more problems, especially in a distributed file system :)

And I know nothing about LVM.

It is. Nor would it help you in any meaningful way if the answer were "yes", since nothing could stop root from making any amount of symlinks to /dev entries, for multiple different reasons only root ever heard of. I.e. a "has a link" check is both effectively impossible, and totally useless.

That would be putting the cart before the horse.

The only way symlinks inside the /dev tree would help would be if you _required_ one to the right device, under a unique name you specified in advance. That was the whole idea behind truly ancient "standard" symlinks like /dev/mouse or /dev/modem, and could work the same to justify a new entry /dev/TimsProgramsSerialPort (or rather ~/.TimsProgram/serialPort)

Not to mention that these days, any such install-time static set-up would make even less sense than it did back then, as serial ports on desktop machines have long since been predominantly of the hot-plugged USB persuasion, which only exist as /dev entries for the time the USB-to-serial thingy is actually plugged in. You'ld be better off querying the /proc pseudo files about what types of devices there are (if that still exists these days; haven't done much Linux for most of the past decade).

What I'm doing with the symbolic links is to give USB serial ports meaningful names. The USB to serial cable with the '1' on it is always '/ dev/ttyCable1', regardless of whether it's /dev/ttyUSB0 or /dev/ttyUSB42. All of the USB serial devices I commonly use get names and udev rules, which goes a long way to helping me actually be useful with them.

That exactly what I do too, using a udev rule. That way it works even if the port was still open when unplugged and re-plugged. I also do not know a simple solution to your question. But from the command line something like

rb-thinkpad:/dev # ls -l | grep ttyS0 lrwxrwxrwx 1 root root 5 Aug 8 09:07 serial-link -> ttyS0 crw-rw---- 1 root dialout 4, 64 Aug 8 2014 ttyS0

would do it. I had just created a symlink "serial-link".

You can look at st_nlink in the stat struct to see if multiple directory entries point to the same inode. This wont tell you anything about symlinks though. There is no easy way, that I know of, to go from the referenced file back to the symlink entry (or hard link).

But even the hard link count does not help you much. I can use mknod(1) or mknod(2) to create any number of /dev entries with the same major/minor numbers.

I do something similar, with a set of rules like this:

KERNEL=="ttyUSB*", DEVPATH=="*/usb2/2-1/2-1.1/2-1.1:1.0/*", SYMLINK += "ttySerial_hub1" KERNEL=="ttyUSB*", DEVPATH=="*/usb2/2-1/2-1.2/2-1.2:1.0/*", SYMLINK += "ttySerial_hub2" KERNEL=="ttyUSB*", DEVPATH=="*/usb2/2-1/2-1.3/2-1.3:1.0/*", SYMLINK += "ttySerial_hub3" KERNEL=="ttyUSB*", DEVPATH=="*/usb2/2-1/2-1.4/2-1.4:1.0/*", SYMLINK += "ttySerial_hub4"

KERNEL=="ttyUSB*", DEVPATH=="*/usb2/2-1/2-1.1/2-1.1:1.1/*", SYMLINK += "ttySerial_hub1b" KERNEL=="ttyUSB*", DEVPATH=="*/usb2/2-1/2-1.2/2-1.2:1.1/*", SYMLINK += "ttySerial_hub2b" KERNEL=="ttyUSB*", DEVPATH=="*/usb2/2-1/2-1.3/2-1.3:1.1/*", SYMLINK += "ttySerial_hub3b" KERNEL=="ttyUSB*", DEVPATH=="*/usb2/2-1/2-1.4/2-1.4:1.1/*", SYMLINK += "ttySerial_hub4b"

KERNEL == "ttyUSB*", ATTRS{idVendor} == "0403", ATTRS{idProduct} == "6001", \ ATTRS{serial} == "FTFLYG0L", SYMLINK += "ttySerial_ttl1"

ATTR{idVendor}=="0403", ATTR{idProduct}=="6001", \ ATTR{serial}=="FTUSV1RA", SYMLINK += "ttySerial_232"

I have a hub taped to my desk, and when I plug a FTDI cable into port 2 I get a /dev/ttySerial_hub2 serial port (and a "hub2b" port, if it is a dual-port FTDI device). Rules like that make life much easier on Linux, and are a world apart from Windows giving new comms port numbers for every device/port combination you use. But it depends on how much control you have of the machine in use.

USB serial ports are normally called ttyUSBx, but can sometimes have different names (I have seen ttyACMx). You could probably search for all /dev/ttyXXX devices where XXX is not just a number - I don't know of any tty names other than serial ports.

You don't say whether you mean hard links or soft links - but the answer is "no" anyway. With hard links, you can count the number of links to a file - with soft links you don't even know that.

Hard links cannot be differentiated from the original filename link to the inode: they are all borne equal. You can create a file under one name, hard link a second name to it and delete the original name. The resulting file continues to exist under the new name just as it were created under it originally.

Symbolic links can be identified with lstat() and the target can be resolved with readlink(). For an example, man 2 readlink.

AFAIK, there is no means for a file to know if a path to it is buried as a symbolic link somewhere in the filesystem, pointing to the file, but for your purposes it does not matter, as you're going to scan the device directory anyway. You should be prepared to scan sub-directories as well, as many distributions create sub-directorien in /dev.

The /sys pseudo-filesystem is a peephole into the device driver data structures in the kernel. You can find everything about USB devices by scanning the /sys/bus/usb/ directory and the 'files' under it.

In article , Joe Chisolm wrote: }On Thu, 07 Aug 2014 17:13:44 -0500, Tim Wescott wrote: } }> Subject line says it -- is there a handy way under Linux to tell if a }> file is linked _to_? .. } There is no easy way, that I know of, to go from }the referenced file back to the symlink entry

To find links to file with a unique name foo you can try:

find / -lname foo

but it's actually a lot more complicated than that, as the target of a symlink can be either an absolute path or a relative path, so a symlink to "../a" might refer to the same file as "/x/y/z/a" or a different one depending on its location, so merely matching the name is not enough. And, in fact, -lname matches a pattern, so my example matches "xfoo".

In general, you need to examine the whole filesystem hierarchy and even that may not be enough, depending on your definition of reference as there could be a symlink on a filesystem which is not currently mounted.