精华内容
参与话题
问答
  • 硬链接

    2018-10-26 17:11:28
    硬链接:  有几个文件名对应着同一个inode,则硬链接数就为几  可以用来做备份  ln abc .abc  创建一个文件 指向 abc 的 inode 号,此时abc 的 inode号为 2 ,  当你删除 abc 时,实际上只是把指向这个...

    硬链接:

      有几个文件名对应着同一个inode,则硬链接数就为几

      可以用来做备份

      ln abc .abc

      创建一个文件 指向 abc 的 inode 号,此时abc 的 inode号为 2 ,

      当你删除 abc 时,实际上只是把指向这个inode 号的硬链接数减 1 ,

      虽然用 ls 命令查看时,abc 文件被删除了,但是abc文件的内容并没有被系统删除,

      因为它的硬链接数不为 0 ,此时你可以 .abc 文件依旧可以查看。

    这样做有什么好处呢 ?

      普通的拷贝备份需要占用与文件大小相同的空间 , 但是这个不占用那么多的空间

      对于文件的更改不需要对备份文件做更改,因为这两个文件指向的是同一个存储空间

      注意:

        硬链接不能跨分区创建

    展开全文
  • 区分 Linux 的硬链接与软链接

    万次阅读 2020-09-21 21:52:43
    从 inode 了解 Linux 文件系统 Linux 的文件与目录 现代操作系统为解决信息能独立于进程之外被长期存储引入了文件,文件作为进程创建信息的逻辑单元可被多个进程并发使用。在 UNIX 系统中,操作系统为磁盘上的文本...

    从 inode 了解 Linux 文件系统

    Linux 的文件与目录

    现代操作系统为解决信息能独立于进程之外被长期存储引入了文件,文件作为进程创建信息的逻辑单元可被多个进程并发使用。在 UNIX 系统中,操作系统为磁盘上的文本与图像、鼠标与键盘等输入设备及网络交互等 I/O 操作设计了一组通用 API,使他们被处理时均可统一使用字节流方式。换言之,UNIX 系统中除进程之外的一切皆是文件,而 Linux 保持了这一特性。为了便于文件的管理,Linux 还引入了目录(有时亦被称为文件夹)这一概念。目录使文件可被分类管理,且目录的引入使 Linux 的文件系统形成一个层级结构的目录树。清单 1.所示的是普通 Linux 系统的顶层目录结构,其中 /dev 是存放了设备相关文件的目录。

    清单 1. Linux 系统的顶层目录结构

    1

    2

    3

    4

    5

    6

    7

    8

    9

    10

    11

    12

    13

    14

    15

    16

    17

    18

    19

    /              根目录

    ├── bin     存放用户二进制文件

    ├── boot    存放内核引导配置文件

    ├── dev     存放设备文件

    ├── etc     存放系统配置文件

    ├── home    用户主目录

    ├── lib     动态共享库

    ├── lost+found  文件系统恢复时的恢复文件

    ├── media   可卸载存储介质挂载点

    ├── mnt     文件系统临时挂载点

    ├── opt     附加的应用程序包

    ├── proc    系统内存的映射目录,提供内核与进程信息

    ├── root    root 用户主目录

    ├── sbin    存放系统二进制文件

    ├── srv     存放服务相关数据

    ├── sys     sys 虚拟文件系统挂载点

    ├── tmp     存放临时文件

    ├── usr     存放用户应用程序

    └── var     存放邮件、系统日志等变化文件

    Linux 与其他类 UNIX 系统一样并不区分文件与目录:目录是记录了其他文件名的文件。使用命令 mkdir 创建目录时,若期望创建的目录的名称与现有的文件名(或目录名)重复,则会创建失败。

    1

    2

    3

    4

    5

    6

    # ls -F /usr/bin/zi*

    /usr/bin/zip*       /usr/bin/zipgrep*  /usr/bin/zipnote*

    /usr/bin/zipcloak*  /usr/bin/zipinfo*  /usr/bin/zipsplit*

     

    # mkdir -p /usr/bin/zip

    mkdir: cannot create directory `/usr/bin/zip': File exists

    Linux 将设备当做文件进行处理,清单 2.展示了如何打开设备文件 /dev/input/event5 并读取文件内容。文件 event5 表示一种输入设备,其可能是鼠标或键盘等。查看文件 /proc/bus/input/devices 可知 event5 对应设备的类型。设备文件 /dev/input/event5 使用 read() 以字符流的方式被读取。结构体 input_event 被定义在内核头文件 linux/input.h 中。

    清单 2. 打开并读取设备文件

    1

    2

    3

    4

    5

    6

    7

    int fd;

    struct input_event ie;

    fd = open("/dev/input/event5", O_RDONLY);

    read(fd, &ie, sizeof(struct input_event));

    printf("type = %d  code = %d  value = %d\n",

                ie.type, ie.code, ie.value);

    close(fd);

    硬链接与软链接的联系与区别

    我们知道文件都有文件名与数据,这在 Linux 上被分成两个部分:用户数据 (user data) 与元数据 (metadata)。用户数据,即文件数据块 (data block),数据块是记录文件真实内容的地方;而元数据则是文件的附加属性,如文件大小、创建时间、所有者等信息。在 Linux 中,元数据中的 inode 号(inode 是文件元数据的一部分但其并不包含文件名,inode 号即索引节点号)才是文件的唯一标识而非文件名。文件名仅是为了方便人们的记忆和使用,系统或程序通过 inode 号寻找正确的文件数据块。图 1.展示了程序通过文件名获取文件内容的过程。

    图 1. 通过文件名打开文件

    图 1. 通过文件名打开文件

    清单 3. 移动或重命名文件

    1

    2

    3

    4

    5

    6

    7

    8

    9

    10

    # stat /home/harris/source/glibc-2.16.0.tar.xz

     File: `/home/harris/source/glibc-2.16.0.tar.xz'

     Size: 9990512      Blocks: 19520      IO Block: 4096   regular file

    Device: 807h/2055d      Inode: 2485677     Links: 1

    Access: (0600/-rw-------)  Uid: ( 1000/  harris)   Gid: ( 1000/  harris)

    ...

    ...

    # mv /home/harris/source/glibc-2.16.0.tar.xz /home/harris/Desktop/glibc.tar.xz

    # ls -i -F /home/harris/Desktop/glibc.tar.xz

    2485677 /home/harris/Desktop/glibc.tar.xz

    在 Linux 系统中查看 inode 号可使用命令 stat 或 ls -i(若是 AIX 系统,则使用命令 istat)。清单 3.中使用命令 mv 移动并重命名文件 glibc-2.16.0.tar.xz,其结果不影响文件的用户数据及 inode 号,文件移动前后 inode 号均为:2485677。

    为解决文件的共享使用,Linux 系统引入了两种链接:硬链接 (hard link) 与软链接(又称符号链接,即 soft link 或 symbolic link)。链接为 Linux 系统解决了文件的共享使用,还带来了隐藏文件路径、增加权限安全及节省存储等好处。若一个 inode 号对应多个文件名,则称这些文件为硬链接。换言之,硬链接就是同一个文件使用了多个别名(见 图 2.hard link 就是 file 的一个别名,他们有共同的 inode)。硬链接可由命令 link 或 ln 创建。如下是对文件 oldfile 创建硬链接。

    1

    2

    link oldfile newfile

    ln oldfile newfile

    由于硬链接是有着相同 inode 号仅文件名不同的文件,因此硬链接存在以下几点特性:

    • 文件有相同的 inode 及 data block;
    • 只能对已存在的文件进行创建;
    • 不能交叉文件系统进行硬链接的创建;
    • 不能对目录进行创建,只可对文件创建;
    • 删除一个硬链接文件并不影响其他有相同 inode 号的文件。

    清单 4. 硬链接特性展示

    1

    2

    3

    4

    5

    6

    7

    8

    9

    10

    11

    12

    13

    14

    15

    16

    17

    18

    19

    20

    21

    22

    23

    24

    25

    26

    27

    28

    29

    30

    31

    32

    33

    # ls -li

    total 0

     

    // 只能对已存在的文件创建硬连接

    # link old.file hard.link

    link: cannot create link `hard.link' to `old.file': No such file or directory

     

    # echo "This is an original file" > old.file

    # cat old.file

    This is an original file

    # stat old.file

     File: `old.file'

     Size: 25           Blocks: 8          IO Block: 4096   regular file

    Device: 807h/2055d      Inode: 660650      Links: 2

    Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)

    ...

    // 文件有相同的 inode 号以及 data block

    # link old.file hard.link | ls -li

    total 8

    660650 -rw-r--r-- 2 root root 25 Sep  1 17:44 hard.link

    660650 -rw-r--r-- 2 root root 25 Sep  1 17:44 old.file

     

    // 不能交叉文件系统

    # ln /dev/input/event5 /root/bfile.txt

    ln: failed to create hard link `/root/bfile.txt' => `/dev/input/event5':

    Invalid cross-device link

     

    // 不能对目录进行创建硬连接

    # mkdir -p old.dir/test

    # ln old.dir/ hardlink.dir

    ln: `old.dir/': hard link not allowed for directory

    # ls -iF

    660650 hard.link  657948 old.dir/  660650 old.file

    文件 old.file 与 hard.link 有着相同的 inode 号:660650 及文件权限,inode 是随着文件的存在而存在,因此只有当文件存在时才可创建硬链接,即当 inode 存在且链接计数器(link count)不为 0 时。inode 号仅在各文件系统下是唯一的,当 Linux 挂载多个文件系统后将出现 inode 号重复的现象(如 清单 5.所示,文件 t3.jpg、sync 及 123.txt 并无关联,却有着相同的 inode 号),因此硬链接创建时不可跨文件系统。设备文件目录 /dev 使用的文件系统是 devtmpfs,而 /root(与根目录 / 一致)使用的是磁盘文件系统 ext4。清单 5.展示了使用命令 df 查看当前系统中挂载的文件系统类型、各文件系统 inode 使用情况及文件系统挂载点。

    清单 5. 查找有相同 inode 号的文件

    1

    2

    3

    4

    5

    6

    7

    8

    9

    10

    11

    12

    13

    14

    # df -i --print-type

    Filesystem     Type       Inodes  IUsed    IFree IUse% Mounted on

    /dev/sda7      ext4      3147760 283483  2864277   10% /

    udev           devtmpfs   496088    553   495535    1% /dev

    tmpfs          tmpfs      499006    491   498515    1% /run

    none           tmpfs      499006      3   499003    1% /run/lock

    none           tmpfs      499006     15   498991    1% /run/shm

    /dev/sda6      fuseblk  74383900   4786 74379114    1% /media/DiskE

    /dev/sda8      fuseblk  29524592  19939 29504653    1% /media/DiskF

     

    # find / -inum 1114

    /media/DiskE/Pictures/t3.jpg

    /media/DiskF/123.txt

    /bin/sync

    值得一提的是,Linux 系统存在 inode 号被用完但磁盘空间还有剩余的情况。我们创建一个 5M 大小的 ext4 类型的 mo.img 文件,并将其挂载至目录 /mnt。然后我们使用一个 shell 脚本将挂载在 /mnt 下 ext4 文件系统的 indoe 耗尽(见清单 6.)。

    清单 6. 测试文件系统 inode 耗尽但仍有磁盘空间的情景

    1

    2

    3

    4

    5

    6

    7

    8

    9

    10

    11

    12

    13

    14

    15

    16

    17

    18

    19

    20

    21

    22

    23

    24

    25

    26

    27

    28

    29

    30

    31

    32

    33

    34

    35

    # dd if=/dev/zero of=mo.img bs=5120k count=1

    # ls -lh mo.img

    -rw-r--r-- 1 root root 5.0M Sep  1 17:54 mo.img

    # mkfs -t ext4  -F ./mo.img

    ...

    OS type: Linux

    Block size=1024 (log=0)

    Fragment size=1024 (log=0)

    Stride=0 blocks, Stripe width=0 blocks

    1280 inodes, 5120 blocks

    256 blocks (5.00%) reserved for the super user

    ...

    ...

    Writing superblocks and filesystem accounting information: done

     

    # mount -o loop ./mo.img /mnt

    # cat /mnt/inode_test.sh

    #!/bin/bash

     

    for ((i = 1; ; i++))

    do

       if [ $? -eq 0 ]; then

           echo  "This is file_$i" > file_$i

       else

           exit 0

       fi

    done

     

    # ./inode_test.sh

    ./inode_test.sh: line 6: file_1269: No space left on device

     

    # df -iT /mnt/; du -sh /mnt/

    Filesystem     Type Inodes IUsed IFree IUse% Mounted on

    /dev/loop0     ext4   1280  1280     0  100% /mnt

    1.3M    /mnt/

    硬链接不能对目录创建是受限于文件系统的设计(见 清单 4.对目录创建硬链接将失败)。现 Linux 文件系统中的目录均隐藏了两个个特殊的目录:当前目录(.)与父目录(..)。查看这两个特殊目录的 inode 号可知其实这两目录就是两个硬链接(注意目录 /mnt/lost+found/ 的 inode 号)。若系统允许对目录创建硬链接,则会产生目录环。

    1

    2

    3

    4

    5

    6

    7

    8

    9

    10

    11

    12

    13

    14

    # ls -aliF /mnt/lost+found

    total 44

    11 drwx------ 2 root root 12288 Sep  1 17:54 ./

    2 drwxr-xr-x 3 root root 31744 Sep  1 17:57 ../

     

    # stat  /mnt/lost+found/

     File: `/mnt/lost+found/'

     Size: 12288        Blocks: 24         IO Block: 1024   directory

    Device: 700h/1792d      Inode: 11          Links: 2

    Access: (0700/drwx------)  Uid: (    0/    root)   Gid: (    0/    root)

    Access: 2012-09-01 17:57:17.000000000 +0800

    Modify: 2012-09-01 17:54:49.000000000 +0800

    Change: 2012-09-01 17:54:49.000000000 +0800

    Birth: -

    软链接与硬链接不同,若文件用户数据块中存放的内容是另一文件的路径名的指向,则该文件就是软连接。软链接就是一个普通文件,只是数据块内容有点特殊。软链接有着自己的 inode 号以及用户数据块(见 图 2.)。因此软链接的创建与使用没有类似硬链接的诸多限制:

    • 软链接有自己的文件属性及权限等;
    • 可对不存在的文件或目录创建软链接;
    • 软链接可交叉文件系统;
    • 软链接可对文件或目录创建;
    • 创建软链接时,链接计数 i_nlink 不会增加;
    • 删除软链接并不影响被指向的文件,但若被指向的原文件被删除,则相关软连接被称为死链接(即 dangling link,若被指向路径文件被重新创建,死链接可恢复为正常的软链接)。

    图 2. 软链接的访问

    图 2. 软链接的访问

    清单 7. 软链接特性展示

    1

    2

    3

    4

    5

    6

    7

    8

    9

    10

    11

    12

    13

    14

    15

    16

    17

    18

    19

    20

    21

    22

    23

    24

    25

    26

    27

    28

    # ls -li

     total 0

     

     // 可对不存在的文件创建软链接

     # ln -s old.file soft.link

     # ls -liF

     total 0

     789467 lrwxrwxrwx 1 root root 8 Sep  1 18:00 soft.link -> old.file

     

     // 由于被指向的文件不存在,此时的软链接 soft.link 就是死链接

     # cat soft.link

     cat: soft.link: No such file or directory

     

     // 创建被指向的文件 old.file,soft.link 恢复成正常的软链接

     # echo "This is an original file_A" >> old.file

     # cat soft.link

     This is an original file_A

     

     // 对不存在的目录创建软链接

     # ln -s old.dir soft.link.dir

     # mkdir -p old.dir/test

     # tree . -F --inodes

     .

    ├── [ 789497]  old.dir/

    │   └── [ 789498]  test/

    ├── [ 789495]  old.file

    ├── [ 789495]  soft.link -> old.file

    └── [ 789497]  soft.link.dir -> old.dir/

    当然软链接的用户数据也可以是另一个软链接的路径,其解析过程是递归的。但需注意:软链接创建时原文件的路径指向使用绝对路径较好。使用相对路径创建的软链接被移动后该软链接文件将成为一个死链接(如下所示的软链接 a 使用了相对路径,因此不宜被移动),因为链接数据块中记录的亦是相对路径指向。

    1

    2

    3

    4

    5

    $ ls -li

    total 2136

    656627 lrwxrwxrwx 1 harris harris       8 Sep  1 14:37 a -> data.txt

    656662 lrwxrwxrwx 1 harris harris       1 Sep  1 14:37 b -> a

    656228 -rw------- 1 harris harris 2186738 Sep  1 14:37 data.txt 6

    链接相关命令

    在 Linux 中查看当前系统已挂着的文件系统类型,除上述使用的命令 df,还可使用命令 mount 或查看文件 /proc/mounts。

    1

    2

    3

    4

    5

    6

    7

    # mount

    /dev/sda7 on / type ext4 (rw,errors=remount-ro)

    proc on /proc type proc (rw,noexec,nosuid,nodev)

    sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)

    ...

    ...

    none on /run/shm type tmpfs (rw,nosuid,nodev)

    命令 ls 或 stat 可帮助我们区分软链接与其他文件并查看文件 inode 号,但较好的方式还是使用 find 命令,其不仅可查找某文件的软链接,还可以用于查找相同 inode 的所有硬链接。(见清单 8.)

    清单 8. 使用命令 find 查找软链接与硬链接

    1

    2

    3

    4

    5

    6

    7

    8

    9

    10

    11

    12

    13

    14

    15

    16

    17

    18

    19

    20

    21

    22

    // 查找在路径 /home 下的文件 data.txt 的软链接

    # find /home -lname data.txt

    /home/harris/debug/test2/a

     

    // 查看路径 /home 有相同 inode 的所有硬链接

    # find /home -samefile /home/harris/debug/test3/old.file

    /home/harris/debug/test3/hard.link

    /home/harris/debug/test3/old.file

     

    # find /home -inum 660650

    /home/harris/debug/test3/hard.link

    /home/harris/debug/test3/old.file

     

    // 列出路径 /home/harris/debug/ 下的所有软链接文件

    # find /home/harris/debug/ -type l -ls

    656662 0 lrwxrwxrwx 1 harris harris 1 Sep 1 14:37 /home/harris/debug/test2/b -> a

    656627 0 lrwxrwxrwx 1 harris harris 8 Sep 1 14:37 /home/harris/debug/test2/a ->

    data.txt

    789467 0 lrwxrwxrwx 1 root root 8 Sep 1 18:00 /home/harris/debug/test/soft.link ->

    old.file

    789496    0 lrwxrwxrwx   1 root     root            7 Sep  1 18:01

    /home/harris/debug/test/soft.link.dir -> old.dir

    系统根据磁盘的大小默认设定了 inode 的值(见清单 9.),如若必要,可在格式文件系统前对该值进行修改。如键入命令 mkfs -t ext4 -I 512/dev/sda4,将使磁盘设备 /dev/sda4 格式成 inode 大小是 512 字节的 ext4 文件系统。

    清单 9. 查看系统的 inode 值

    1

    2

    3

    4

    5

    6

    7

    // 查看磁盘分区 /dev/sda7 上的 inode 值

    # dumpe2fs -h /dev/sda7 | grep "Inode size"

    dumpe2fs 1.42 (29-Nov-2011)

    Inode size:              256

     

    # tune2fs -l /dev/sda7 | grep "Inode size"

    Inode size:              256

    Linux VFS

    Linux 有着极其丰富的文件系统,大体上可分如下几类:

    1. 网络文件系统,如 nfs、cifs 等;
    2. 磁盘文件系统,如 ext4、ext3 等;
    3. 特殊文件系统,如 proc、sysfs、ramfs、tmpfs 等。

    实现以上这些文件系统并在 Linux 下共存的基础就是 Linux VFS(Virtual File System 又称 Virtual Filesystem Switch),即虚拟文件系统。VFS 作为一个通用的文件系统,抽象了文件系统的四个基本概念:文件、目录项 (dentry)、索引节点 (inode) 及挂载点,其在内核中为用户空间层的文件系统提供了相关的接口(见 图 3.所示 VFS 在 Linux 系统的架构)。VFS 实现了 open()、read() 等系统调并使得 cp 等用户空间程序可跨文件系统。VFS 真正实现了上述内容中:在 Linux 中除进程之外一切皆是文件。

    图 3. VFS 在系统中的架构

    图 3. VFS 在系统中的架构

    Linux VFS 存在四个基本对象:超级块对象 (superblock object)、索引节点对象 (inode object)、目录项对象 (dentry object) 及文件对象 (file object)。超级块对象代表一个已安装的文件系统;索引节点对象代表一个文件;目录项对象代表一个目录项,如设备文件 event5 在路径 /dev/input/event5 中,其存在四个目录项对象:/ 、dev/ 、input/ 及 event5。文件对象代表由进程打开的文件。这四个对象与进程及磁盘文件间的关系如图 4. 所示,其中 d_inode 即为硬链接。为文件路径的快速解析,Linux VFS 设计了目录项缓存(Directory Entry Cache,即 dcache)。

    图 4. VFS 的对象之间的处理

    图 4. VFS 的对象之间的处理

    Linux 文件系统中的 inode

    在 Linux 中,索引节点结构存在于系统内存及磁盘,其可区分成 VFS inode 与实际文件系统的 inode。VFS inode 作为实际文件系统中 inode 的抽象,定义了结构体 inode 与其相关的操作 inode_operations(见内核源码 include/linux/fs.h)。

    清单 10. VFS 中的 inode 与 inode_operations 结构体

    1

    2

    3

    4

    5

    6

    7

    8

    9

    10

    11

    12

    13

    14

    15

    16

    17

    18

    19

    struct inode {

       ...

       const struct inode_operations   *i_op; // 索引节点操作

       unsigned long           i_ino;      // 索引节点号

       atomic_t                i_count;    // 引用计数器

       unsigned int            i_nlink;    // 硬链接数目

       ...

    }

     

    struct inode_operations {

       ...

       int (*create) (struct inode *,struct dentry *,int, struct nameidata *);

       int (*link) (struct dentry *,struct inode *,struct dentry *);

       int (*unlink) (struct inode *,struct dentry *);

       int (*symlink) (struct inode *,struct dentry *,const char *);

       int (*mkdir) (struct inode *,struct dentry *,int);

       int (*rmdir) (struct inode *,struct dentry *);

       ...

    }

    如清单 10. 所见,每个文件存在两个计数器:i_count 与 i_nlink,即引用计数与硬链接计数。结构体 inode 中的 i_count 用于跟踪文件被访问的数量,而 i_nlink 则是上述使用 ls -l 等命令查看到的文件硬链接数。或者说 i_count 跟踪文件在内存中的情况,而 i_nlink 则是磁盘计数器。当文件被删除时,则 i_nlink 先被设置成 0。文件的这两个计数器使得 Linux 系统升级或程序更新变的容易。系统或程序可在不关闭的情况下(即文件 i_count 不为 0),将新文件以同样的文件名进行替换,新文件有自己的 inode 及 data block,旧文件会在相关进程关闭后被完整的删除。

    清单 11. 文件系统 ext4 中的 inode

    1

    2

    3

    4

    5

    6

    7

    8

    9

    10

    struct ext4_inode {

       ...

       __le32  i_atime;        // 文件内容最后一次访问时间

       __le32  i_ctime;        // inode 修改时间

       __le32  i_mtime;        // 文件内容最后一次修改时间

       __le16  i_links_count;  // 硬链接计数

       __le32  i_blocks_lo;    // Block 计数

       __le32  i_block[EXT4_N_BLOCKS];  // 指向具体的 block

       ...

    };

    清单 11. 展示的是文件系统 ext4 中对 inode 的定义(见内核源码 fs/ext4/ext4.h)。其中三个时间的定义可对应与命令 stat 中查看到三个时间。i_links_count 不仅用于文件的硬链接计数,也用于目录的子目录数跟踪(目录并不显示硬链接数,命令 ls -ld 查看到的是子目录数)。由于文件系统 ext3 对 i_links_count 有限制,其最大数为:32000(该限制在 ext4 中被取消)。尝试在 ext3 文件系统上验证目录子目录及普通文件硬链接最大数可见 清单 12. 的错误信息。因此实际文件系统的 inode 之间及与 VFS inode 相较是有差异的。

    清单 12. 文件系统 ext3 中 i_links_count 的限制

    1

    2

    3

    4

    5

    # ./dirtest.sh

    mkdir: cannot create directory `dir_31999': Too many links

     

    # ./linkcount.sh

    ln: failed to create hard link to `old.file': Too many links

    展开全文
  • 软链接和硬链接

    2015-04-23 19:32:30
    Linux之软链接和硬链接
  • 硬链接硬链接

    2016-06-05 17:34:05
    Linux链接分两种,一种被称为硬链接(Hard Link),另一种被称为符号链接(Symbolic Link)。默认情况下,ln命令产生硬链接 【硬连接】 硬连接的作用是允许一个文件拥有多个有效路径名,这样用户就可以...
    Linux链接分两种,一种被称为硬链接(Hard Link),另一种被称为符号链接(Symbolic Link)。默认情况下,ln命令产生硬链接

    【硬连接】
    硬连接的作用是允许一个文件拥有多个有效路径名,这样用户就可以建立硬连接到重要文件,以防止“误删”的功能。其原因如上所述,因为对应该目录的索引节点有一个以上的连接。只删除一个连接并不影响索引节点本身和其它的连接,只有当最后一个连接被删除后,文件的数据块及目录的连接才会被释放。也就是说,文件真正删除的条件是与之相关的所有硬连接文件均被删除。

    【软连接】
    符号连接(Symbolic Link),也叫软连接。软链接文件有类似于Windows的快捷方式。它实际上是一个特殊的文件。在符号连接中,文件实际上是一个文本文件,其中包含的有另一文件的位置信息。


    假如有一个文件1,建立1的一个软连接,并取名字为2:

     ln -s 1 2

    假如有一个文件1,建立1的一个硬连接,并取名字为2:

     ln  1 2



    硬链接的两个限制:

    1.不能创建到目录的硬链接

    2.只有在同一个文件系统的文件之间才能创建硬链接

    展开全文
  • HDFS符号链接和硬链接

    千次阅读 2016-10-15 15:31:07
    前言初看这个标题,可能很多人会心生疑问:符号链接和硬链接是什么意思?这些概念不是在Linux操作系统下才有的嘛,HDFS目前也有?当然大家可能还会有其他疑问,没关系,在后面的内容讲述中答案会一一揭晓。归纳起来...

    前言


    初看这个标题,可能很多人会心生疑问:符号链接和硬链接是什么意思?这些概念不是在Linux操作系统下才有的嘛,HDFS目前也有?当然大家可能还会有其他疑问,没关系,在后面的内容讲述中答案会一一揭晓。归纳起来一句话:不管是符号链接还是硬链接,它们本质上都是一种快捷的链接方式。熟悉Linux系统的同学应该都知道在Linux文件系统下有硬链接和软链接的概念,而HDFS同样作为一套文件系统,它也能支持文件链接的形式。本文所讲述的主题正是HDFS下的文件链接操作。

    相关背景:Linux软链接和硬链接


    在讲述HDFS下的文件链接内容之前,有必要了解一下相关内容:Linux软链接和硬链接。因为HDFS文件链接的原理设计基本与此相似。Linux软链接和硬链接分别代表着2种截然不同的连接形式,它们在作用上也存在部分微妙的差异。

    软链接


    软链接又被称为符号链接,英文名称soft link或symbolic link(HDFS内采用的软链接名称就是symbolic link,简称symlink)。就个人感觉而言,软链接在实际工作中用得频率会略高于硬链接。一句话简单地概括软链接的作用:

    软链接其实就是文件的一个快捷方式,软链接删除了,其指向的真实文件并不会受到影响。

    所以在实际的工作中,我们一般会把依赖资源包的路径用软链接的方式引用,这样的话资源包的路径可以一直保持不变,而其所指向的真实资源包可以根据使用场景进行任意变化

    硬链接


    硬链接,英文名称为hard link。它的一个主要目的在于文件的共享。文件的硬链接创建出来之后,它具有如下的特点:

    硬链接相当于文件的一个别名。它指向的是一个文件inode的引用地址,而非软链接中的文件路径指向。所以对于硬链接中的文件做修改会影响到其所指向的真实文件,当对硬链接做删除动作后,如果其所指向的文件inode当前没有被外部引用的话,则原文件会被删除,否则原文件不会被删除。

    上面的意思通俗地解释就是说,当真实文件或此文件的硬链接有一个存在的情况下,对文件执行删除操作,文件不会被真正删除。当只剩下一个文件inode引用的情况下,删除操作才能生效。

    HDFS符号链接(软链接)与硬链接概述


    了解完Linux下的软链接与硬链接的概念后,我们将进入本文的主题:HDFS下的符号链接与硬链接。

    Hadoop社区在HDFS-245(Create symbolic links in HDFS)中优先对符号链接功能进行了实现。符号链接另外一部分的工作在HADOOP-6421(Symbolic links)中,此部分是HADOOP-COMMON模块相关的底层代码改动。在硬链接方面,社区目前有相关的JIRA:HDFS-3370(HDFS hardlink),但是社区目前并没有在跟进,只有初始的设计文档。所以本文准备讲述的HDFS硬链接将会是一个设计模型,并未真正实现,这点需要注意

    鉴于目前HDFS的硬链接功能并未真正实现,所以本文的主讲内容还是符号链接的功能,硬链接功能将给出大致设计模型。

    HDFS符号链接(软链接)


    HDFS符号链接,在HDFS中称之为symbolic link,在下文的讲述中此名称都将会简称为symlink。与Linux文件系统中的软链接概念一样,HDFS符号链接也是相当于给目标文件新建一个自定义路径,这个自定义路径实质指向目标文件。所以在这里HDFS符号链接中做的最重要的事情就是路径的解析。而且这个解析还有可能是嵌套的,符号链接中指向的是另外一个符号链接。下面来学习HDFS符号链接的主要原理实现。

    HDFS符号链接原理


    HDFS符号链接功能的实现主要分为2个部分:一个是对现有文件符号链接的添加,另外一个则是符号链接的解析过程。

    对现有文件符号链接的添加在HDFS中的实现就是添加一个新的INode对象在NameNode中,只是这个INode对象是Symlink类型的,叫做INodeSymlink。此对象内部会包含一个实际指向的target地址。

    而符号链接的解析过程则会略微复杂一些,HDFS并不是直接在NameNode最终处理方法的地方做解析的,而是在前面一层FileContext类上做解析的,然后将解析好后的路径再传到HDFS中做处理。换句话说,客户端需要通过FileContext上下文对象来操作符号链接相关的操作,如果直接用FileSystem的API来操作的话,会抛出解析异常的错误

    HDFS符号链接核心代码实现


    此部分我们将通过部分代码的跟踪来学习HDFS符号链接的实现过程。

    同样首先是创建符号链接的过程,我们直接进入到最终的服务端处理方法,FSNamesystem的createSymlink方法。

       *// 为目标文件创建一个符号链接
      void createSymlink(String target, String link,
          PermissionStatus dirPerms, boolean createParent, boolean logRetryCache)
          throws IOException {
        if (!FileSystem.areSymlinksEnabled()) {
          throw new UnsupportedOperationException("Symlinks not supported");
        }
        HdfsFileStatus auditStat = null;
        writeLock();
        try {
          checkOperation(OperationCategory.WRITE);
          checkNameNodeSafeMode("Cannot create symlink " + link);
          // 此处进入创建软链接实际操作
          auditStat = FSDirSymlinkOp.createSymlinkInt(this, target, link, dirPerms,
                                                      createParent, logRetryCache);
          ...

    我们继续进入FSDirSymlinkOp的createSymlinkInt方法,

      static HdfsFileStatus createSymlinkInt(
          FSNamesystem fsn, String target, final String linkArg,
          PermissionStatus dirPerms, boolean createParent, boolean logRetryCache)
          throws IOException {
        FSDirectory fsd = fsn.getFSDirectory();
        String link = linkArg;
        // 检验符号链接的名称
        if (!DFSUtil.isValidName(link)) {
          throw new InvalidPathException("Invalid link name: " + link);
        }
        if (FSDirectory.isReservedName(target) || target.isEmpty()
            || FSDirectory.isExactReservedName(target)) {
          throw new InvalidPathException("Invalid target name: " + target);
        }
    
        if (NameNode.stateChangeLog.isDebugEnabled()) {
          NameNode.stateChangeLog.debug("DIR* NameSystem.createSymlink: target="
              + target + " link=" + link);
        }
    
        FSPermissionChecker pc = fsn.getPermissionChecker();
        INodesInPath iip;
        fsd.writeLock();
        try {
          // 解析得到符号链接的路径对象
          iip = fsd.resolvePathForWrite(pc, link, false);
          link = iip.getPath();
          ...
    
          // 将此符号链接对象加入到NameNode元数据中
          addSymlink(fsd, link, iip, target, dirPerms, createParent, logRetryCache);
          ...

    我们继续进入addSymlink方法,

      private static INodeSymlink addSymlink(FSDirectory fsd, String path,
          INodesInPath iip, String target, PermissionStatus dirPerms,
          boolean createParent, boolean logRetryCache) throws IOException {
        final long mtime = now();
        final INodesInPath parent;
        // 获取目标符号链接的父亲对象
        if (createParent) {
          // 如果需要创建父亲对象,则进行创建父目录操作方法
          parent = FSDirMkdirOp.createAncestorDirectories(fsd, iip, dirPerms);
          if (parent == null) {
            return null;
          }
        } else {
          parent = iip.getParentINodesInPath();
        }
        final String userName = dirPerms.getUserName();
        long id = fsd.allocateNewInodeId();
        PermissionStatus perm = new PermissionStatus(
            userName, null, FsPermission.getDefault());
        // 加入符号链接类型的INode对象到父对象中
        INodeSymlink newNode = unprotectedAddSymlink(fsd, parent,
            iip.getLastLocalName(), id, target, mtime, mtime, perm);
        ...

    最后调用到加入NameNode命名空间方法,

      static INodeSymlink unprotectedAddSymlink(FSDirectory fsd, INodesInPath iip,
          byte[] localName, long id, String target, long mtime, long atime,
          PermissionStatus perm)
          throws UnresolvedLinkException, QuotaExceededException {
        assert fsd.hasWriteLock();
        // 新建符号链接类型的INode对象
        final INodeSymlink symlink = new INodeSymlink(id, null, perm, mtime, atime,
            target);
        symlink.setLocalName(localName);
        // 将符号链接对象加入到最终路径对应的上一级父目录下
        return fsd.addINode(iip, symlink, perm.getPermission()) != null ?
            symlink : null;
      }

    至此,添加软链接操作正式完毕,与普通HDFS文件INode对象的添加过程类似。

    接下来我们来看另外一个部分的内容:HDFS符号链接的路径解析过程。这个过程是本文的一个重点。在没有学习HDFS符号链接源代码之前,本人一直以为HDFS把符号链接的解析过程放在了NameNode的处理方法中,但最终结果表明,事实并不是这样的

    假设我们直接以HDFS文件的符号链接进行读写操作,究竟会发生什么事情呢?这里我们以setReplication设置副本数操作为例。

    首先通过DFSClient端执行setReplication方法,

       *// 为指定的文件进行副本数的设置,假设我们这里传入的src路径是一个符号链接,而非真实文件地址
      public boolean setReplication(String src, short replication)
          throws IOException {
        checkOpen();
        try (TraceScope ignored = newPathTraceScope("setReplication", src)) {
          // 向服务端发起设置副本数操作请求
          return namenode.setReplication(src, replication);
        } catch (RemoteException re) {
          ...
        }
      }

    我们直接进入FSNamesystem的相应处理方法,

      boolean setReplication(final String src, final short replication)
          throws IOException {
        boolean success = false;
        checkOperation(OperationCategory.WRITE);
        writeLock();
        try {
          checkOperation(OperationCategory.WRITE);
          checkNameNodeSafeMode("Cannot set replication for " + src);
          // 调用真正设置副本数方法
          success = FSDirAttrOp.setReplication(dir, blockManager, src, replication);
        } catch (AccessControlException e) {
          logAuditEvent(false, "setReplication", src);
          throw e;
        } finally {
          writeUnlock();
        }
        ...
        return success;
      }

    这里进入FSDirAttrOp的setReplication方法,

      static boolean setReplication(
          FSDirectory fsd, BlockManager bm, String src, final short replication)
          throws IOException {
        bm.verifyReplication(src, replication, null);
        final boolean isFile;
        FSPermissionChecker pc = fsd.getPermissionChecker();
        fsd.writeLock();
        try {
          // 解析此路径得到INode路径对象
          final INodesInPath iip = fsd.resolvePathForWrite(pc, src);
          if (fsd.isPermissionEnabled()) {
            fsd.checkPathAccess(pc, iip, FsAction.WRITE);
          }
          // 对此路径进行副本的设置
          final BlockInfo[] blocks = unprotectedSetReplication(fsd, iip,
                                                               replication);
          ...

    至少从目前来看,我们还没看到解析符号链接的操作,我们继续进入设置副本的进一步操作:unprotectedSetReplication方法。

      static BlockInfo[] unprotectedSetReplication(
          FSDirectory fsd, INodesInPath iip, short replication)
          throws QuotaExceededException, UnresolvedLinkException,
          SnapshotAccessControlException, UnsupportedActionException {
        assert fsd.hasWriteLock();
    
        final BlockManager bm = fsd.getBlockManager();
        // 获取路径对象的最后一个节点,也就是最终需要设置副本的文件INode对象
        final INode inode = iip.getLastINode();
        if (inode == null || !inode.isFile() || inode.asFile().isStriped()) {
          // TODO we do not support replication on stripe layout files yet
          return null;
        }
        // 得到此INodeFile对象
        INodeFile file = inode.asFile();
        // Make sure the directory has sufficient quotas
        short oldBR = file.getPreferredBlockReplication();
    
        long size = file.computeFileSize(true, true);
        // Ensure the quota does not exceed
        if (oldBR < replication) {
          fsd.updateCount(iip, 0L, size, oldBR, replication, true);
        }
        // 对象文件对象进行副本数的设置
        file.setFileReplication(replication, iip.getLatestSnapshotId());
        short targetReplication = (short) Math.max(
            replication, file.getPreferredBlockReplication());
    
        ...
        return file.getBlocks();
      }

    在此方法中,HDFS直接从路径对象中取出文件INode对象,然后对其进行副本数的设置,从中并没有对符号链接进行解析的操作。我们重新把目光回到之前FSDirAttrOp的setReplication方法,在此方法中的fsd.resolvePathForWrite操作是否会有这样的解析动作呢,从方法名上看也确实包含了解析的单词。这里进入FSDirectory的resolvePathForWrite方法,

      INodesInPath resolvePathForWrite(FSPermissionChecker pc, String src)
          throws UnresolvedLinkException, FileNotFoundException,
          AccessControlException {
        // 此处调用同名方法,这里的第三个布尔参数代表解析到符号链接的INode对象时是否抛出异常
        return resolvePathForWrite(pc, src, true);
      }

    此方法中间会调用层层方法,最终调用INodesInPath类内部的resolve方法。此方法执行过程如下,

      static INodesInPath resolve(final INodeDirectory startingDir,
          final byte[][] components, final boolean isRaw,
          final boolean resolveLink) throws UnresolvedLinkException {
        Preconditions.checkArgument(startingDir.compareTo(components[0]) == 0);
    
        INode curNode = startingDir;
        int count = 0;
        int inodeNum = 0;
        INode[] inodes = new INode[components.length];
        boolean isSnapshot = false;
        int snapshotId = CURRENT_STATE_ID;
    
        while (count < components.length && curNode != null) {
          final boolean lastComp = (count == components.length - 1);
          inodes[inodeNum++] = curNode;
          final boolean isRef = curNode.isReference();
          final boolean isDir = curNode.isDirectory();
          final INodeDirectory dir = isDir? curNode.asDirectory(): null;
          if (!isRef && isDir && dir.isWithSnapshot()) {
            ...
          } else if (isRef && isDir && !lastComp) {
            ...
          }
          // 如果当前INode是符号链接类型并且当前需要抛出符号链接异常或当前不是最后一个INode对象时,
          // 都抛出异常
          if (curNode.isSymlink() && (!lastComp || resolveLink)) {
            final String path = constructPath(components, 0, components.length);
            final String preceding = constructPath(components, 0, count);
            final String remainder =
              constructPath(components, count + 1, components.length);
            // 获取符号链接地址
            final String link = DFSUtil.bytes2String(components[count]);
            // 获取符号链接真实指向地址
            final String target = curNode.asSymlink().getSymlinkString();
            if (LOG.isDebugEnabled()) {
              LOG.debug("UnresolvedPathException " +
                " path: " + path + " preceding: " + preceding +
                " count: " + count + " link: " + link + " target: " + target +
                " remainder: " + remainder);
            }
            // 抛出无法解析异常
            throw new UnresolvedPathException(path, preceding, remainder, target);
          }
          ...
        return new INodesInPath(inodes, components, isRaw, isSnapshot, snapshotId);
      }

    从上面的操作方法中,我们可以得出两个结论:

    • 第一点,HDFS符号链接的解析逻辑并不是实现在NameNode服务端的处理代码中。
    • 第二点,NameNode服务端中解析符号链接的目的在于帮助抛出解析异常信息,以此告诉用户当前处理的路径是一个符号链接地址。

    那么这部分的解析逻辑到底发生在了什么地方呢?这个答案我们可以从符号链接的单元测试实例中进行寻找,范例代码如下(同样以设置副本数操作为例):

       @Test
       /** setReplication affects the target not the link */  
       public void testSetReplication() throws IOException {
         Path file = new Path(testBaseDir1(), "file");
         Path link = new Path(testBaseDir1(), "linkToFile");
         createAndWriteFile(file);
         fc.createSymlink(file, link, false);
         // 此处通过fc对象进行设置,fc指的是文件上下文对象
         fc.setReplication(link, (short)2);
         assertEquals(0, fc.getFileLinkStatus(link).getReplication());
         assertEquals(2, fc.getFileStatus(link).getReplication());      
         assertEquals(2, fc.getFileStatus(file).getReplication());
      }

    上面符号链接的设置副本操作是通过fc对象进行的,fc对象的意思是文件上下文,此对象的初始化操作如下:

       @BeforeClass
       public static void testSetUp() throws Exception {
         Configuration conf = new HdfsConfiguration();
         conf.setBoolean(DFSConfigKeys.DFS_PERMISSIONS_ENABLED_KEY, true);
         conf.set(FsPermission.UMASK_LABEL, "000");
         cluster = new MiniDFSCluster(conf, 1, true, null);
         // 测试实例初始化操作中,得到文件上下文对象
         fc = FileContext.getFileContext(cluster.getURI());
       }

    至此,这也就是为什么我们不能直接用FileSystem对象进行符号链接相关操作执行的原因。

    下面我们来聊聊FileContext到底是如何帮助用户完成符号链接的解析过程的。比如说,现在我已经初始化好了一个FileContext对象,然后调用了setReplication操作,接着会触发到下面的方法,

      public boolean setReplication(final Path f, final short replication)
          throws AccessControlException, FileNotFoundException,
          IOException {
        final Path absF = fixRelativePart(f);
        // 调用解析器对象进行解析
        return new FSLinkResolver<Boolean>() {
          @Override
          public Boolean next(final AbstractFileSystem fs, final Path p) 
            throws IOException, UnresolvedLinkException {
            // next方法执行时,p已经代表了目标真实文件地址
            return fs.setReplication(p, replication);
          }
        }.resolve(this, absF);
      }

    所以以上的实现关键点在于FSLinkResolver的解析过程。我们进入此类,解析过程如下:

      public T resolve(final FileContext fc, final Path path) throws IOException {
        int count = 0;
        T in = null;
        Path p = path;
        // 获取初始文件系统
        AbstractFileSystem fs = fc.getFSofPath(p);
    
        // 进行循环解析,直到所有的符号链接地址都被解析成功
        for (boolean isLink = true; isLink;) {
          try {
            // 如果当前的路径解析成功,则更新标记为false,跳出循环,代表当前路径已解析成功
            in = next(fs, p);
            isLink = false;
          } catch (UnresolvedLinkException e) {
            ...
            // 否则出现符号链接时,解析当前第一层符号链接地址,fs.getLinkTarget(p)会获取当前符号链接地址所指向的真实地址
            p = qualifySymlinkTarget(fs.getUri(), p, fs.getLinkTarget(p));
            fs = fc.getFSofPath(p);
            // 然后用新的路径和文件系统对象进行下一次的操作执行
          }
        }
        return in;
      }

    fs.getLinkTarget(p)操作方法的实现,大家可以从DistributedFileSystem中查看其具体实现。

    所以,HDFS符号链接的总过程调用如下图所示:


    20161014221322931
    图 1-1 HDFS符号链接解析过程

    HDFS硬链接的原型设计


    鉴于前面花了大量的篇幅介绍了HDFS符号链接(软链接)的内容,最后简单介绍介绍HDFS硬链接的内容。因为此功能目前在HDFS中并未实现,只有原型设计,所以这里也将只会介绍社区上对于此功能的一个设计。

    HDFS硬链接的一个核心使用点在于它可以在无需拷贝真实数据的情况下,实现数据的共享。为了实现这样的功能,在HDFS-3370中的设计文档中,设计者引入了INodeHardLinkFile对象来代表当前的一个硬链接。这些对象共享HardLinkFileInfo对象。在HardLinkFileInfo对象中,会保持有当前的引用计数值,表示当前引用此文件的硬链接数,与Linux操作系统中的硬链接类似。

    下面通过图形展示的方式大致介绍一下HDFS硬链接的原型设计:

    首先,假设当前存在一个已存在的文件File1,如图1-2。


    20161015151401844
    图 1-2 HDFS初始文件

    此时对文件File1创建一个硬链接,同时名称也为File1不变,File1的INodeFile对象将会转化为INodeHardLinkFile对象,同时引用计数为1,此过程见图1-3。


    20161015151713754
    图 1-3 HDFS硬链接的创建

    在此基础上,如果还要对此文件进行硬链接的创建,即为INodeHardLinkFile的再次创建,但是引用的HarLinkFileInfo还是同一个对象,HarLinkFileInfo引用计数此时递增 2,此过程见图1-4。


    20161015151935506
    图 1-4 HDFS硬链接的再创建

    这个于Linux硬链接中的文件inode引用原理是完全一致的。当个别文件硬链接对象的删除将不会删除其真实的数据,除非硬链接文件当前没有其他的引用对象了。

    此设计文档的作者是来自于Facebook的某位工程师,本人估测此功能在Facebook内部已经早已实现,HDFS硬链接更多设计细节,可以阅读参考资料中的链接地址。

    参考资料


    [1].https://issues.apache.org/jira/browse/HDFS-245
    [2].https://issues.apache.org/jira/browse/HDFS-3370
    [3].https://issues.apache.org/jira/browse/HADOOP-6421
    [4].https://issues.apache.org/jira/secure/attachment/12526189/HDFS-HardLink.pdf

    展开全文
  • Linux 硬链接与软链接

    2019-02-14 14:14:51
    在Linux中,连接文件有两种,一种类似于Windows的快捷方式,可以让你快速地链接到目标文件(或...这种称为硬链接(hard link),也叫作实体链接。 软链接与硬链接是两种完全不一样的东西。 1.硬链接(hard link) 1...
  • linux软链接和硬链接

    万次阅读 2010-06-12 16:15:00
    简而言之:软链接相当于windows中的快捷方式硬链接相当于一个灾备系统,数据存放在两处,与复制不同的是两处之间存在同步机制,一处数据的改变会实时同步到另一处,另外一处数据如果被删除了,不会影响到另一处的...
  • linux命令ln用来为文件创建链接,链接这一概念类似于windows中的“快捷方式”,链接类型分为硬链接和软链接,命令格式: ln (参数) 源文件 链接  默认是创建硬链接,而参数-s为软链接。 所谓硬链接,就是在本...
  • 20-硬链接与软链接

    千次阅读 2016-12-01 23:05:53
    首先,我们要理解的一个概念是:什么是链接?链接是一个传送门。当你使用 vim 打开一个链接的时候,看到的...既然如此,为什么还区分硬链接和软链接?它们的区别在哪里?1 回忆 dir_entry如果你不知道什么是 dir_entr
  • 软链接和硬链接到底有啥作用和区别

    万次阅读 多人点赞 2018-01-22 11:38:32
    关于软硬链接的解释都太模糊,还有什么i节点,跨分区根本弄不明白,在查阅了书籍和询问老师后决定自己写一篇简单的博文,然初学者都能够明白的博文。一 建立软链接和硬链接的语法软链接:ln -s 源文件 目标文件 ...
  • Linux 的文件与目录现代操作系统为解决信息能独立于进程之外被长期存储引入了文件,文件作为进程创建信息的逻辑单元可被多个进程并发使用。在 UNIX 系统中,操作系统为磁盘上的文本与图像、鼠标与键盘等输入设备及...
  • 现代操作系统为解决信息能独立于进程之外被长期存储引入了文件,文件作为进程创建信息的逻辑单元可被多个进程并发使用。在 UNIX 系统中,操作系统为磁盘上的文本与图像、鼠标与键盘等输入设备及网络交互等 I/O 操作...
  • 硬链接软链接

    2019-09-24 15:32:02
    硬链接: 创建目录: mkdir min 创建一个目录min,在该目录下创建一个文件1.txt, ls 输入文本内容,cat 查看文本内容 查看文件属性 可以看出,该文件的innode :686821 link: 1 当给1.txt链接一个文件1_hard.txtt时...
  • 硬链接 软链接

    2009-10-09 10:43:00
    硬链接[oracle@dcm ~]$ ln original.file hard.link软链接[oracle@dcm ~]$ ln -s original.file soft.link[oracle@dcm ~]$ ls -l-rw-r--r-- 2 oracle oinstall 4 Jul 14 17:21 original.file-rw-r--r-- 2 oracle o.....
  • windows文件硬链接

    2013-07-12 03:20:19
    可以copy链接,尤其适用于dropbox,比如你想把其他地方的文件放到dropbox上,可以利用此软件,做一个链接
  • 软链接硬链接

    2018-04-06 16:55:47
    硬链接 ln /tmp/test.txt /tmp/test 软链接 ln -s /temp/test.txt /tmp/tes 硬链接:在当前目录下的inode中添加一个文件名,并将其指向的inode指向为/tmp/test.txt的inode。这样这两个文件使用同一个inode,如果...
  • 软链接 硬链接

    2017-10-11 09:49:22
    硬链接与软链接的联系与区别 我们知道文件都有文件名与数据,这在 Linux 上被分成两个部分:元数据 (metadata) 是文件的附加属性,如文件大小、创建时间、所有者等信息。用户数据 (user data) 即文件数据块 (data ...
  • linux硬链接和软链接的区别

    千次阅读 2017-12-23 14:07:04
    你可以将链接简单地理解为 Windows 中常见的快捷方式(或是 OS X 中的替身),Linux 中常用它来解决一些库版本的问题,通常也会将一些目录层次较深的文件链接到一个更易访问的目录中。在这些用途上,我们通常会使用...
  • 主要为大家详细介绍了什么是Linux软链接和Linux硬链接,在默认情况下,ln命令产生硬链接,感兴趣的小伙伴们可以参考一下
  • Linux文件的软链接和硬链接

    千次阅读 2015-07-27 13:29:11
    Linux链接概念Linux链接分两种,一种被称为硬链接(Hard Link),另一种被称为符号链接(Symbolic Link)。默认情况下,ln命令产生硬链接。1.1索引节点索引节点是指在许多类Unix文件系统中的一种数据结构。每个索引...
  • 主要介绍了Linux 硬链接和软链接详细介绍的相关资料,需要的朋友可以参考下
  • 理解 Linux 的硬链接与软链接

    千次阅读 2013-08-12 14:02:11
    Linux 的文件与目录 现代操作系统为解决信息能独立于进程之外被长期存储引入了文件,文件作为进程创建信息的逻辑单元可被多个进程并发使用。在 UNIX 系统中,操作系统为磁盘上的文本与图像、鼠标与键盘等输入设备及...

空空如也

1 2 3 4 5 ... 20
收藏数 9,028
精华内容 3,611
关键字:

硬链接