Linux - GeneralThis Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
I'm writing a Perl script to serve as a Data Archiving and Storage Manager. It use three levels of classification, Categories, Subjects and Topics, that define three levels of subdirectories, with items (i.e. data files) entered appropriately. So one might have Mathematics > Calculus > Integration and Mathematics > Calculus > Differentiation. A file on Isaac Newton might go in Mathematics > Calculus > History, but also in Science > Physics > History and in Metaphysics > Alchemy > Alchemists. Two specifications enter here:
1. Multiple classifications are allowed - sc. each file can be entered under two or more headings if required.
2. No file may be duplicated.
The solution adopted, since I'm using an ext3 filesystem, is to use links. The question arises as to whether soft or hard links are most appropriate. Soft links are "pointers" to files and directories, whereas hard links are alternative names for the same file. I understand that directories should not be hard-linked, since this creates multiple parents, breaking the directory tree structure and rendering it unusable.
Are there any guidelines or usage recommendations that differentiate soft and hard links to allow an optimum selection, or is the choice simply a preference?
Symbolic links make the most sense when each file has one classification that you consider "primary" and that is where the actual file will always be stored. Otherwise you run the risk of, for example, deleting or renaming the "Metaphysics" hierarchy and thus breaking any symlinks to files that were actually stored there. With hard links, all the links are co-equal, and deleting or renaming one of the links would not affect the others. Hard links also have the minor advantage that a simple "ls -l" for any of the links tells you how many links that file has. (With either type of link you have to scan the filesystem to find out where those other links are.)
The down side of any type of link is that accidentally breaking a link and creating an unwanted second, and perhaps slightly different, copy of a file is pretty easy to do. (Just use an editor that isn't careful about how it handles symlinks or files with multiple hard links.) In my experience, that sort of problem seems to happen more often with hard links.
> The down side of any type of link ... multiple hard links.)
Have never used hard links, so this is an interesting caveat - thanks again.
The problem occurs because the safest way to update a file with the typical single link is to create a new file and then, once the new file has been written successfully, rename it over the old file. If this is done for a file with more than one link, the linking is broken and all of the other links are left pointing to the old content. Most editors will recognize that a file with multiple links should not be updated that way and revert to directly writing over the existing file. An example of an editor that does not avoid breaking the linking is sed with the "-i" (--in-place) option. (It is a stream editor that writes its output while reading its input. Those two cannot be the same file.)
The problem occurs because ... Those two cannot be the same file.)
Invaluable. I mostly use nedit for this sort of thing, so will check its operation. I'll leave this for a day and then mark it solved in case of further addenda, but I guess now that preference is the only real criterion. BTW, could you confirm that my understanding about hard-linking directories is correct?
BTW, could you confirm that my understanding about hard-linking directories is correct?
Confirmed. Even root cannot create hard links to a directory. Quite a few pieces of software make the tacit assumption that the directory structure is a tree, and making extra hard links to a directory would break that.
FWIW, a long time ago in a galaxy quite close to this one, actually, SunOS did allow root to make hard links to a directory. I tried doing it. Recovery from that was not easy (took some low-level fiddling with the fsdb file system debugger). No, I don't recall why I thought it might be a good idea.
Here's a lateral approach (given you specified Perl as the front-end) and is probably what I would do.
Have only the 'primary' path exist in reality and create a tied hash in Perl to store that path string and all the 'alternate path' strings and have them all resolve (eg HoHoH...) to the one true path
No links requited at all.
How you specify the Hash structure depends on how you intend to access the files and whether they will have guaranteed unique names.