20101010 :: [회상] 우분투 리눅스를 재설치한 사연

하지말라면 하지 말자

역시, 하지말란 건 하면 안되는 것이었나 봅니다. 우분투 10.04를 잘 쓰고 있었고, 게다가 이 버전은 장기지원판으로 상당한 안정성을 자랑하고 있었습니다만, 몇 일 전 우분투 10.10의 개발버전 (알파인지 베타인지는 정확히 기억이 나지 않는 군요)이 배포된다는 소식을 듣고 또 몹쓸 “최신 버전 선호 사상”이 돋아나는 바람에 사고를 치고 말았습니다.

sudo update-manager -d

네, 뭣도 모르고 그 위험하다는 배포판 업그레이드를 감행해 버린 것이었습니다. 사실 상 우분투 10.04 버전도 알파2 상태에서 업그레이드를 감행했으나, 의외로 상당히 안정적으로 동작해주었고 (당시에는 무선랜이 안잡힌다던가 하는 많은 문제들이 있었음에도) 또, 9.10 버전부터는 대략 설치 후에 이것 저것 손봐야 하는 부분도 별로 없었기에 큰 두려움은 없었습니다.

어쨌든 배포판업그레이드는 무리 없이 끝이 났고 매일 매일 새로이 업데이트 되는 백여개의 패키지들을 꼬박꼬박 설치해가면서 잘 사용하고 있었는데, 몇 일전에 드디어 문제가 발생했습니다.

부팅 중 그래픽 모드로 전환이 되지 않고 커서만 검은 화면에서 껌뻑거리는 형태로 가만히 멈춰있더군요.

라이브 CD로 부팅해서 손을 볼까했는데, 어쩐 일인지 라이브CD 부팅 불가. 환장하고 미칠 노릇이었습니다. 결국 밀어버리고 새로 설치하기로 결심하였는데, 문제는 설치시디(라이브시디)로 설치절차를 로드하지도 못하고 그냥 먹통이 되는 경우가 있었습니다. (이는 10.04 버전의 새 설치시디의 문제였는지는 모르겠습니다. 하지만 9.10 으로 설치해서 업그레이드하기에는 도저히 엄두가 나지 않더군요)

어찌어찌해서 껐다 켰다를 반복하다보니, 열 번 중 한 번 꼴로 설치 화면이 정상적으로 노출되어 설치를 시작합니다. 윈도 7을 설치해보지 않아서 비교가 어렵지만 우분투의 설치 과정은 버전이 올라갈수록 조금씩 조금씩 더 다듬어져 사용하기 편리하게 업그레이드가 확실히 되고 있다고 느껴집니다. (게다가 속도도 아주 빠릅니다.)

재설치 후 문제

이것은 확실히 10.04를 클린 셋업했을 때 생기는 문제가 확실해 보입니다만, 설치를 마치고 재부팅을 하고 나니, 역시 또 부팅이 되지 않습니다. (부팅은 되는 것으로보이는데, 로그온 화면의 그 뚜둥하는 사운드가 들리고 커서도 나타나지만 여기에서 더 이상 진전이 되지 않습니다.) GRUB 화면에서 복구 모드를 선택하여 failsafe graphic mode로 부팅을 하면 정상적인 화면으로 로그인이 가능했습니다. 아마 그래픽 드라이버의 버전 문제인 듯 합니다. 여기서 가장 먼저 그래픽 드라이버 업데이트를 실시해야 합니다. 다른 업데이트를 아무 생각없이 설치하고 재부팅되면 나아지겠지…라고 했더니, 왠걸 이번에는 복구 모드로 부팅 중에 아예 벽돌이 되어버리더군요. 결국 눈물을 머금고 다음의 과정을 반복하여 다시 설치했습니다.

  1. 설치 시디를 넣고 설치 선택 화면을 기다린다. (많은 경우 설치 화면 윈도우를 제대로 그리지 못하는데, 이것은 설치 시디의 문제 혹은 CD롬의 문제로 보입니다.)
  2. 설치 언어는 ‘영어’를 선택한다. 한 번 이상 우분투를 설치해 본 경험이 있다면, 설치 과정을 영어로 선택한다고 해서 문제가 될 것은 없다.
  3. 설치 시에는 기존에 우분투가 설치되어 있던 파티션을 지정할 수 있도록 파티션을 수동으로 나누는 과정을 반드시 선택해야 한다.
  4. 설치가 완료되면 재부팅이 된다. 이 때 Recovery mode를 선택하고, 이후 나타나는 모드 선택화면에서 Failsafe Graphic Mode를 선택한다.
  5. 정상적으로 로그인 화면이 뜬다.
  6. 로그인하여 곧바로 SYSTEM > Administration > Hardware Drivers 를 선택한다. 사용 가능한 드라이버의 목록이 표시되는데, 이 때 recommended라 표시된 최신 버전 (current version)의 드라이버를 설치한다.
  7. 재부팅한다. 이 후부터는 정상적으로 부팅이 된다.

