음.. 예상하지 못한 상황.. foo는 어디로 갔을까요?
글쓴이: seoleda / 작성시간: 목, 2004/05/13 - 11:19오전
/test/ $ ls src work /test/ $cd work /test/work $ ln -s ../src target /test/work $ cd target /test/work/target $ mv foo ..
이렇게 하니 foo란 화일이 test 라는 디렉토리에 들어 가네요 ^^
제가 test/work/target라는 경로를 사용했으므로, target의 부모인 wrok에 foo가 들어 가리라고 생각했습니다.
그런데 돌아가는 것은 target의 실제 디렉토리인 src의 부모 디렉토리인 test로 화일이 옮겨 지네요. -.-
src라는 디렉토리에서 작업을 했다면 모르지만, target라는 디렉토리에서 작업을 했으므로 사용자는 target의 부모디렉토리인 work로 옮기라고 지시한 상황이 명백합니다. 그런데 쉘은 다르게 해석했습니다.
이는 적절한 처벌을 받아야 할거 같은데요.
cp 역시 마찬가지로 동작합니다. 이는 수정되어야 하는게 아닐까요?
아니면, 설계상의 다른 이유나 보안상의 헛점이 있나요?
Forums:
Re: 음.. 예상하지 못한 상황.. foo는 어디로 갔을까요?
cd /test/work/target
cd -P ..
pwd
cd /test/work/
cd -P target
pwd
cd ..
pwd
해보세요... : )
cd 와 cp(mv)가 일관성 없이 동작하는 상황을 얘기한것입니다.
-P는 심볼릭링크를 따르지 않도록 하는거잖아요..
제 얘기는 target 디렉토리에서 foo를 복사를 하면, 월래 심볼릭 링크를 따라서 work디렉토리에 들어가야 맞다고 생각합니다. target는 디렉토리 구조가 work 아래이 있도록 되어 있으니깐요.
심볼릭 링크된 디렉토리에서 부모디렉토리로 mv나 cp를 사용하면, 실제 링크의 부모 디렉토리로 복사됩니다.
이는 cd .. 과는 엄연히 다르게 동작하죠.
위 예에서 target 에서 cd .. 하면 분명히 work로 갑니다.
하지만 target 에서 cp(mv) foo .. 을 하면 work 로 가지 않죠.
물론 검은해님이 알려주신 -P 옵션으로 cd도 cp(mv)와 일관성을 가지면서 동작하도록 할수는 있겠습니다. 하지만 cp(mv)가 cd와 동일하게 동작하는게 더 유저인터페이스 적인 측면에서 올바른것 같습니다. ^^
cd 는 외부 명령이 아닙니다. 외부 명령이 아니기 때문에 흔히 발생할
cd 는 외부 명령이 아닙니다. 외부 명령이 아니기 때문에 흔히 발생할 수 있는 여러가지 차이가 있을 수 있습니다.
/test/work/target
이것은
/test/src
와 같은 directory 로 되어 있는데,
/test/work/target/..
/test/src/..
이것을 해석하는 것이 단지 path 를 나타내는 문자열을 parsing하는 문제라면 달라지겠지만,
그 디렉토리에서 ls -ali 를 해서 나오는 inode를 통해 .. 을 해석하게 되면 항상 하나일 수 밖에 없습니다.
전통적으로 cp, mv 는 partition의 영향을 많이 받는 Utility 이므로 inode를 따라 수행되며, cd 는 현재 디렉토리에서 계산하여 path를 문자열로 계산하여 움직이는 것입니다.
외워야하죠.. :(
---
http://coolengineer.com
[quote="pynoos"]외워야하죠.. :([/quote]
구현내용이 다르다는 것은 이해하겠습니다.
그러나, 비전문가들에게 "이러이러한게 다르니 조심해라" 하는것 보단 처음부터 일관성있는 인터페이스를 제공하는게 바람직하다고 생각합니다.
따라서 cp(mv)와 cd가 일관성있게 동작하도록 코드를 고치고 싶습니다.
하지만 걸리는 것이 월래 일관성이 있었는데, 그렇게 하다보니 보안상 문제가 되어서 수정되지 않았을까 하는 우려가 됩니다.
Re: 음.. 예상하지 못한 상황.. foo는 어디로 갔을까요?
말씀하신 대로 움직인다면 제 생각엔 더 이상한 것 아닌가요? 제가 보기엔
target은 실제 디렉토리가 아니라, 디렉토리를 가리키는 링크일 뿐입니다.
따라서 링크가 가리키는 디렉토리의 부모(..)으로 가는 것이 일관된 동작
입니다. cp, mv도 마찬가지고요. 다운을 받고 있는 a.txt라는 파일을
같은 파티션 내에서 mv a.txt b.txt라고 하면 새로 a.txt가 생기는 것이
일관된다고 생각하시나요? 저는 아니라고 생각합니다. 이전에 제가 a.txt라고
불렀던 파일을 b.txt로 옮겼으므로 b.txt에 다운에 되어야 맞고, 실제로
그렇게 동작합니다. 당연히 cd도 그렇게 동작을 해야죠. 링크는 링크일 뿐입
니다. 편의상 디렉토리에 대한 링크는 디렉토리처럼, 파일에 대해서는 파일
처럼 "보일" 뿐이지요.
적어도 cp(mv) 와 cd의 경로를 해석하는 방법에 있어서 차이가 있어
적어도 cp(mv) 와 cd의 경로를 해석하는 방법에 있어서 차이가 있어서는 안된다고 생각합니다.
물론 mv a.txt b.txt 에서 b가 더 생기는 상황은 저도 원치 않습니다.
i-node 기반으로 되어 있는 cp(mv)를 고쳐서 위와 같이 원치 않는 상황이 발생하면 안돼죠.
하지만, 그렇게 보인다면 그렇게 동작해야 합니다. 전문가들이야 그냥 그렇구나 하고 쳐도 비전문가들에게는 납득할 만한 상황이 아니죠.
어떤 음악을 전공한 A가 리눅스에서 아주 좋은 프로그램이 있다고 해서, 그 프로그램을 사용하려고 리눅스를 깔고, 기본적인 사용법을 익혔습니다.
물론 cp(mv) 와 cd가 경로를 해석하는 방법이 다르다거나, 심볼릭 링크에 대해서는 전혀 관심없습니다. 그런데,
/test/work/target 의 내용을 /work/backup으로 옮길 일이 생겼습니다.
A는 target의 상위디렉토리는 work 이므로 다음과 같이 명령을 실행하고 흐뭇해 했습니다.
/test/work/target $ cp * ../backup
그럼 A는 /tast/work/backup 이라는 디렉토리를 찾을 수 있을까요?
적어도 cd에서 -P옵션을 디폴트로 사용해서 cd와 cp(mv)가 동일한 방식으로 경로를 해석한후에, A와 같은 경우에 한해서 당신의 생각과는 다르게 작동했다는 경고를 내내고, 당신의 backup 디렉토리는 src 아래로 복사되었다고 얘기를 해주거나, cp(mv)의 argument로 사용된 심볼릭 링크에 한해서는 cd와 동일하게 경로를 해석하도록 해야 하는것이 바람직하다고 생각합니다.
이러한 작은 배려가 리눅스를 더 멋지게 하고, 많은 사람들에게 사랑받도록 하는 방법이 아닐까 생각합니다.
[quote="seoleda"]이러한 작은 배려가 리눅스를 더 멋지게 하
필요하다면 alias cd cd -P 로 걸어두면 되겠지요. cp, mv 가 기본으로 심볼릭 링크를 따라간다면, 제 경우엔 엄청나게 열받을겁니다. 기존에 있는걸 무작정 대고 고쳐야된다고 하면 안되겠지요.
많은 사람들에게 사랑받으려면 GUI쪽을 발전시키는게 낫다고 봅니다 :)
어떤 파일 시스템상의 객체를 표현하는 방법이 위와 같이 여러방법이 있을
어떤 파일 시스템상의 객체를 표현하는 방법이 위와 같이 여러방법이 있을 때, 일어나는 일은 Unix 에서만 있는 일이 아닙니다.
예를 들어 윈도우의 내문서 폴더의 상위 폴더는 바탕화면인가요? 아니면, Documents and Settings\ID 인가요? 윈도우의 폴더 개념이라는 것은 디렉토리의 확장이면서 쉘익스텐션이라는 아주 재밌는 개념을 도입하면서 생긴 것입니다. 여기에서도 파일 시스템상의 객체를 표현할 때는 PIDL 이라는 것을 사용하여 표현하는 것으로 바뀌었습니다.
http://msdn.microsoft.com/library/en-us/shellcc/platform/shell/programmersguide/shell_faq.asp
보이는 것과 내부에서 표현하는 것이 다른 것으로 생기는 차이는 경험에 의존해서 이해해야합니다.
---
http://coolengineer.com
댓글 달기