Список содержимого каталога с абсолютным путем не равен списку с относительным путем?

Question

Я запустил экземпляр Ubuntu 14.01 в AWS, используя его API (с Python и Boto).

Я изменил свойства корневого устройства - 30 ГБ вместо стандартных 8 ГБ и использовал standard магнитный диск вместо обычного ssd gp2 .

После завершения загрузки я обнаружил, что символическая ссылка /etc/resolv.conf (-> ../run/resolvconf/resolv.conf), похоже, не работает.

И чем это произошло:

root@ip-10-246-135-238:/etc# pwd
/etc
root@ip-10-246-135-238:/etc# ls ../run
udev
root@ip-10-246-135-238:/etc# ls /run
acpid.pid     atd.pid     crond.pid     dbus               initramfs  motd.dynamic       network                     plymouth   resolvconf    screen           shm   sshd.pid  udev                     upstart-socket-bridge.pid  user
acpid.socket  cloud-init  crond.reboot  dhclient.eth0.pid  lock       mount              network-interface-security  pppconfig  rsyslogd.pid  sendsigs.omit.d  sshd  systemd   upstart-file-bridge.pid  upstart-udev-bridge.pid    utmp

Эта среда больше не работает, поэтому я не могу запускать какие-либо дополнительные команды отладки, но, возможно, кто-то может объяснить мне, что здесь произошло? Как это возможно в первую очередь?

Answer 1

Единственное объяснение, которое я могу придумать, это то, что вы получили доступ к /etc по символической ссылке, поэтому ../ самом деле не было / но что-то еще. Например:

$ tree ~/testdir
/home/terdon/testdir
├── bar
└── foo
    └── bar -> ../bar/

3 directories, 0 files

В приведенном выше примере foo/bar является ссылкой на ./bar . Теперь рассмотрим это:

$ cd foo/bar
$ pwd
/home/terdon/testdir/foo/bar ## Note that the path follows the link
$ ls ../
bar  foo

Как вы можете видеть выше, ls ../ перечислил содержимое ~/testdir а не ~/testdir/foo . Таким образом, если вы получили доступ к /etc через ссылку, ../ будет родительским каталогом ссылки, а не родительским каталогом самого /etc

Я понятия не имею, что это за ссылка. Я не вижу вероятных кандидатов в моей виртуальной машине Ubuntu, и единственный экземпляр run/udev я нахожу, находится в /run сам по себе. Тем не менее, если то, что вы описываете, произошло так, как вы показываете, и это была не просто какая-то странная ошибка, вы, вероятно, были где-то в связанном каталоге.

Answer 2

Перечитав вывод терминала, я получил ответ:

root@ip-10-246-135-238:/etc# mount -v
/dev/xvda1 on / type ext4 (rw)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
none on /sys/fs/cgroup type tmpfs (rw)
none on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
udev on /dev type devtmpfs (rw,mode=0755)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)
none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)
none on /run/shm type tmpfs (rw,nosuid,nodev)
none on /run/user type tmpfs (rw,noexec,nosuid,nodev,size=104857600,mode=0755)
none on /sys/fs/pstore type pstore (rw)
systemd on /sys/fs/cgroup/systemd type cgroup (rw,noexec,nosuid,nodev,none,name=systemd)
/dev/xvdb on /mnt type ext3 (rw,_netdev)
/dev/xvdf on / type ext4 (rw)
/dev/xvdf on /mnt/image type ext4 (rw)

У меня на самом деле была глупая ошибка в моем коде, который монтировал /dev/xvdf на / .