이상하게 느껴지는 것이 있다면, 9.04부터 설치하여 사용하고 9.04  > 9.10 > 10.04 > 10.10의 순차적인 버전 업데이트를 실시한 컴퓨터가 한 순간에 맛이 간다는게 좀 이상합니다. 아무래도 10.04 버전의 그래픽 드라이버가 제 노트북과 잘 맞지 않았는데 10.10 업그레이드 시에 해당 버전으로 회귀 (혹은 강제 업데이트)가 되어 문제가 발생한 것이 아닌가 싶습니다. 그전까지는 잘 사용했는데 10.04를 시디로 설치하고 맨 처음에 그 문제가 반복해서 나타났었거든요.

아무튼 오늘의 교훈은

고수님들의 말씀은 조상님들의 그것과 크게 다르지 않다. 위험하니 하지 말라면 하지 말자.

가 되겠군요.  우리 날짜로 내일이면 우분투 10.10의 정식 릴리즈가 있을 거라는 블로터 기사를 본 듯 합니다. (수상합니다. 전통적으로 해당 월의 거의 마지막 즈음에 릴리즈가 되어 왔는데, 특별히 10년 10월 10일에 배포하는 이벤트라도 준비하나 봅니다) 어쨌거나 정식버전이 릴리즈 되었다 하더라도 통상 RC에서는 베타를 거친 사람들은 어지간한 문제는 손수 해결했고, 그것이 RC에서는 보완되지 않아 문제가 발견되지 않는 경우가 많습니다. 또 문제가 발생했을 때 그 해법이 인터넷에 돌아다니기 시작하려면 어느 정도 시간이 필요하니, 우분투 새 버전은 서둘러 릴리즈 날짜에 업그레이드 하는 것은 추천하고 싶지 않습니다. 아 이 건 저 뿐만 아니라 다른 고수님들도 많이 하시는 말씀이니 들으시면 손해볼 것은 없다고 생각되네요 🙂

(그럼에도 불구하고 전 데스크톱 2대에는 모두 10.10을 또 냉큼 설치했더랬습니다. 뭐하는 짓인지…)

20100608 :: 리눅스에서 아이폰 동영상 인코딩하기 (ffmpeg)

지난 포스팅에서 문제가 되었던 부분은 결국 극복을 못했습니다. 워드프레스가 RC 버전이라 생긴 문제인지.. 암튼 계속 이어나갑니다.

Medibuntu의 힘을 빌리다.

Medibuntu 라는 Ubuntu의 사촌쯤 되는 배포판이 있습니다. 미디어 처리에 특화된 녀석으로 온갖 비디오, 오디오 코덱들을 많이 가지고 있는 녀석입니다. 이 녀석을 사용하면 아이폰용 동영상을 거뜬히 인코딩할 수 있다고 합니다.

그렇다고 사용하고 있는 우분투 배포판을 미디분투로 변신 시킬 필요는 없습니다. 다만 코덱 설치와 관련하여 Medibuntu의 저장소(repository)만 살짝 빌려올 생각입니다. 이 부분은 우분투 공식 문서 사이트를 참조하여 설치하도록 합니다. (해당 링크의 페이지에서 Adding The Repository 부분의 명령을 복사하여 터미널에서 실행합니다.)[1. 이 부분을 본문에 삽입하니 포스트가 저장이 안되는 문제가 있어서 뺐습니다.]

이 명령은 Medibuntu에서 사용하는 저장소를 추가하고, 키 인증을 받고, 패키지 목록을 새로 고치는 과정을 수행합니다. 이 과정 중에 인증에 실패했다는 경고가 나올 수 있지만 무시하면 됩니다.

