web-dev-qa-db-ja.com

シンボリックリンクが機能しないのはなぜですか？

私はシンボリックリンクをよりよく理解しようとしています...あまり運がありません。これは、ユーザー名/ホストを変更した実際のシェル出力です。

username@Host:~$ mkdir actual
username@Host:~$ mkdir proper
username@Host:~$ touch actual/file-1.txt
username@Host:~$ echo "file 1" > actual/file-1.txt
username@Host:~$ touch actual/file-2.txt
username@Host:~$ echo "file 2" > actual/file-2.txt
username@Host:~$ ln -s actual/file-1.txt actual/file-2.txt proper
username@Host:~$ # Now, try to use the files through their links
username@Host:~$ cat proper/file-1.txt
cat: proper/file-1.txt: No such file or directory
username@Host:~$ cat proper/file-2.txt
cat: proper/file-2.txt: No such file or directory
username@Host:~$ # Check that actual files do in fact exist
username@Host:~$ cat actual/file-1.txt
file 1
username@Host:~$ cat actual/file-2.txt
file 2
username@Host:~$ # Remove the links and go home :(
username@Host:~$ rm proper/file-1.txt
username@Host:~$ rm proper/file-2.txt

シンボリックリンクは、ファイルに直接アクセスしているかのようにそれが指すファイルを操作できるという意味で、透過的に動作するはずだと思いました（もちろん、rmの場合は除きます）もちろん、リンクは単に削除されます）。

linuxubuntubashsymbolic-link
24
orokusaki

シンボリックリンクは、フルパスまたはリンクへの相対パスを好む傾向があります。そうでない場合は、ローカルで_file-1.txt_を検索することがよくあります（奇妙なことに十分です）。

properに移動して_ls -l_を実行すると、シンボリックリンクが_actual/file-1.txt_であるはずの__../actual/file-1.txt_を探していることがわかります。

したがって、2つのオプションがあります。

  1. 完全なパスを与える

    _ln -s ~/actual/file-1.txt ~/actual/file-2.txt ~/proper
_

  2. リンクを入れたいフォルダに移動し、そこからリンクします

    _cd proper
ln -s ../actual/file-1.txt ../actual/file-2.txt ./
_

編集：タイピングを保存するためのヒント。

あなたは単に_ln -s ~/actual/file-{1,2}.txt ~/proper_を行うことができます

中かっこ内の項目は置き換えられ、互いの後に配置され、コマンドを作成します

    _ln -s ~/actual/file-1.txt ~/actual/file-2.txt ~/proper
_
53
nerdwaller

問題は相対パスの使い方です。完全な明示パスを使用してリンクの作成を指定すると、機能します。

$ ln -s〜/ actual/file1.txt〜/ actual/file2.txt〜/ proper /

$ catプロパティ/file1.txt

ファイル1

$

この例では、properにリンクを作成します。このリンクは、意図した両方の親ではなく、現在のディレクトリの下でactualという名前のサブディレクトリを探します。

3
Don Simon

シンボリックリンクは扱いにくい場合があります。本質的に、シンボリックリンクは、別のファイルのファイル名/パス名を含むファイルです（特別な扱いのためにフラグが立てられています）。リンクファイルのパス名が「/」で始まる場合、それは絶対パス名として扱われ、物事はかなり簡単です。スラッシュで始まらない場合は、リンクが配置されているディレクトリに対する相対パス名として扱われます。 （これは、名前にスラッシュが含まれているかどうかにかかわらず当てはまります。）したがって、「proper/file–1.txt」へのリンクとしてactual/file–1.txtを作成し、それにアクセスしようとすると、システムがproper/actual/file–1.txtにアクセスしようとしました。あなたは言っておくべきだった

ln –s  ../actual/file–1.txt  ../actual/file–2.txt  proper

ちなみに、touchコマンドは必要ありませんでした。 echo "file 1" > actual/file–1.txtを作成するには、actual/file–1.txtで十分です。

1
Scott

存在しない（またはパスを誤って指定した）ファイルへのリンクを作成しようとした場合、ln -sはエラーをスローしません。リンクを作成しますが、そのリンクで「猫」を試してみると、ファイルが見つからないことを示しています。 lsで確認できる場合でも。このような場合は、常にファイルパスを再確認してください。

ubuntu@ip-172-31-80-155:~/lab5$ ln -s etc/ufw/ufw.conf link1
ubuntu@ip-172-31-80-155:~/lab5$ ls -al
total 5360
drwxrwxr-x 2 ubuntu ubuntu    4096 Mar  9 18:56 .
drwxr-xr-x 7 ubuntu ubuntu    4096 Mar  9 18:42 ..
-rwxr--r-- 1 ubuntu ubuntu 5478400 Mar  9 18:32 backup.tar
lrwxrwxrwx 1 ubuntu ubuntu      16 Mar  9 18:56 link1 -> etc/ufw/ufw.conf
ubuntu@ip-172-31-80-155:~/lab5$ cat link1
cat: link1: No such file or directory

ファイルetc/ufw/ufw.confが存在しないためです。正しいパスは/etc/ufw/ufw.confです

ubuntu@ip-172-31-80-155:~/lab5$ ln -s /etc/ufw/ufw.conf link2
ubuntu@ip-172-31-80-155:~/lab5$ ls -l
total 5352
-rwxr--r-- 1 ubuntu ubuntu 5478400 Mar  9 18:32 backup.tar
lrwxrwxrwx 1 ubuntu ubuntu      16 Mar  9 18:56 link1 -> etc/ufw/ufw.conf
lrwxrwxrwx 1 ubuntu ubuntu      17 Mar  9 19:00 link2 -> /etc/ufw/ufw.conf
ubuntu@ip-172-31-80-155:~/lab5$ cat link2
# /etc/ufw/ufw.conf
#

# Set to yes to start on boot. If setting this remotely, be sure to add a rule
# to allow your remote connection before starting ufw. Eg: 'ufw allow 22/tcp'
ENABLED=no

# Please use the 'ufw' command to set the loglevel. Eg: 'ufw logging medium'.
# See 'man ufw' for details.
LOGLEVEL=low
0
sindhura

関連する問題であり、多くの人にとってそれは明白かもしれませんが、数分間困惑しました：それ自体がシンボリックリンクされているディレクトリ内にシンボリックリンクを作成している場合、または現在の作業ディレクトリのパス内にシンボリックリンクがある場合、シンボリックリンクが機能しない問題に遭遇します。

使用する cd ..およびls -l繰り返し、親ディレクトリ自体がシンボリックリンクされているかどうかを確認します。

シンボリックリンクを作成する必要がある場合は、元のターゲットディレクトリにcdし、そこに新しいシンボリックリンクを作成して、相対パスが正確になるようにします。

または別の言い方をすると、相対パスは原点からターゲットへのパスです。 Originがその後シンボリックリンクされた場合、それは問題ありません。しかし、それ自体が何らかの形でシンボリックリンクされているディレクトリ内に新しいOrigin link_nameを設定する際に問題が発生する可能性があります。

0
Chrisky