/Nordlöw
> What are hard links used for?
They're what puts the whole directory structure of the filesystem
together.
--
As we enjoy great advantages from the inventions of others, we should
be glad of an opportunity to serve others by any invention of ours;
and this we should do freely and generously. (Benjamin Franklin)
> What are hard links used for?
They are used to connect multiple directory entries to a single inode.
You probably should read through a good Unix fundamentals book,
like "Operating Systems Design and Implementation".
FWIW, you might find http://linuxgazette.net/105/pitcher.html helpfull.
--
Lew Pitcher
Master Codewright & JOAT-in-training | Registered Linux User #112576
http://pitcher.digitalfreehold.ca/ | GPG public key available by request
---------- Slackware - Because I know what I'm doing. ------
> What are hard links used for?
Hard links are used to put a file or a directory into one or more
other directories. Any link that's not a soft link (in a typical
filesystem ) is a hard link.
DS
Do you mean for example the link between a directory and its
containing files?
Could you give me an example of an application scenario where need to
call link() from C.
/Nordlöw
> Could you give me an example of an application scenario where need to
> call link() from C.
A backup application using the file system as its database.
Greetings,
Jacob
--
"constructive ambiguity"
> Do you mean for example the link between a directory and its
> containing files?
No, that's something completely different. A hard link is about
having two (or more) different names for exactly the same file.
If you do
touch test1
ln test1 test2
then you have two file names in that directory that refer to
exactly the same file. If you now change one of them, using
e.g.
echo "ABC" test1
then you will find that the content of 'test2' has also
changed and is identical to that of 'test1' (Beware: some
editors like emacs per default don' work on the original
file but on a copy, renaming the original file as a backup,
so if you change 'test1' with emacs with the default set-
tings then you might get the wrong impression of how hard
links work.)
It's important to keep in mind that the name of a file name
and the file itself are two different things. For example,
if you "delete a file" with rm you actually don't delete the
file but just the (or one) name of the file. The file itself
only gets deleted when there are no more file names for it
(and no processes have the file open anymore). So if you
create a hard link you create just another name and if you
delete a hard link you just delete the name but the file
continues to exist (and is still reachable by its other
name).
> Could you give me an example of an application scenario where need to
> call link() from C.
You would use it whenever you want a second name for a file.
Regards, Jens
--
\ Jens Thoms Toerring ___ j...@toerring.de
\__________________________ http://toerring.de
>> Do you mean for example the link between a directory and its
>> containing files?
>
> No, that's something completely different.
Actually not.
Greetings,
Jacob
--
"Any, sufficiently advanced, technology is indistinguishable from magic."
Beg to differ: It's *exactly* the same thing.
The link between a directory entry and the containing file *is* a hard
link. To quote Dennis Ritchie and Ken Thompson: "The UNIX system differs
from other systems in which linking is permitted in that all links to a
file have equal status" ("The UNIX Time-Sharing System" in BSTJ Vol 57,
no soft links were used at that time).
You can have *additional* hard links:
> If you do
>
> touch test1
> ln test1 test2
>
> then you have two file names in that directory that refer to
> exactly the same file. If you now change one of them, using
You now have *two* hard links to the same file. There is absolutely no
conceptual difference between the two hard links and the two links
cannot be distinguished. If your delete any one of the hard links, you
still have *one* hard link.
E.g.
touch abc
ln abc def
rm abc
is absolutely identical to
touch def
The usage of hard links as providing additional access paths to files is
more or less just a very useful side-effect of the concept of how
directory entries are linked to the files.
Josef
--
These are my personal views and not those of Fujitsu Technology Solutions!
Josef Möllers (Pinguinpfleger bei FTS)
If failure had no penalty success would not be a prize (T. Pratchett)
Company Details: http://de.ts.fujitsu.com/imprint.html
> Nordlöw <per.n...@gmail.com> wrote:
>> On 11 Nov, 01:27, David Schwartz <dav...@webmaster.com> wrote:
>> > On Nov 10, 1:51 pm, Nordlöw <per.nord...@gmail.com> wrote:
>> >
>> > > What are hard links used for?
>> >
>> > Hard links are used to put a file or a directory into one or more
>> > other directories. Any link that's not a soft link (in a typical
>> > filesystem ) is a hard link.
>
>> Do you mean for example the link between a directory and its
>> containing files?
>
> No, that's something completely different. A hard link is about
> having two (or more) different names for exactly the same file.
> If you do
No, it's exactly the same thing. Hard links are about having *one* or
more names for exactly the same file.
> touch test1
This creates a hard link putting the file in the directory.
> ln test1 test2
This creates a second hard link for the file.
--
> > Hard links are used to put a file or a directory into one or more
> > other directories. Any link that's not a soft link (in a typical
> > filesystem ) is a hard link.
> Do you mean for example the link between a directory and its
> containing files?
Yes, those are hard links.
> Could you give me an example of an application scenario where need to
> call link() from C.
If you wanted to move a file from one directory to another (in the
same filesystem), for example, you could hard link it into the new
directory (with any file name you want) and then unlink it from the
old directory. The final result would be the file in the new directory
in the normal way with either the same or a different filename.
A hard link places a file or directory into a directory with a
particular name in the normal way. Note that the same file or
directory can be hard linked into any number of containing directories
with different names in each one. Of course, the normal number of such
links is just one.
DS
> On Nov 11, 1:30�am, Nordl�w <per.nord...@gmail.com> wrote:
>
>> > Hard links are used to put a file or a directory into one or more
>> > other directories. Any link that's not a soft link (in a typical
>> > filesystem ) is a hard link.
>
>> Do you mean for example the link between a directory and its
>> containing files?
>
> Yes, those are hard links.
>
>> Could you give me an example of an application scenario where need to
>> call link() from C.
>
> If you wanted to move a file from one directory to another (in the
> same filesystem), for example, you could hard link it into the new
> directory (with any file name you want) and then unlink it from the
> old directory. The final result would be the file in the new directory
> in the normal way with either the same or a different filename.
The rename system call would be a better way to do that, but the
example is of course valid.
> A hard link places a file or directory into a directory with a
> particular name in the normal way. Note that the same file or
> directory can be hard linked into any number of containing directories
> with different names in each one. Of course, the normal number of such
> links is just one.
Note that most modern systems don't allow arbitrarily linked
directories, only one normal name and the automatic . and .. links.
--
M�ns Rullg�rd
ma...@mansr.com
>> A hard link places a file or directory into a directory with a
>> particular name in the normal way. Note that the same file or
>> directory can be hard linked into any number of containing
>> directories with different names in each one. Of course, the
>> normal number of such links is just one.
>
> Note that most modern systems don't allow arbitrarily linked
> directories, only one normal name and the automatic . and ..
> links.
Back in the day, early versions of SunOS would allow root to
hard-link to directories. I did it once (I don't remember
exactly what I was trying to accomplish). Anyway, it created a
filesystem that was no longer a tree but a more general
directed graph.
That broke things rather badly. Tools like fsck and find and
whatnot all assume filesystems are strictly trees. It took
days of work to recover from that simple "ln" command. IIRC, I
finally had to manually wipe some i-nodes. That orphaned some
files, but it eliminated the "loops" in the filesystem and
allowed fsck to complete without panicking.
I think later versions of Solaris forbade even root from
hard-linking to directories.
--
Grant Edwards grante Yow! Did YOU find a
at DIGITAL WATCH in YOUR box
visi.com of VELVEETA?
Before the days of that fancy "rename" call mv was implemented using
the link method above.
I once hard linked a directory on solaris. It didn't cause any
problems until I tried to get rid of it. Every fsck would bring
it back. lol
I'm trying to figure out what it would even mean -- did the directory
end up with multiple links to it, . going back to itself, and .. going
to its original parent, or the most directory to be linked from, or ...?
It almost sounds like allowing it was a bug in Solaris.
>>> Back in the day, early versions of SunOS would allow root to
>>> hard-link to directories. I did it once (I don't remember
>>> exactly what I was trying to accomplish). Anyway, it created a
>>> filesystem that was no longer a tree but a more general
>>> directed graph.
>>>
>>> That broke things rather badly. Tools like fsck and find and
>>> whatnot all assume filesystems are strictly trees. It took
>>> days of work to recover from that simple "ln" command. IIRC, I
>>> finally had to manually wipe some i-nodes. That orphaned some
>>> files, but it eliminated the "loops" in the filesystem and
>>> allowed fsck to complete without panicking.
>>>
>>> I think later versions of Solaris forbade even root from
>>> hard-linking to directories.
>>
>> I once hard linked a directory on solaris. It didn't cause any
>> problems until I tried to get rid of it. Every fsck would bring
>> it back. lol
>
> I'm trying to figure out what it would even mean -- did the
> directory end up with multiple links to it, . going back to
> itself, and .. going to its original parent,
Yes, that's the way I remember it. But, it was almost 20 years
ago so I might be wrong.
> or the most directory to be linked from,
>
> or ...?
>
> It almost sounds like allowing it was a bug in Solaris.
I assume they eventually decided it was, because that "feature"
was removed later.
--
Grant Edwards grante Yow! I am a traffic light,
at and Alan Ginzberg kidnapped
visi.com my laundry in 1927!
[...]
> Yes, that's the way I remember it. But, it was almost 20 years
> ago so I might be wrong.
>
>> or the most directory to be linked from,
>>
>> or ...?
>>
>> It almost sounds like allowing it was a bug in Solaris.
>
> I assume they eventually decided it was, because that "feature"
> was removed later.
There was once a technical reason for this, eg, the UNIX 1st ed mkdir
system call is documented as
mkdir creates an empty directory whose name is the null--
terminated string pointed to by name. The mode of the di
rectory is mode. The special entries "." and ".." are not
present.
which implies that these special entries had to be created after the
directory itself by using the link system call.
While it makes sense in that scenario that the link() system
call needs the ability, it doesn't seem to justify being
allowed to do it using the command-line utility "ln" (which is
how I managed to shoot myself in the foot).
--
Grant Edwards grante Yow! And then we could sit
at on the hoods of cars at
visi.com stop lights!
% echo hello > contents
% ln -s contents softlink
% ln contents hardlink
% rm contents
% cat softlink
cat: softlink: No such file or directory
% cat hardlink
hello
You can for example have a directory that only members of group a can access
and another that only group b can access.
with a hard link it's possible to have the same file in both of them.
A hard link is also useful when a process is chrooted but need to share a file
with a not chrooted program using the same path, and so on.
The limit is that it must be the same file system while a soft link can cross
over file systems.
/bb
It's not allowed to hard link directories, and it was a bug in SunOS 4
so it was possible, and the admin cure was to unlink it at then unmount
and fsck.
All file systems, even fat has a sort of directory hard links to . and ..
but no others, and there is no need, it can be fixed with autofs.
/bb
Note that a hard link is a short cut to the desired file. It goes there
immediately, it doesn't go through Go! and it doesn't collect money.
As such, it can, indeed, bypass any access protection on the directory
hierarchy above the desired file.
A softlink, however, follows the perscribed path, i.e. it just permits
you to replace a path by a single directory entry. Thus, when you want
to access the desired file, you'll follow the path and if any entry
within that path does not permit you to go further, you can't.
Josef
--
These are my personal views and not those of Fujitsu Technology Solutions!
Josef M�llers (Pinguinpfleger bei FTS)
> bb wrote:
>> On 2009-11-10 22:51, Nordlöw wrote:
>>> What are hard links used for?
>>>
>>> /Nordlöw
>>
>>
>> % echo hello > contents
>> % ln -s contents softlink
>> % ln contents hardlink
>> % rm contents
>> % cat softlink
>> cat: softlink: No such file or directory
>> % cat hardlink
>> hello
>>
>>
>> You can for example have a directory that only members of group a
>> can access
>> and another that only group b can access.
>> with a hard link it's possible to have the same file in both of them.
>>
>> A hard link is also useful when a process is chrooted but need to
>> share a file
>> with a not chrooted program using the same path, and so on.
>> The limit is that it must be the same file system while a soft link
>> can cross
>> over file systems.
>
> Note that a hard link is a short cut to the desired file. It goes
> there immediately, it doesn't go through Go! and it doesn't collect
> money.
> As such, it can, indeed, bypass any access protection on the directory
> hierarchy above the desired file.
The hard link itself doesn't provide any way to bypass protections.
First, the protections on the file itself are in the file's inode, and
aren't affected by any hard links to it. Second, you have to have
proper accesses at every level of some path that leads to the file.
> A softlink, however, follows the perscribed path, i.e. it just permits
> you to replace a path by a single directory entry. Thus, when you want
> to access the desired file, you'll follow the path and if any entry
> within that path does not permit you to go further, you can't.
>
> Josef
--
[...]
> Note that a hard link is a short cut to the desired file. It goes
> there immediately, it doesn't go through Go! and it doesn't collect
> money. As such, it can, indeed, bypass any access protection on the
> directory hierarchy above the desired file.
I believe to remember that this was already written, but the text
above again obscures it somewhat: Technically, the term 'hard link'
is a misnomer: Originally (before so-called symbolic links existed),
this was called 'a link' because it links a name residing in some
directory to a file. At any given time, a file may have any number
(presumably subject to some implementation limit) of names associated
with it and they are all perfectly equal. As opposed to this, a
symbolic link associates a new name with another name and this other
name may refer to anything, with anything possibly changing over time,
or even not exist at all.
I was referring to "the directory hierarchy above the desired file.":
josef@bounty:/tmp$ mkdir closed
josef@bounty:/tmp$ echo Hi there > closed/file
josef@bounty:/tmp$ mkdir open
josef@bounty:/tmp$ cd open
josef@bounty:/tmp/open$ ln ../closed/file file_h
josef@bounty:/tmp/open$ ln -s ../closed/file file_s
josef@bounty:/tmp/open$ cat file_h
Hi there
josef@bounty:/tmp/open$ cat file_s
Hi there
josef@bounty:/tmp/open$ chmod 000 ../closed/
josef@bounty:/tmp/open$ cat file_h
Hi there
josef@bounty:/tmp/open$ cat file_s
cat: file_s: Permission denied
So, a hard link will get you past the 000 of /tmp/closed, a soft link
will not.
Josef
--
These are my personal views and not those of Fujitsu Technology Solutions!
Josef Möllers (Pinguinpfleger bei FTS)
[...]
A 'link' is a directory entry pointing to a particular file and access
to the directory which happens to contain the link is governed by the
permissions of the directory itself and its parent directories, up to
/. A 'symbolic link' is an alias for a particular path name.
Your initial post could easily be misread as saying a hard link somehow
provides a way to bypass Unix filesystem security, and I was clarifying
that. Your example isn't disputing what I said, it's an example of it.
ACK. Sorry for the misunderstanding.
ACK. Sorry for the misunderstanding.
Josef