그럼 혹시 모르니, 다음 패키지들을 설치 및 재설치 해보도록 하겠습니다.

  • ffmpeg
  • x264
  • faac
  • libavcodec-extra-52

명령어는 다음과 같습니다.

[bash]$ sudo apt-get –reinstall install ffmpeg x264 faac libavcodec-extra-52[/bash]

여기까지 하면 거의 준비가 끝났습니다. 다만, ffmpeg의 옵션이 매우 복잡합니다. 그래서 역시 구글링에서 얻은 옵션 값을 이용하여 스크립트를 하나 만들었습니다.

단 두 줄로 이루어졌습니다만, 좀 깁니다..

[bash]#!/bin/bash
ffmpeg -i "$1" -r 29.97 -vcodec libx264 -s 480×320 -aspect 16:9 -flags +loop -cmp +chroma -deblockalpha 0 -deblockbeta 0 -b 1000k -maxrate 1250k -bufsize 4M -bt 256k -refs 1 -coder 0 -me_method umh -me_range 16 -subq 7 -partitions +parti4x4+parti8x8+partp8x8 -g 250 -keyint_min 35 -level 30 -qmin 10 -qmax 51 -qcomp 0.6 -trellis 2 -sc_threshold 40 -i_qfactor 0.71 -acodec libfaac -ab 80k -ar 48000 -ac 2 "$1.mp4"[/bash]

위의 내용을 복사하여 메모장(gEdit)등에 붙여넣고 적당한 이름을 주고 저장합니다. 패스로 지정된 영역[1. /usr/share/bin 등에 저장하면 일반 내장 명령어처럼 호출할 수 있습니다.]에 저장해도 좋지만 여기서는 귀찮으니, 그냥 동영상 파일들이 있는 디렉터리에 저장하도록 합니다. 위 스크립트는 영상을 인코딩하여 원래 이름 뒤에 .mp4라는 확장자를 붙여서 그 결과를 만들어 내는 명령입니다.

예를 들어 이 스크립트를 aip 라는 이름을 주었다고 가정하겠습니다. 이제 해당 파일을 ‘실행가능하도록’ 만들어야 합니다. 리눅스는 파일 확장자 따위는 필요 없고 다만 ‘실행 가능한 권한’이 있으면 그냥 실행할 수 있습니다. (참 권한에 민감합니다…)

[bash]$ chmod 755 aip[/bash]

만약, 권한이 없다고 한다면 sudo chmod 755 aip로 해 줍니다. 제 경우에는 ntfs 드라이브에서 실행하니 권한이 없다고 하여 sudo 를 통해 실행 권한을 주었습니다.

그리고 해당 디렉터리에서 ./aip “개인의 취향 E01.avi” 라고 입력합니다. (이때 파일명 중간에 빈칸이 들어가서 따옴표로 일부러 둘러쌌습니다.) 그러자 인코딩이 됩니다. 조금 기다렸다 q를 눌러 중지하고 우선 컴퓨터 상에서 제대로 재생되는지 확인해 봅니다. 아무래도 제대로 재생이 되는 듯 하군요.

이제 인코딩을 한 방에 끝내버리겠습니다. 개인의 취향은 총 16편으로 구성되어 있고, 제 PC에는 “개인의취향.E01.avi”와 같은 식으로 이름이 정리되어 있습니다. 이를 한 방에 하려면 for 구문을 쓰면 되지요.

$ for x in 개인의*; do ./aip “$x” ;done

이렇게 작업을 시작한지 40분이 경과되었고, 고작 2편이 인코딩을 조금 전에 시작한 것 같습니다. h264 코덱은 인코딩에 엄청나게 많은 시간이 걸리는 군요. 인코딩 작업이 끝나면, 동영상이 제대로 아이폰에서 재생되는지 확인하고 후속 포스팅을 올리도록 하겠습니다.

긴 글 읽어주셔서 감사합니다.

20100427 :: 플래시 플레이어 10.1로 업그레이드 하기

Flash on Linux

