On Tuesday 13 December 2011 06:56:34 am Patrick Schmalstig / WRRJ Radio wrote: > Thank you for clarifying that... even though I've had lots of computer > experience I've never had to create a symlink before so I didn't know > exactly what to do.
You've mentioned "lots of computer experience" twice now. That may be relevant, or not, depending on what that means. For reference as to why it *might* work........ Symbolic ( or soft ) links have existed in Unix almost since the beginning circa 1972. Microsoft then "invented" their version circa 1995, called them "short cuts" and did what they could within the limitations of MS FAT file systems. In some ways they are similar, but quite different in others. On MS file systems, files are referenced ( by the machine ) by human readable name. On many *nix file systems, nearly all that you are likely to run into, files are referenced ( by the machine ) by physical track/sector location on the platters. By block number, as created when the file system is made. ( called a "format" in MS parlance, but isn't really a true format at all ) The file name is stored in an inode with appropriate metadata which tells the machine where the file is, among other things, like permission bits, name, and type. This is a hard link. Unlike MS systems, there can be any number of hard links all pointing to the same file PROVIDED they exist within the same file system on the same disk. A symbolic link is an inode containing a pointer to an inode that is a hard link. It can traverse file systems, and discs because it does not contain an absolute reference to the actual file. It's a pointer to a pointer, if you will. A symbolic inode, like a hard link, can have a different human readable name for the same inode number that represents the actual file, but does NOT contain metadata about the file itself, such as type and permissioning. This is because the file "name" is a meaningless construct to the machine in *nix systems, but is an absolute reference on MS systems. Some code takes what the file type is from the metadata contained within the hard link. The file command does this directly from the referenced inode, so it will return the file type on hard links, and identify a symbolic link as a symbloic link, not what the linked file is. This is why file name "extensions" are an artificial construct on *nix, but absolute on MS. More recent code, influenced by MS, takes the file type from the name "extension" which was previously meaningless on *nix systems. The distinctions blur. Therefore, some installation routines create multiple symbolic links to a file, with different names, similar to what you did manually. Typically, you can find many of these in the library directories. SO, although creating a symbolic worked for you this time, does not mean it will work in the future ! Be aware, else it can get quite frustrating. Additional A file on *nix is not deleted until the last handle is released. That handle always references a hard link. Once the last hard link is deleted, the file itself is marked as available disc space. Symbolic links are left orphaned, pointing to nowhere. Sometimes, during a crash, it's possible to delete the hard link, but not mark the file space as available. If this happens, fsck will create a link in the lost+found directory, and name the file with its block number, so as to maintain the integrity of the file system. Hope this helps.... -- Cowboy http://cowboy.cwf1.com If there are epigrams, there must be meta-epigrams. _______________________________________________ Rivendell-dev mailing list [email protected] http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev
