questions

questions

Post by Doc » Sat, 24 May 2003 18:06:48



Hi guys
What's the difference between a phisic link and a simbolic link in UNIX?
Thinking that we are in a Unix directory (our home directory), how many
phisic links are there in it?
Best Regards
 
 
 

questions

Post by Lew Pitche » Mon, 26 May 2003 13:29:30


Without hesitation, Doc asserted (on or about 05/23/2003 05:06 AM) that:
 > Hi guys
 > What's the difference between a phisic link and a simbolic link in UNIX?
Below, I've attached an answer I wrote to a similar question. Note that
"soft link" is the same as "symbolic link", and "hard link" is the same
as "physical link".

 > Thinking that we are in a Unix directory (our home directory), how many
 > phisic links are there in it?

The only requirement is that there be at least two physical links in the
directory (although, there can be more). There's one to link to the
directory itself, and another to link to the directory's parent directory.
After that, there's a hard link to each file and directory listed in
the directory (except for those links that are not hard links - go figure).

See the explanation below, before I confuse you more.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Q: Can someone give me a simple explanation of the difference between a
    soft link and a hard link?  The documentation I've read mention these
    links but make no strong explanations of their meaning and how/when to
    use them.  Thanks!

A: OK, I'll give it a try...

    Unix files consist of two parts: the data part and the filename part

    The data part is associated with something called an 'inode'. The inode
    carries the map of where the data is, and the permissions, etc for the
    data.

                                .---------------> ! data ! ! data ! etc
                               /                  +------+ !------+
         ! permbits, etc ! data addresses !
         +------------inode---------------+

    The filename part carries a name and an associated inode number.

                          .--------------> ! permbits, etc ! addresses !
                         /                 +---------inode-------------+
         ! filename ! inode # !
         +--------------------+

    More than one filename can reference the same inode number; these files are
    said to be 'hard linked' together.

         ! filename ! inode # !
         +--------------------+
                         \
                          >--------------> ! permbits, etc ! addresses !
                         /                 +---------inode-------------+
         ! othername ! inode # !
         +---------------------+

    OTOH, there's a special file type, who's data part carries a path to
    another file. Since it is a special file, the OS recognizes the data as a
    path, and redirects opens, reads and writes so that, instead of accessing
    the data within the special file, they access the data in the file _named_
    by the data in the special file. This special file is called a 'soft link'.

         ! filename ! inode # !
         +--------------------+
                         \
                          .-------> ! permbits, etc ! addresses !
                                    +---------inode-------------+
                                                      /
                                                      /
                                                     /
     .----------------------------------------------'
    !
     '-->  !"/path/to/some/other/file"!
           +---------data-------------+
                   /                      }
     .~ ~ ~ ~ ~ ~ ~                       }-- (redirected at open() time)
    :                                     }
     '~~> ! filename ! inode # !
          +--------------------+
                          \
                           '------------> ! permbits, etc ! addresses !
                                          +---------inode-------------+
                                                             /
                                                            /
      .----------------------------------------------------'
      !
      '->  ! data !  ! data ! etc.
           +------+  +------+

    Now, the filename part of the file is stored in a special file of it's own
    along with the filename parts of other files; this special file is called a
    directory. The directory, as a file, is just an array of filename parts of
    other files.

    When a directory is built, it is initially populated with the filename parts
    of two special files: the '.' and '..' files. The filename part for the '.'
    file is populated with the inode# of the directory file in which the entry
    has been made. '.' is a hardlink to the file that implements the current
    directory.

    The filename part for the '..' file is populated with the inode# of the
    directory file that contains the filename part of the current directory
    file. '..' is a hardlink to the file that implements the immediate parent
    of the current directory.

    The 'ln' command knows how to build hardlinks and softlinks; the 'mkdir'
    command knows how to build directories (the OS takes care of the hardlinks).

    There are restrictions on what can be hardlinked (both links must reside on
    the same filesystem, the source file must exist, etc.) that are not
    applicable to softlinks (source and target can be on seperate file systems,
    source does not have to exist, etc.). OTOH, softlinks have other
    restrictions not shared by hardlinks (additional I/O necessary to complete
    file access, additional storage taken up by softlink file's data, etc.)

    In other words, there's tradeoffs with each.

    Now, let's demonstrate some of this...

    Let's start off with an empty directory, and create a file in it

    ~/directory $ ls -lia
    total 3
      73477 drwxr-xr-x   2 lpitcher users        1024 Mar 11 20:16 .
      91804 drwxr-xr-x  29 lpitcher users        2048 Mar 11 20:16 ..

    ~/directory $ echo "This is a file" >basic.file

    ~/directory $ ls -lia
    total 4
      73477 drwxr-xr-x   2 lpitcher users        1024 Mar 11 20:17 .
      91804 drwxr-xr-x  29 lpitcher users        2048 Mar 11 20:16 ..
      73478 -rw-r--r--   1 lpitcher users          15 Mar 11 20:17 basic.file

    ~/directory $ cat basic.file
    This is a file

    Now, let's make a hardlink to the file

    ~/directory $ ln basic.file hardlink.file

    ~/directory $ ls -lia
    total 5
      73477 drwxr-xr-x   2 lpitcher users        1024 Mar 11 20:20 .
      91804 drwxr-xr-x  29 lpitcher users        2048 Mar 11 20:18 ..
      73478 -rw-r--r--   2 lpitcher users          15 Mar 11 20:17 basic.file
      73478 -rw-r--r--   2 lpitcher users          15 Mar 11 20:17 hardlink.file

    ~/directory $ cat hardlink.file
    This is a file

    We see that
     a) hardlink.file shares the same inode (73478) as basic.file
     b) hardlink.file shares the same data as basic.file
    If we change the permissions on basic.file

    ~/directory $ chmod a+w basic.file

    ~/directory $ ls -lia
    total 5
      73477 drwxr-xr-x   2 lpitcher users        1024 Mar 11 20:20 .
      91804 drwxr-xr-x  29 lpitcher users        2048 Mar 11 20:18 ..
      73478 -rw-rw-rw-   2 lpitcher users          15 Mar 11 20:17 basic.file
      73478 -rw-rw-rw-   2 lpitcher users          15 Mar 11 20:17 hardlink.file

    then the same permissions change on hardlink.file.
    The two files (basic.file and hardlink.file) share the same inode and data,
    but have different file names.

    Let's now make a softlink to the original file

    ~/directory $ ln -s basic.file softlink.file

    ~/directory $ ls -lia
    total 5
      73477 drwxr-xr-x   2 lpitcher users        1024 Mar 11 20:24 .
      91804 drwxr-xr-x  29 lpitcher users        2048 Mar 11 20:18 ..
      73478 -rw-rw-rw-   2 lpitcher users          15 Mar 11 20:17 basic.file
      73478 -rw-rw-rw-   2 lpitcher users          15 Mar 11 20:17 hardlink.file
      73479 lrwxrwxrwx   1 lpitcher users          10 Mar 11 20:24 softlink.file ->
                                                                   basic.file

    ~/directory $ cat softlink.file
    This is a file

    Here, we see that, although softlink.file accesses the same data as
    basic.file and hardlink.file, it does not share the same inode (73479 vs
    73478), nor does it exhibit the same file permissions. It does show a new
    permission bit: the 'l' (softlink) bit.

    If we delete basic.file

    ~/directory $ rm basic.file

    ~/directory $ ls -lia
    total 4
      73477 drwxr-xr-x   2 lpitcher users        1024 Mar 11 20:27 .
      91804 drwxr-xr-x  29 lpitcher users        2048 Mar 11 20:18 ..
      73478 -rw-rw-rw-   1 lpitcher users          15 Mar 11 20:17 hardlink.file
      73479 lrwxrwxrwx   1 lpitcher users          10 Mar 11 20:24 softlink.file ->
                                                                   basic.file

    then we loose the ability to access the linked data through the softlink

    ~/directory $ cat softlink.file
    cat: softlink.file: No such file or directory

    However, we still have access to the original data through the hardlink

    ~/directory $ cat hardlink.file
    This is a file

    You will notice that when we deleted the original file, the hardlink didn't
    vanish. Similarly, if we had deleted the softlink, the original file wouldn't
    have vanished.

    A further note with respect to hardlink files:

    When deleting files, the data part isn't disposed of until all the filename
    parts have been deleted. There's a count in the inode that indicates how
    many filenames point to this file, and that count is decremented by 1 each
    time one of those filenames is deleted. When the count makes it to zero,
    the inode and it's associated data are deleted.

    Bye the way, the count also reflects how many times the file has been opened
    without being closed (in other words, how many references to the file are
    still active). This has some ramifications that aren't obvious at first:
    you can delete a file so that no "filename" part points to the inode,
    without releasing the space for the data part of the file, because the file