리눅스에서 가장 신경이 많이 쓰이는 부분 중 하나는 바로 플래시가 사용된 웹사이트를 이용하는 순간입니다. 윈도 플랫폼에서는 비교적 성능도 나쁘지 않고 많이 안정된 상태이지만 리눅스 버전의 플래시 플레이어가 돌기 시작하면 대부분의 웹사이트에서는 CPU 사용률이 VirtualBox를 통해 윈도를 실행했을 때 보다도 더욱 미친 듯이 뛰어 오르기 시작합니다. 그러다 뻗어버리기도 하지요. 다행히 파이어폭스 3.6.3(4?)에서부터는 플러그인을 독립적인 프로세스로 실행하여 플래시가 죽더라도 웹 브라우저를 다시 시작해야 하는 불상사는 발생하지 않습니다만, 여전히 불안정하지요.

최신 버전 플래시로 업그레이드하기

게다가 요즘은 많은 웹사이트에서 파일 업로드 기능을 플래시로 제공하는 곳이 많습니다. 비교적 대용량의 파일을 업로드 하도록 한다거나, 혹은 여러 개의 파일을 동시에 업로드하는데는 기존의 웹 브라우저의 기능으로는 어려움이 많기 때문입니다.[1. HTML5에서는 멀티 파일 업로드가 지원되며, 파일 탐색기에서 끌어다 놓는 것도 지원됩니다. 이미 구글 크롬과 파이어폭스 3.6 이상을 사용하면 Gmail에서 이 기능을 사용할 수 있습니다.] 그런데 아무래도 불안정하다보니 파일을 업로드 하는 중간에 플러그인이 죽어버리거나, 파일 업로드가 완료되지 못하고 계속 멈추거나 하는 증상이 발생하곤 합니다.

그래서 한 번 모험을 시도해보기로 했습니다. 플래시를 최신 버전으로 업그레이드 해보는 것입니다. * 주의 : 이 방법으로 제 경우에는 비교적 안정적인 동작을 보입니다만, 시스템의 상태에 따라서는 저와 반대되는 결과가 나타날 수 있습니다.

설치된 플래시 버전 확인

먼저 시스템에 설치된 플래시의 버전을 확인해 봅니다. 아마 패키지 형태로 설치가 되었을 것입니다. 제 기억이 맞다면 파이어폭스 설치 후 플래시 플러그인 설치 화면에서 더나은 버전이 저장소에 있다고 하여 apt-get 명령으로 설치했던 것 같습니다. [2. 플래시 플러그인 패키지의 이름은 adobe-flashplugin입니다. 따라서 sudo apt-get install adobe-flashplugin이라는 명령으로 터미널에서 설치가 가능합니다.] 패키지 상의 버전을 확인하기 위해서는 dpkg 명령을 사용합니다.

dpkg -l | grep flash

그럼 결과가 아래와 비슷하게 보입니다.

ii        adobe-flashplugin                                        10.0.45.2-1karmic1

현재 플래시 플레이어의 최신 버전은 10.1 입니다. 지금 설치되어 있는 버전보다는 최신 버전이군요. 최신 버전이긴하지만 아직 공식적으로 배포된 버전은 아닙니다.  다운로드는 adobe labs 사이트에서 내려 받을 수 있습니다. 리눅스용 파일은 tar.gz 포맷으로 압축되어 있는 파일입니다. 해당 파일을 다운로드 받아 압축을 풀어 놓습니다. (여기서는 홈 폴더 아래에 downloads 라는 폴더에 압축을 풀어 두었다고 가정합니다.) 압축을 푸니 눈에 익은 .deb 파일이 아니라 .so 파일입니다. 예전에 아파치 서버 같은 거 보면 .so 라는 확장자를 가진 파일을 종종 본 듯도 합니다만, 이거 어떻게 설치해야 하는지 난감합니다. 어쩌면 그냥 파일만 교체하면 될 듯도 합니다. 그래서 한 번 찾아보기로 합니다.

find / -name “libflashplayer.so” (/ 슬래시를 빼먹지 않도록 주의. 빼 먹으면 현재 디렉토리에서부터 찾게 됩니다.)

이렇게 찾으면 결과 중에 ‘/usr/lib/adobe-flashplugin/libflashplayer.so‘라는 항목이 보입니다. 이 곳이 플래시 플레이어 플러그인 파일이 존재하는 곳입니다. 해당 디렉터리로 이동하여, 혹시 모르니 기존 파일을 백업해 놓습니다.

cd /usr/lib/adobe-flashplugin

sudo mv libflashplayer.so libflashplayer.so.backup [3. 팁: 파일 이름이 긴 경우에는 앞에 몇 글자만 입력하고 tab 키를 누르면 자동 완성 됩니다.]

