A listagem do conteúdo do diretório com caminho absoluto não é igual à listagem com o caminho relativo?

Question

Eu lancei a instância do Ubuntu 14.01 na AWS usando sua API (com Python e Boto).

Alterei as propriedades do dispositivo raiz - 30 GB em vez do padrão 8 GB e usei o disco magnético standard em vez do geral ssd gp2 .

Após o término da inicialização, descobri que /etc/resolv.conf symlink (- > ../run/resolvconf/resolv.conf ) parece estar corrompido.

E isso aconteceu:

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

Esse ambiente não está mais ativo, por isso não posso executar nenhum comando de depuração adicional, mas talvez alguém possa me explicar o que aconteceu aqui? Como isso é possível em primeiro lugar?

    

Answer 1

A única explicação que posso pensar é que você acessou /etc de um symlink, então ../ não foi realmente / , mas outra coisa. Por exemplo:

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

3 directories, 0 files

No exemplo acima, foo/bar é um link para ./bar . Agora, considere isto:

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

Como você pode ver acima, ls ../ listou o conteúdo de ~/testdir e não ~/testdir/foo . Portanto, se você acessou /etc através de um link, o ../ seria o diretório pai do link e não o diretório pai de /etc .

Eu não tenho ideia do que esse link poderia ter sido. Não vejo candidatos prováveis em minha VM do Ubuntu e a única run/udev instância que encontro está em /run . Ainda assim, se o que você descreveu aconteceu enquanto você mostra e não foi apenas um bug estranho, você provavelmente estava em algum lugar em um diretório vinculado.

    

Answer 2

A releitura da saída do terminal revelou-me a resposta:

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)

Na verdade, eu tinha um bug bobo no meu código que montou /dev/xvdf on / .