...

read more »

 
 
 

questions

Post by Doc » Mon, 26 May 2003 16:23:46


Thanks Lew you've been really clear in your explanation
Best Regards
Doc
"Lew Pitcher" <lpitc...@sympatico.ca> escribi en el mensaje
news:iigpab.sgk.ln@merlin.l6s4x6-4.ca...
> Without hesitation, Doc asserted (on or about 05/23/2003 05:06 AM) that:
>  > Hi guys
>  > What's the difference between a phisic link and a simbolic link in
UNIX?
> Below, I've attached an answer I wrote to a similar question. Note that
> "soft link" is the same as "symbolic link", and "hard link" is the same
> as "physical link".

>  > Thinking that we are in a Unix directory (our home directory), how many
>  > phisic links are there in it?

> The only requirement is that there be at least two physical links in the
> directory (although, there can be more). There's one to link to the
> directory itself, and another to link to the directory's parent directory.
> After that, there's a hard link to each file and directory listed in
> the directory (except for those links that are not hard links - go
figure).

> See the explanation below, before I confuse you more.

> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

> Q: Can someone give me a simple explanation of the difference between a
>     soft link and a hard link?  The documentation I've read mention these
>     links but make no strong explanations of their meaning and how/when to
>     use them.  Thanks!

> A: OK, I'll give it a try...