그리고 아까 압축을 풀어놓은 파일을 이 곳으로 가져옵니다.

sudo cp ~/downloads/libflashplayer.so ./

이렇게 파일 이름이 길 때는 탭 신공이 큰 위력을 발휘합니다. 이제 브라우저를 재시작하면 됩니다.

복구방법

문제가 발생한 경우에는 아래와 같이 원상 복구하면 됩니다.

cd /usr/lib/adobe-flashplugin

sudo rm libflashplayer.so

sudo mv libflashplayer.so.backup libflashplayer.so

혹은 다음과 같이 apt-get 명령을 통해서 삭제 후 재설치 하는 방법도 있겠네요

sudo apt-get remove adobe-flashplugin; sudo apt-get install adobe-flashplugin[4. 팁2 : 패키지 이름의 경우에도 자동완성이 됩니다. 그리고 세미 콜론은 두 줄로 나눠쓸 명령어를 한 줄로 합쳐주는 기능입니다]

20100419 :: 궁극의 폴더 동기화 유틸리티 – DirSync Pro

리눅스에서도 쓸만한 폴더 동기화 유틸리티

딱 작년 이 맘 때 쯤 매우 유용한 폴더 동기화 유틸리티인 Allways Sync에 대한 글을 쓴 적이 있습니다. 리눅스로 넘어온 이후에 가장 아쉽고 미련이 남던 프로그램 중 하나였는데요, 물론 리눅스에도 rsync와 같은 간편한 프로그램이 있긴 합니다만 삼바를 통한 공유폴더로의 설정이 안된다든지 하는 문제점이 있습니다. (생각해보니 안될 것도 없다는 생각도 드네요) 20100419 :: 궁극의 폴더 동기화 유틸리티 – DirSync Pro 더보기

20100404 :: 심볼릭 링크에 대하여

리눅스를 쓰게 되면서 가장 많이 접하는 단어 중의 하나가 바로 ‘심볼릭 링크’라는 말이죠. 복사하기 귀찮거나 그러면 그냥 심볼릭 링크를 만들면 된다는 이야기는 참 많이 들었던 것 같습니다. 대충 앞뒤 상황을 보아하니 윈도의 ‘바로가기(shortcut)’와 같은 개념인 듯 합니다만… 그렇게 대충 알고 지내다가 오늘은 ‘하드 링크’라는 걸 또 알게 되어…. 아… 링크면 링크지 심볼릭은 뭐고 하드 링크는 또 뭐다냐…

윈도의 바로가기와 차이점

리눅스에서의 링크는 윈도의 ‘바로가기’와 비슷하면서도 또 많이 다릅니다. 정확하게는 ‘데이터 혹은 파일의 실체가 아닌 그 곳에 다다르는 통로’라는 개념으로 이해하면 되는데, 실제적으로는 이게 ‘바로가기’와 다를 바가 없다는 거죠. 차이가 있다면 ‘바로가기’는 결국 윈도의 파일 탐색기가 제공하는 경로 데이터 파일임에 반해, 링크는 리눅스의 파일 시스템 자체가 제공하는 기능이라는 이랄까요? 즉 무슨 말인고 하니 윈도 탐색기에서 어떤 프로그램이나 디렉터리의 바로가기를 바탕화면에 생성했다고 하면, 윈도의 바탕화면 폴더에는 해당 바로가기의 ‘파일’이 생성됩니다. 그리고 이 파일 안에는 어떤 아이콘을 표시해야하고, 가리키고 있는 대상의 경로는 무엇인지 따위의 정보가 기록되는 거죠. 우리는 실제로 이 바로가기 파일을 편집해서 참조하는 위치를 바꿀 수도 있어요. 그런데 리눅스에서 어떤 디렉터리에서 링크를 생성하면, 해당 디렉터리에는 목표지점(target)의 이름만이 생성됩니다. 만약 그 대상이 어떤 텍스트 파일이라 하고 cat somelink 라는 명령을 준다면, 링크의 내용이 아닌 목표 지점인 텍스트 파일의 내용이 그대로 출력된다는 이야기입니다. 한마디로 말해, 리눅스의 링크는 그 실체가 없다고 할까요.해당 링크에 접근하는 것은 원본 파일에 접근하는 것일 뿐, 링크 그 자체를 손볼 수 있는 방법은 없는 것처럼 보입니다.

