Links: Difference between revisions
Yuron [PHRhYmxlIGNsYXNzPSJ0d3BvcHVwIj48dHI+PHRkIGNsYXNzPSJ0d3BvcHVwLWVudHJ5dGl0bGUiPkdyb3Vwczo8L3RkPjx0ZD51c2VyPGJyIC8+YnVyZWF1Y3JhdDxiciAvPmludGVyZmFjZS1hZG1pbjxiciAvPnN5c29wPGJyIC8+PC90ZD48L3RyPjwvdGFibGU+] (talk | contribs) m (1 revision imported) |
W81054ch [PHRhYmxlIGNsYXNzPSJ0d3BvcHVwIj48dHI+PHRkIGNsYXNzPSJ0d3BvcHVwLWVudHJ5dGl0bGUiPkdyb3Vwczo8L3RkPjx0ZD51c2VyPGJyIC8+YnVyZWF1Y3JhdDxiciAvPmludGVyZmFjZS1hZG1pbjxiciAvPnN5c29wPGJyIC8+PC90ZD48L3RyPjwvdGFibGU+] (talk | contribs) m (1 revision imported) |
||
(One intermediate revision by one other user not shown) | |||
Line 2: | Line 2: | ||
-->{{Path|Filing|11}}<!-- | -->{{Path|Filing|11}}<!-- | ||
-->{{#invoke:Dependencies|add|Filing System Implementation,4}} | -->{{#invoke:Dependencies|add|Filing System Implementation,4}} | ||
The simplest [[Filing_System|filing system]] is ‘flat’, | The simplest [[Filing_System|filing system]] is ‘flat’, where all files are in the same place. This is not manageable for any | ||
where all files are in the same place. This is not manageable for any | |||
significant number of files. | significant number of files. | ||
A more familiar structure is probably the <strong>tree</strong> structure. This | A more familiar structure is probably the <strong>tree</strong> structure. This allows some categorisation of files and filenames can be duplicated in different directories. The actual filename really includes the <strong>path</strong> to that file from the root of the filestore, or <em>relative</em> to a known position. | ||
allows some categorisation of files and filenames can be duplicated in | |||
different directories. The actual filename really includes the | |||
<strong>path</strong> to that file from the root of the filestore, or <em>relative</em> to | |||
a known position. | |||
Sometimes it is convenient to have a file in more than one place. | Sometimes it is convenient to have a file in more than one place. Rather than copying the file, this may be done by adding a <strong>link</strong>, which is an alias for a file. | ||
Rather than copying the file, this may be done by adding a <strong>link</strong>, | |||
which is an alias for a file. | |||
[[Image:link_tree.png|link=|alt=Link in tree]] | [[Image:link_tree.png|link=|alt=Link in tree]] | ||
Adding links can cause complications. The structure ceases to be a | Adding links can cause complications. The structure ceases to be a simple tree and becomes a directed graph. In particular, it is undesirable to form <em>cycles</em> in this graph: recursive searches would never reach the ‘bottom’ of the structure. A particular system way therefore not allow such links to be created. | ||
simple tree and becomes a directed graph. In particular, it is | |||
undesirable to form <em>cycles</em> in this graph: recursive searches would | |||
never reach the ‘bottom’ of the structure. A particular | |||
system way therefore not allow such links to be created. | |||
In Unix, at least, there is more than one way of building a link. | In Unix, at least, there is more than one way of building a link. These will <em>largely</em> appear to be the same, but there are important differences. | ||
These will <em>largely</em> appear to be the same, but there are important | |||
differences. | |||
=== Symbolic links === | === Symbolic links === | ||
A symbolic (or ‘soft’) link is a special form of file which | A symbolic (or ‘soft’) link is a special form of file which is simply a form of pointer to another file. The other file could be a directory; making it point at a directory higher up the hierarchy (i.e. creating a cycle) is probably a bad idea, but shouldn’t be catastrophic. | ||
is simply a form of pointer to another file. The other file could be | |||
a directory; making it point at a directory higher up the hierarchy | |||
(i.e. creating a cycle) is probably a bad idea, but shouldn’t be | |||
catastrophic. | |||
<blockquote> | <blockquote> | ||
<strong>Exercise:</strong> Try this in a Unix terminal <code>ln -s `which ls` dir</code>. | <strong>Exercise:</strong> Try this in a Unix terminal <code>ln -s `which ls` dir</code>. | ||
(The <code>which ls</code> command finds and returns the path | (The <code>which ls</code> command finds and returns the path to your usual <code>ls</code> command.) | ||
to your usual <code>ls</code> command.) | You now have your ‘very own’, Windows-like <code>dir</code> command … which simply points at the operating system utility. | ||
You now have your ‘very own’, Windows-like <code>dir</code> command … which simply points at | |||
the operating system utility. | |||
(You can delete the link again, harmlessly, with <code>rm dir</code>.) | (You can delete the link again, harmlessly, with <code>rm dir</code>.) | ||
</blockquote> | </blockquote> | ||
A symbolic link, being an <em>alias</em> for an object, does not have to link | A symbolic link, being an <em>alias</em> for an object, does not have to link to anything real. | ||
to anything real. | |||
<blockquote> | <blockquote> | ||
<strong>Exercise:</strong> Try this in a Unix terminal <code>ln -s this_is_not_a_filename_which_exists qwerty</code> (you can shorten the | <strong>Exercise:</strong> Try this in a Unix terminal <code>ln -s this_is_not_a_filename_which_exists qwerty</code> (you can shorten the filenames). | ||
filenames). | <code>qwerty</code> will now appear in your directory but <code>cat qwerty</code> will fail (because there is no real file there). | ||
<code>qwerty</code> will now appear in your directory but <code>cat qwerty</code> will | |||
fail (because there is no real file there). | |||
</blockquote> | </blockquote> | ||
=== Hard links === | === Hard links === | ||
To understand hard links it is probably sensible to check up on (e.g.) | To understand hard links it is probably sensible to check up on (e.g.) [[Inodes|i-nodes]] first. Note that an i-node <em>defines</em> a file and the filename is simply <em>associated</em> with that (unique) node number. | ||
[[Inodes|i-nodes]] first. Note that an i-node <em>defines</em> a file and the | |||
filename is simply <em>associated</em> with that (unique) node number. | |||
<blockquote> | <blockquote> | ||
When a file is created, an i-node is allocated <em>and</em> a directory | When a file is created, an i-node is allocated <em>and</em> a directory entry is made which includes the i-node number. Another way of stating this is: the file is created and a name is <em>linked</em> to it. | ||
entry is made which includes the i-node number. Another way of | |||
stating this is: the file is created and a name is <em>linked</em> to it. | |||
</blockquote> | </blockquote> | ||
When a hard link is created it is a directory entry which links to the | When a hard link is created it is a directory entry which links to the i-node – to the file itself, not another <em>name</em>. The link <em>is</em> the file. | ||
i-node – to the file itself, not another <em>name</em>. The link <em>is</em> the file. | |||
[[Image:links.png|link=|alt=Links]] | [[Image:links.png|link=|alt=Links]] | ||
Line 67: | Line 40: | ||
<strong>Exercise:</strong> Try this in a Unix terminal: | <strong>Exercise:</strong> Try this in a Unix terminal: | ||
Choose or create a file (e.g. xxx). | Choose or create a file (e.g. xxx). | ||
<code>stat xxx</code> – you will probably see “Links: 1”, as in | <code>stat xxx</code> – you will probably see “Links: 1”, as in there is one directory entry, somewhere, pointing to this file. | ||
there is one directory entry, somewhere, pointing to this file. | |||
Create a hard link to that file: (e.g.) <code>ln xxx yyy</code>. | Create a hard link to that file: (e.g.) <code>ln xxx yyy</code>. | ||
<code>stat xxx</code> – you will probably see “Links: 2” now. | <code>stat xxx</code> – you will probably see “Links: 2” now. | ||
<code>stat yyy</code> – the <strong>same file</strong> so the data is the same! | <code>stat yyy</code> – the <strong>same file</strong> so the data is the same! | ||
You can remove either <code>xxx</code> or <code>yyy</code> – removing <em>both</em> will remove | You can remove either <code>xxx</code> or <code>yyy</code> – removing <em>both</em> will remove the file though. | ||
the file though. | |||
</blockquote> | </blockquote> | ||
Note that the filing system is keeping track of the number of links to | Note that the filing system is keeping track of the number of links to an i-node. | ||
an i-node. | |||
*“Deleting a file” which has multiple links will not actually delete the data. | *“Deleting a file” which has multiple links will not actually delete the data. | ||
Line 82: | Line 52: | ||
===== Experiment ===== | ===== Experiment ===== | ||
Have a look at the output from <code>ls -la</code>. The first <em>number</em> is the | Have a look at the output from <code>ls -la</code>. The first <em>number</em> is the hard link count. This will be <code>1</code> for most data files but more for a directory. Create a new, empty directory and the count for <code>.</code> will be <code>2</code>: one from the parent and one from itself: the count for <code>..</code> is likely to be more because <em>every</em> subdirectory also points at its parent with a hard link. Example: | ||
hard link count. This will be <code>1</code> for most data files but more for a | |||
directory. Create a new, empty directory and the count for <code>.</code> will | |||
be <code>2</code>: one from the parent and one from itself: the count for <code>..</code> is | |||
likely to be more because <em>every</em> subdirectory also points at its | |||
parent with a hard link. Example: | |||
[[Image:hard_links.png|link=|alt=Link diagram]] | [[Image:hard_links.png|link=|alt=Link diagram]] | ||
Line 103: | Line 68: | ||
=== Links and i-nodes === | === Links and i-nodes === | ||
Another thing you might check (try <code>ls -i</code> for example) is looking at | Another thing you might check (try <code>ls -i</code> for example) is looking at the i-node numbers for soft- and hard-links. Creating a new hard link does not allocate a new i-node; however a soft (symbolic) link is really just a file in its own right and each one has its own i-node. | ||
the i-node numbers for soft- and hard-links. Creating a new hard link | |||
does not allocate a new i-node; however a soft (symbolic) link is | |||
really just a file in its own right and each one has its own i-node. | |||
---- | ---- | ||
Line 149: | Line 111: | ||
</div></div> | </div></div> | ||
---- | ---- | ||
{{BookChapter|13.3.4|547-549}} | |||
{{PageGraph}} | {{PageGraph}} | ||
{{Category|Filing System}} | {{Category|Filing System}} | ||
{{Category|User}} | {{Category|User}} |
Latest revision as of 10:03, 5 August 2019
On path: Filing | 1: Filing System • 2: File Systems • 3: Files • 4: File Attributes • 5: File Types • 6: File Permissions • 7: File Access • 9: Filing System Implementation • 10: I-nodes • 11: Links • 12: File Descriptor |
---|
Depends on | Filing System Implementation |
---|
The simplest filing system is ‘flat’, where all files are in the same place. This is not manageable for any significant number of files.
A more familiar structure is probably the tree structure. This allows some categorisation of files and filenames can be duplicated in different directories. The actual filename really includes the path to that file from the root of the filestore, or relative to a known position.
Sometimes it is convenient to have a file in more than one place. Rather than copying the file, this may be done by adding a link, which is an alias for a file.
Adding links can cause complications. The structure ceases to be a simple tree and becomes a directed graph. In particular, it is undesirable to form cycles in this graph: recursive searches would never reach the ‘bottom’ of the structure. A particular system way therefore not allow such links to be created.
In Unix, at least, there is more than one way of building a link. These will largely appear to be the same, but there are important differences.
Symbolic links
A symbolic (or ‘soft’) link is a special form of file which is simply a form of pointer to another file. The other file could be a directory; making it point at a directory higher up the hierarchy (i.e. creating a cycle) is probably a bad idea, but shouldn’t be catastrophic.
Exercise: Try this in a Unix terminal
ln -s `which ls` dir
. (Thewhich ls
command finds and returns the path to your usualls
command.) You now have your ‘very own’, Windows-likedir
command … which simply points at the operating system utility. (You can delete the link again, harmlessly, withrm dir
.)
A symbolic link, being an alias for an object, does not have to link to anything real.
Exercise: Try this in a Unix terminal
ln -s this_is_not_a_filename_which_exists qwerty
(you can shorten the filenames).qwerty
will now appear in your directory butcat qwerty
will fail (because there is no real file there).
Hard links
To understand hard links it is probably sensible to check up on (e.g.) i-nodes first. Note that an i-node defines a file and the filename is simply associated with that (unique) node number.
When a file is created, an i-node is allocated and a directory entry is made which includes the i-node number. Another way of stating this is: the file is created and a name is linked to it.
When a hard link is created it is a directory entry which links to the i-node – to the file itself, not another name. The link is the file.
Exercise: Try this in a Unix terminal: Choose or create a file (e.g. xxx).
stat xxx
– you will probably see “Links: 1”, as in there is one directory entry, somewhere, pointing to this file. Create a hard link to that file: (e.g.)ln xxx yyy
.stat xxx
– you will probably see “Links: 2” now.stat yyy
– the same file so the data is the same! You can remove eitherxxx
oryyy
– removing both will remove the file though.
Note that the filing system is keeping track of the number of links to an i-node.
- “Deleting a file” which has multiple links will not actually delete the data.
- Deleting a file when that is the only link would leave the i-node isolated; at this point it becomes is available for reuse.
Experiment
Have a look at the output from ls -la
. The first number is the hard link count. This will be 1
for most data files but more for a directory. Create a new, empty directory and the count for .
will be 2
: one from the parent and one from itself: the count for ..
is likely to be more because every subdirectory also points at its parent with a hard link. Example:
From the red directory:
drwxr-xr-x 2 jdg apt 4096 Sep 21 16:12 .
drwxr-xr-x 4 jdg apt 4096 Sep 21 16:12 ..
-rw-r--r-- 1 jdg apt 16 Sep 21 16:12 thing
- The parent directory and self have hard links to
.
- The parent directory has links from its own parent, itself and two subdirectories (we are in one of these)
thing
is just a file and has one link – from this directory.
It could have more, but hasn’t here.
Links and i-nodes
Another thing you might check (try ls -i
for example) is looking at the i-node numbers for soft- and hard-links. Creating a new hard link does not allocate a new i-node; however a soft (symbolic) link is really just a file in its own right and each one has its own i-node.
Thought exercise
Test your understanding with what happens in each of these sequences.
- Create a file
aa
- Create a symbolic link to
aa
calledbb
- Delete
aa
- Read
bb
Create a file aa
Straightforward so far!
Create a symbolic link to aa
called bb
aa
is a real file;bb
is a link to that filename.
Delete aa
The file is gone.
Read bb
No chance. The link is there, but it links to nothing.
… and is this any different?
- Create a file
aa
- Create a hard link to
aa
calledbb
- Delete
aa
- Read
bb
Create a file aa
Straightforward so far!
Create a hard link to aa
called bb
aa
is still there;bb
is another name for the file.
Delete aa
The link is removed and the filename
aa
has gone. However as there is still a link to the file the data is retained.
Read bb
… and there it is.
The middle two steps are effectively renaming the file.
Also refer to: | Operating System Concepts, 10th Edition: Chapter 13.3.4, pages 547-549 |
---|