>     Unix files consist of two parts: the data part and the filename part

>     The data part is associated with something called an 'inode'. The
inode
>     carries the map of where the data is, and the permissions, etc for the
>     data.

>                                 .---------------> ! data ! ! data ! etc
>                                /                  +------+ !------+
>          ! permbits, etc ! data addresses !
>          +------------inode---------------+

>     The filename part carries a name and an associated inode number.

>                           .--------------> ! permbits, etc ! addresses !
>                          /                 +---------inode-------------+
>          ! filename ! inode # !
>          +--------------------+

>     More than one filename can reference the same inode number; these
files are
>     said to be 'hard linked' together.

>          ! filename ! inode # !
>          +--------------------+
>                          \
>                           >--------------> ! permbits, etc ! addresses !
>                          /                 +---------inode-------------+
>          ! othername ! inode # !
>          +---------------------+

>     OTOH, there's a special file type, who's data part carries a path to
>     another file. Since it is a special file, the OS recognizes the data
as a
>     path, and redirects opens, reads and writes so that, instead of
accessing
>     the data within the special file, they access the data in the file
_named_
>     by the data in the special file. This special file is called a 'soft
link'.

>          ! filename ! inode # !
>          +--------------------+
>                          \
>                           .-------> ! permbits, etc ! addresses !
>                                     +---------inode-------------+
>       /
>                                                       /
>                                                      /
>      .----------------------------------------------'
>     !
>      '-->  !"/path/to/some/other/file"!
>            +---------data-------------+
>                    /                      }
>      .~ ~ ~ ~ ~ ~ ~                       }-- (redirected at open() time)
>     :                                     }
>      '~~> ! filename ! inode # !
>           +--------------------+
>                           \
>                            '------------> ! permbits, etc ! addresses !
>                                           +---------inode-------------+
>                                                              /
>                                                             /
>       .----------------------------------------------------'
>       !
>       '->  ! data !  ! data ! etc.
>            +------+  +------+

>     Now, the filename part of the file is stored in a special file of it's
own
>     along with the filename parts of other files; this special file is
called a
>     directory. The directory, as a file, is just an array of filename
parts of
>     other files.

>     When a directory is built, it is initially populated with the filename
parts
>     of two special files: the '.' and '..' files. The filename part for
the '.'
>     file is populated with the inode# of the directory file in which the
entry
>     has been made. '.' is a hardlink to the file that implements the
current
>     directory.