그리고 또 재밌는 것은 링크를 통해 특정 지점에 접근하더라도, 사용자가 바라보는 경로는 마치 링크가 실제로 존재하는 것처럼 보인다는 것입니다. 아니 방금 전까지만 해도 리눅스의 링크는 실체가 없다고 해 놓고서는 무슨 소리냐고 할 수 있는데 사실은 이런거죠.

결국 파일 시스템 내의 어떤 지점이 여러 곳에서 여러 개의 이름을 갖는 것과 똑같다고 생각하면 됩니다. 너무 추상적이라 예를 들자면, 만약 /some/path/source 라는 디렉터리가 존재해서, /usr/local/links 라는 디렉터리에서 해당 지점으로 링크를 만들었다고 합시다. 링크의 이름은 타이핑하기 귀찮으니 s 로 하구요. 그래서 links 디렉터리에서 s로 이동한다면

/usr/local/links$ cd s
/usr/local/links/s$ ls

{실제로 /some/path/source 에 들어있는 파일 리스트가 쫙 뿌려집니다.}

이렇게 됩니다. 즉 링크는 목표지점을 완전히 직접적으로 연결하는 장치이고, 이를 통해 접근하는 경우 사용자는 원본의 경로로 직접 접근하는 것과 ‘아무런 차이점이 없이’ 특정 경로를 바로 액세스하는 효과를 누릴 수 있게되는 것이죠. 사실 이것은 좀 혼란스럽게 느껴질 수 있지만, 단일 자원의 무분별한 중복(복사본으로 넘쳐나는 불행!)을 방지하고 또한 변경 사항이 생기는 경우 모든 것이 동기화되는 개념이기 때문에 (왜냐면 원본은 하나 밖에 없으니까) 상당히 효율적이고 멋진 기능이라 할 수 있다.

하드 링크와 심볼릭 링크

그럼 이제 하드링크와 심볼릭 링크의 차이점에 대해 살펴보겠습니다. 먼저 보통 ‘링크’라고 이야기하면 일반적으로는 심볼릭 링크를 이야기하는 듯 합니다. 하드 링크는 하드 링크라고 별도로 명시하는 듯 하네요. 심볼릭 링크는 말 그대로 이름으로만 존재하는 링크에요. 만약 어떤 파일에 대해 다른 위치에서 심볼릭 링크를 만들었다고 하면, 해당 심볼릭 링크는 파일의 경로+파일이름과 완전히 동일하게 취급됩니다. 마치 링크가 존재하는 그 디렉토리에 텍스트 파일이 있는 것과 똑같은 효과가 있지요.(실제로도 그렇습니다. 링크는 원본 파일이 가진 파일 이름과 같이 또  다른 ‘이름’이니까요) 이 때 원본 파일을 에디터로 수정한 다음, 링크를 통해 해당 파일의 내용을 들여다보면 당연히 수정된 내용이 반영되어 보입니다. 만약 vi와 같은 에디터를 통해 링크를 수정한다면, 그것은 결국 ‘링크의 이름을 가진 원본 텍스트 파일’을 수정하는 것이므로 나중에 원본을 확인해보면 수정된 내용이 반영되어 있기도 하구요. 우리는 그저 “똑같은 파일이 요기잉네”와 같이 취급하면 됩니다.

여기까지는 어려울 것이 없어요. 그럼 하드 링크는 어떻게 동작할까요? 하드링크의 동작도 마찬가지 입니다. 링크를 만들어서 마치 해당 디렉터리에 파일이 위치하는 것처럼 액세스 할 수 있지요. 원본을 수정하면 링크를 통해 확인한 내용이 즉시 바뀐 것을 볼 수 있는 것도 똑같습니다. 그런데 만약, 원본을 지워버리면 어떻게 될까요? 하드 링크의 경우, 원본을 지우더라도 링크를 통해 확인해보면 해당 파일이 그대로 존재하는 것처럼 보입니다. 어이쿠야. 하드링크는 원본이 삭제되더라도 그 내용이 없어지지 않는다는 것이지요. 중요한 것은 원본이 삭제되기 전까지는 하드링크는 일반적인 링크의 역할만 하게 되지만 원본이 지워지게되면 하드 링크는 복사본의 역할을 수행하게 됩니다. 사실 이러한 동작은 거꾸로 특정 파일이 삭제될 때 실제로 파일 시스템 내에서 소멸되지 않고 어딘가에 숨어있으며, 그 위치는 여전히 하드 링크들에 의해 접근이 가능해진다는 이야기가 됩니다. 이건 대용량의 동영상 파일이나 iso 파일로 실험해 볼 수도 있어요. 수 백 메가바이트짜리 대용량 파일에 대해 링크를 생성하더라도 파일 시스템의 사용량은 거의 변화가 없습니다. 단순히 이름만 더 생겼단 의미겠지요. 그런데 원본을 삭제해도 역시 변화가 없다. 변화가 발생하는 것은 원본을 삭제한 후 하드 링크를 (두 개 이상의 하드링크가 존재했다면 모두 다)삭제하였을 때 그렇게 됩니다.