>     The filename part for the '..' file is populated with the inode# of
the
>     directory file that contains the filename part of the current
directory
>     file. '..' is a hardlink to the file that implements the immediate
parent
>     of the current directory.

>     The 'ln' command knows how to build hardlinks and softlinks; the
'mkdir'
>     command knows how to build directories (the OS takes care of the
hardlinks).

>     There are restrictions on what can be hardlinked (both links must
reside on
>     the same filesystem, the source file must exist, etc.) that are not
>     applicable to softlinks (source and target can be on seperate file
systems,
>     source does not have to exist, etc.). OTOH, softlinks have other
>     restrictions not shared by hardlinks (additional I/O necessary to
complete
>     file access, additional storage taken up by softlink file's data,
etc.)

>     In other words, there's tradeoffs with each.

>     Now, let's demonstrate some of this...

>     Let's start off with an empty directory, and create a file in it

>     ~/directory $ ls -lia
>     total 3
>       73477 drwxr-xr-x   2 lpitcher users        1024 Mar 11 20:16 .
>       91804 drwxr-xr-x  29 lpitcher users        2048 Mar 11 20:16 ..

>     ~/directory $ echo "This is a file" >basic.file

>     ~/directory $ ls -lia
>     total 4
>       73477 drwxr-xr-x   2 lpitcher users        1024 Mar 11 20:17 .
>       91804 drwxr-xr-x  29 lpitcher users        2048 Mar 11 20:16 ..
>       73478 -rw-r--r--   1 lpitcher users          15 Mar 11 20:17
basic.file

>     ~/directory $ cat basic.file
>     This is a file

>     Now, let's make a hardlink to the file

>     ~/directory $ ln basic.file hardlink.file

>     ~/directory $ ls -lia
>     total 5
>       73477 drwxr-xr-x   2 lpitcher users        1024 Mar 11 20:20 .
>       91804 drwxr-xr-x  29 lpitcher users        2048 Mar 11 20:18 ..
>       73478 -rw-r--r--   2 lpitcher users          15 Mar 11 20:17
basic.file
>       73478 -rw-r--r--   2 lpitcher users          15 Mar 11 20:17
hardlink.file

>     ~/directory $ cat hardlink.file
>     This is a file

>     We see that
>      a) hardlink.file shares the same inode (73478) as basic.file
>      b) hardlink.file shares the same data as basic.file
>     If we change the permissions on basic.file

>     ~/directory $ chmod a+w basic.file

>     ~/directory $ ls -lia
>     total 5
>       73477 drwxr-xr-x   2 lpitcher users        1024 Mar 11 20:20 .
>       91804 drwxr-xr-x  29 lpitcher users        2048 Mar 11 20:18 ..
>       73478 -rw-rw-rw-   2 lpitcher users          15 Mar 11 20:17
basic.file
>       73478 -rw-rw-rw-   2 lpitcher users          15 Mar 11 20:17
hardlink.file

>     then the same permissions change on hardlink.file.
>     The two files (basic.file and hardlink.file) share the same inode and
data,
>     but have different file names.

>     Let's now make a softlink to the original file

>     ~/directory $ ln -s basic.file softlink.file

>     ~/directory $ ls -lia
>     total 5
>       73477 drwxr-xr-x   2 lpitcher users        1024 Mar 11 20:24 .
>       91804 drwxr-xr-x  29 lpitcher users        2048 Mar 11 20:18 ..
>       73478 -rw-rw-rw-   2 lpitcher users          15 Mar 11 20:17
basic.file
>       73478 -rw-rw-rw-   2 lpitcher users          15 Mar 11 20:17
hardlink.file
>       73479 lrwxrwxrwx   1 lpitcher users          10 Mar 11 20:24
softlink.file ->

basic.file

>     ~/directory $ cat softlink.file
>     This is a file

>     Here, we see that, although softlink.file accesses the same data as
>     basic.file and hardlink.file, it does not share the same inode (73479
vs
>     73478), nor does it exhibit the same file permissions. It does show a
new
>     permission bit: the 'l' (softlink) bit.

>     If we delete basic.file