하드 링크 자체는 원본과 동기화된 파일이라고 생각해도 무방하기 때문에 ls -al를 통해 데이터의 유형을 살폈을 때도 그냥 파일과 다름없습니다만, 심볼릭 링크는 l이라고 당당히 링크의 신분을 밝힙니다.

심볼릭 링크는 원래 위치만을 참조하기 때문에 원본을 삭제하면 해당 링크는 그저 허공을 가리킬 뿐, 해당 파일이나 디렉터리가 없다는 에러 메시지를 뿜어내게 됩니다. 이것이 하드 링크와 심볼릭 링크의 차이점입니다. 아, 이제야 왜 하드링크와 소프트링크가 아닌 하드 링크와 심볼릭 링크의 차이점을 알 수 있겠네요. 그것은 ‘소프트링크’라고 쓰면 ‘소프트드링크’처럼 들리기 때문입니다!

링크 만들기

링크를 만드는 명령은 ln입니다. 이 명령은 다음과 같이 사용됩니다.

  1. ln {타겟의 위치} [링크의 이름]
  2. ln -s {타겟의 위치} [링크의 이름]

1번 방법은 하드 링크를 생성합니다. 링크 이름을 별도로 주지 않으면 원본과 같은 이름의 링크가 생성됩니다. 2번처럼 -s 옵션을 주면 심볼릭 링크가 생성됩니다. 역시 링크 이름을 주지 않으면 원본과 같은 이름으로 링크가 생성됩니다. 하드 링크는 원본의 변화나 삭제시 기존 데이터를 보존하는 역할을 합니다. 그것과 관련되어 조금 복잡한 사연을 가지고 있어서 디렉터리 자체는 하드 링크의 생성이 불가능합니다. 파일만 가능하지요. 하지만 심볼릭 링크는 파일이나 디렉터리 모두에 사용될 수 있습니다.

정리. 그리고 하드링크까지 한번에 삭제하기

이렇게 살펴보고 나니 링크라는 게 대단한 건줄 알았는데 별거 아니었구나 하는 생각이 듭니다. 그런데 여기서 한 가지 의문이 드는데, 만약에 어떤 파일이 하드 링크를 여러 곳에 두고 있다면 그 파일을 지운다 한들 실질적으로는 파일시스템 내에 다른 이름으로 살아남아있을 확률이 크다는 이야기입니다. 결국 특정 파일을 완전히 삭제하고 싶다면 참조하고 있는 모든 링크를 찾아보아야 한다는 이야긴데, 특정한 파일을 참조하는 하드 링크를 찾는 방법을 알아보야겠지요?

특정 파일에 대한 하드 링크를 검색하는 것은 결국 ‘똑같은 파일에 대한 다른 이름’을 찾는 것이므로 find 명령의 -samefile 옵션을 사용하면 됩니다. 예를 들면 다음과 같겠지요.

$ find /home -samefile file_that_has_many_hardlinks.mp3

그리고 이들을 한 번에 지워버리고 싶다면 다음과 같은 명령을 사용합니다.

$ find /home -samefile file_that_has_many_hardlinks.mp3 | xargs rm

(xargs는 표준입력으로 받은 항목들을 나누어 뒤에 이어지는 명령에 인수로 넘기는 역할을 한다고 합니다.)

오늘은 여기까지입니다. 이틀 연속 외박을 할 순 없으니까, 이제 집에 가야겠어요. 요즘 일교차가 유난히 큰 듯 한데, 다들 감기 조심하세요. 여러분 안녕~