>     ~/directory $ rm basic.file

>     ~/directory $ ls -lia
>     total 4
>       73477 drwxr-xr-x   2 lpitcher users        1024 Mar 11 20:27 .
>       91804 drwxr-xr-x  29 lpitcher users        2048 Mar 11 20:18 ..
>       73478 -rw-rw-rw-   1 lpitcher users          15 Mar 11 20:17
hardlink.file
>       73479 lrwxrwxrwx   1 lpitcher users          10 Mar 11 20:24
softlink.file ->

basic.file

>     then we loose the ability to access the linked data through the
softlink

>     ~/directory $ cat softlink.file
>     cat: softlink.file: No such file or directory

>     However, we still have access to the original data through the
hardlink

>     ~/directory $ cat hardlink.file
>     This is a file

>     You will notice that when we deleted the original file, the hardlink
didn't
>     vanish. Similarly, if we had deleted the softlink, the original file
wouldn't
>     have vanished.

>     A further note with respect to hardlink files:

>     When deleting files, the data part isn't disposed of until all the
filename
>     parts have been deleted. There's a count in the inode that indicates
how
>     many filenames point to this file, and that count is decremented by 1
each
>     time one of those filenames is deleted. When the count makes it to
zero,
>     the

...

read more »

 
 
 

questions

Post by Dragan Cvetkovi » Tue, 27 May 2003 10:26:21


[snip]

Quote:> Lew Pitcher

> Master Codewright and JOAT-in-training
> Registered Linux User #112576 (http://counter.li.org/)
> Slackware - Because I know what I'm doing.

Lew, what happened to your usual TD Bank signature?

Bye, Dragan

--
Dragan Cvetkovic,

To be or not to be is true. G. Boole      No it isn't.  L. E. J. Brouwer

 
 
 

questions

Post by Lew Pitche » Wed, 28 May 2003 00:21:45




> [snip]

>>Lew Pitcher

>>Master Codewright and JOAT-in-training
>>Registered Linux User #112576 (http://counter.li.org/)
>>Slackware - Because I know what I'm doing.

> Lew, what happened to your usual TD Bank signature?

> Bye, Dragan

Hi, Dragan


Codewright" status. When I post from work, I'm much more reserved <grin>

--

Lew Pitcher, IT Consultant, Application Architecture
Enterprise Technology Solutions, TD Bank Financial Group

(Opinions expressed here are my own, not my employer's)

 
 
 

questions

Post by Dragan Cvetkovi » Wed, 28 May 2003 02:25:46





> > [snip]

> >>Lew Pitcher

> >>Master Codewright and JOAT-in-training
> >>Registered Linux User #112576 (http://counter.li.org/)
> >>Slackware - Because I know what I'm doing.

> > Lew, what happened to your usual TD Bank signature?
> > Bye, Dragan

> Hi, Dragan


> Codewright" status. When I post from work, I'm much more reserved <grin>

> --

> Lew Pitcher, IT Consultant, Application Architecture
> Enterprise Technology Solutions, TD Bank Financial Group

> (Opinions expressed here are my own, not my employer's)

I see. Thanks.

Bye, Dragan

--
Dragan Cvetkovic,

To be or not to be is true. G. Boole      No it isn't.  L. E. J. Brouwer

 
 
 

questions

Post by Geoff Clar » Wed, 28 May 2003 21:32:22



>The only requirement is that there be at least two physical links in the
>directory (although, there can be more). There's one to link to the
>directory itself, and another to link to the directory's parent directory.

Where does this "requirement" come from, and what systems does it
apply to?

It's not required by the POSIX/UNIX standards.  They only specify how
the components "." and ".." are resolved when they occur in pathnames.
They do not require that directories contain entries for "." and "..".
--

 
 
 

questions

Post by Brian Ingli » Tue, 10 Jun 2003 17:22:15


On 27 May 2003 12:32:22 GMT in comp.unix.internals, Geoff Clare



>>The only requirement is that there be at least two physical links in the
>>directory (although, there can be more). There's one to link to the
>>directory itself, and another to link to the directory's parent directory.

>Where does this "requirement" come from, and what systems does it
>apply to?

unix filesystems ufs, ffs, ... do it this way.
they also add one to the directory reference count for each
subdirectory .. entry.

Quote:>It's not required by the POSIX/UNIX standards.  They only specify how
>the components "." and ".." are resolved when they occur in pathnames.
>They do not require that directories contain entries for "." and "..".

POSIX defines an interface, which may be implemented on top of
non-unix filesystems, especially on IBM OSes.

Thanks. Take care, Brian Inglis         Calgary, Alberta, Canada
--

    fake address                use address above to reply

 
 
 

questions

Post by Geoff Clar » Wed, 11 Jun 2003 21:43:00



>On 27 May 2003 12:32:22 GMT in comp.unix.internals, Geoff Clare


>>>The only requirement is that there be at least two physical links in the
>>>directory (although, there can be more). There's one to link to the
>>>directory itself, and another to link to the directory's parent directory.

>>Where does this "requirement" come from, and what systems does it
>>apply to?
>unix filesystems ufs, ffs, ... do it this way.

In other words, it's common existing practice.  That doesn't
make it a "requirement".

Quote:>they also add one to the directory reference count for each
>subdirectory .. entry.

That is also common existing practice, but not a "requirement".

Quote:>>It's not required by the POSIX/UNIX standards.  They only specify how
>>the components "." and ".." are resolved when they occur in pathnames.
>>They do not require that directories contain entries for "." and "..".
>POSIX defines an interface, which may be implemented on top of
>non-unix filesystems, especially on IBM OSes.

Well of course, if you include non-UNIX filesystems then anything
is possible.

My point was that since the standards do not require directories to
contain "." and ".." entries, portable applications should not rely
on their existence.  The same goes for the relationship between
the link count and the number of subdirectories.

--

 
 
 

1. Mini-Linux Distribution Questions + General Questions + UMSDOS Questions

Basically I have recently installed the Mini-Linux distribution (from
sunsite.unc.edu) on my box  (486 66, 12Mb, Limited HDD space), and it
works and installs fine, runs fine.... Great I thought, lets install
on several other PC's - Install on another 486d266 - won't even start
- LOADLIN doesn't even begin decompressing the kernal......
Then try a 486dx4100, this time it decompresses kernal and starts
linux startup, and comes up with a HDD sector size too big (its a
544Mb drive) and says "Giving up"..... Linux doesn't start at all.
Anyone else got an experience with this (the mini-linux distribution
is 1.0.9 kernal I think)

Next On the PC that mini-linux runs on, X won't start - cannot start
my graphics card (its an Advance Logic card, Vesa compatible).  Anyone
know how to fix this?

I run mini-linux for several reasons, the main one being the lack of
HDD space (I have 20Mb free without mini-linux, 0.5Mb with), howver I
have heard that the latest distributions include UMSDOS, so now onto
the UMSDOS questions:

Which kernal works best with UMSDOS, and will fit in 20Mb, with the
majority of data residing on CD?

Do the latest linux kernals support a SB16 and panasonic double speed
CD?  Also are NEC drives supported (a mate has one of these)

Basically I cannot delete my  DOS partition, as my family cannot use
linux to save their lives, and love MS word, so I need UMSDOS, so both
can happily reside on one partition (I don't want to partition)

Also does UMSDOS have any problem booting off a d: drive (I am
installing another 100Mb drive to try to alleviate the space problem)

Right thats it......
Thanks for your help and I apologize for the bad spelling in some
places (my software don't spell check).

IMPORTANT:  My news feed is knackered, so can replyies be by mail as
well as news please?

Dan (Linux newbie)

2. HELP: Printing prob

3. Questions, questions questions

4. Toshiba T3100SX - X Install?

5. 3 issues --- 1-Gnome Question, 2-CDRom Detect Question, 3-IMLIB Question

6. Emergency (for me): need static chown

7. Questions Questions Questions ???

8. GNOME set up... having a hiccup during GNOME start up.

9. Questions, Questions, and more Questions..

10. 3 issues --- 1-Gnome Question, 2-CDRom Detect Question, 3-IMLIB Question

11. Newbie Questions (ICEWM Background, ppp question, mem > 64mb)

12. sar Question (probably a newbie question)

13. A followup question to "A C question (about strlen)"