윈도우에서 cURL 설치 및 사용법
참고 : http://ilhee.tistory.com/25
Linux curl 참고 : http://tyboss.tistory.com/entry/Linux-curl-%EC%82%AC%EC%9A%A9%EB%B2%95
다운로드 : https://curl.haxx.se/download.html
목록 중 Win64 - Generic 항목에서 7zip으로 되어 있는 항목을 받는다.
압축을 해제하면 하위 경로에 curl.exe 파일이 있거나 하위 디렉토리 중 bin 디렉토리를 확인하면 있다.
cmd 창에서 해당 경로로 들어간 후 curl --help 로 확인가능하다.
OS/Windows
- [Windows] 윈도우에서 curl 설치 및 사용법 2016.10.18
- [Windows] cmd 한글 깨짐 (chcp 949) 2015.02.26 2
- [Windows] Windows 2003 공유 및 보안 메뉴 안보임 문제 2014.10.06
- [Windows] 디스크가 쓰기 금지되어 있습니다 . The disk is write protected. [출처] 디스크가 쓰기 금지되어 있습니다 . The disk is write protected. 2014.09.29
- [Windows] 네트워크 드라이브 연결 2014.09.18
- [Windows] 윈도도우 부분 복구 ( FixWin ) 2014.01.14
- [Windows] 윈도우에서 링크(Link)란 무엇인가? - 하드 링크, 심볼 링크, 정션 2013.10.24
[Windows] 윈도우에서 curl 설치 및 사용법
[Windows] cmd 한글 깨짐 (chcp 949)
CMD에서 한글이 깨질 때
* 활성코드 확인
c:\>chcp
활성 코드 페이지: 949, 활성 코드 페이지: 65001 등등 표시
* 활성코드 수정
c:\>chcp 949
* chcp 949 적용 시 cmd 창을 다시 열었을 경우 활성코드가 다시 바뀌는 경우
1. regedit
2. HKEY_CURRENT_USER\Console
- CodePage 키 더블클릭 > 단위를 10진수 선택 > 949 설정
4. HKEY_CURRENT_USER\Console\%SystemRoot%_system32_cmd.exe
- CodePage 키 더블클릭 > 단위를 10진수 선택 > 949 설정
* 위 방법으로도 원래대로 돌아가는 경우 cmd를 켤 때마다 chcp 명령어 실행
1. regedit
2. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Command Processor
새로만들기 > 문자열 값
Key : AutoRun
Value : chcp 949
[Windows] Windows 2003 공유 및 보안 메뉴 안보임 문제
출처 : http://gnujava.com:8000/board/article_view.jsp?article_no=1003&board_no=14&table_cd=EPAR05&table_no=05
2003서버에 계정을 하나 만드시고, 원격에서 접속하려는 컴퓨터에서 그 계정으로 로그온 하도록 설정해야 됩니다.
방법은 시작 -> 프로그램 -> 관리도구 -> 로컬 보안 정책 을 실행합니다.
그 후, 로컬 정책 -> 보안 옵션 -> 네트워크 액세스 : 로컬 계정에 대한 공유 및 보안 탭을 선택합니다. 여기에 값을 일반 -> 로컬 사용자를 그대로 인증 으로 변경한 후, 재부팅 합니다.
위와 같이 설정 후
- 로컬 및 사용자 그룹에서 Guest계정을 사용안함으로 설정
- 새 사용자를 선택한 후, 사용자 등록
- 폴더 생성
- 공유 설정(NTFS 파일 시스템일 경우)
- 공유 탭에서 폴더 공유 지정 사용 권한에 EVERYONE 권한을 모두 줌.
- 보안탭으로 가서 2번에서 만든 계정을 등록 후, 모든 권한을 줌
- 다시 EVERYONE 을 선택한 후, 제거
- 확인을 누릅니다.
그 후, XP 홈에서 접속을 시도하면, 로그온창이 나타나게 됩니다. 그럼 좀전에 만든 계정으로 로그온을 하시면, 접속이 가능해
집니다.
서비스 항목에서 아래의 서비스들이 실행되어 있어야 합니다.
Server
Workstation
Computer Browser
위 서비스가 구동중인지 확인 바랍니다. 물론 2003서버에서 말이죠.. 이서비스들이 사용안함으로 되어 있으면, 네트워크 공유가 되지 않습니다.
그리고, 이벤트 로그를 보시고, 이벤트 ID 2011이 발생한다면, 아래 사이트를 방문하여 레지스트리를 수정합니다.
http://support.microsoft.com/default.aspx?scid=kb;ko;177078
[Windows] 디스크가 쓰기 금지되어 있습니다 . The disk is write protected. [출처] 디스크가 쓰기 금지되어 있습니다 . The disk is write protected.
참고 : http://blog.naver.com/whdals0/220107223824
1. 시작 -> cmd
2. c:\> diskpart
3. DISKPART> list disk
- 디스크 목록 확인
4. DISKPART> select disk 1
- select disk 번호 : 번호는 list disk 목록에 나온 번호
5. attributes disk clear readonly
- 읽기만 하는 속성 지움
6. exit
[Windows] 네트워크 드라이브 연결
[Windows7] 내 자격 증명 기억을 해도 네트워크 드라이브 인증을 요구할때
참고 : http://ddoong2.com/m/post/572
네트워크 드라이브를 연결해서 사용하는데 로그인 할때마다 풀리는 경우가 발생했다.
분명 '내 자격 증명 기억'을 체크 했는데
설정 방법은 Windows7 일때...
시작 -> 제어판 -> 자격증명 관리자 -> Windows 자격증명 추가
====================================================================================================================================
네트워크 드라이브 연결 지속
참고 : http://blog.naver.com/hanyu99/80110310727
http://support.microsoft.com/kb/297684/ko
windows의 버전 마다 차이기 있을 수는 있겠지만 네트워크 공유에 드라이브를 매핑하면
해당 시스템의 유휴 세션 시간이 지난면 매핑된 드라이브 연결이 끊어 질 수가 있습니다.
그로 인해 말씀하신것 처럼 매핑된 드라이브 아이콘에 붉은색 x 를 표시하게 됩니다.
하지만 다시 액세스 또는 탐색 시 붉은색 x가 없어지게 됩니다.
이런 유휴 시간이 있는 것은 지정된 유휴 시간 후 유휴 연결을 제거하여 사용되지 않는
세션에서 서버 리소스가 낭비되는 것을 줄이기 위해서 입니다.
만약 해당 연결 시간을 지속적으로 또는 그 시간을 늘리기 위해서는 하기의 명령줄을 활용하시면 되는데요.
net config server /autodisconnect:number
입니다. 여기서 number는 연결을 끊기 전에 서버가 대기하도록 할 시간이며 최대 값은 65,535입니다.
그리고 autodisconnect 값을 0(영)으로 설정하면 autodisconnect 기능은 해제되지 않으며
autodisconnect 기능을 해제하려면 아래와 같이 하시면 됩니다.
net config server /autodisconnect:-1
하기의 링크에서 자세한 사항을 보실 수 있습니다.
참고 사항
net config server는 다음과 같은 정보를 표시합니다.
--------------------------------------------------------------------
C:\>net config server
서버 이름 \\culaworld
서버 설명 테스트
소프트웨어 버전 Microsoft Windows Server 2003
서버 활성화
NetbiosSmb (000000000000)
NetBT_Tcpip_{xxxxxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxxxx} (xxxxxxxxxxxx)
서버 숨겨짐 아니오
로그온 사용자 최대 수 제한 없음
세션당 열 수 있는 파일의 최대 수 16384
유휴 세션 시간 (분) 15
명령을 잘 실행했습니다.
--------------------------------------------------------------------
Windows XP의 인바운드 연결 제한
http://support.microsoft.com/kb/314882/ko
Windows NT Workstation 3.5x 및 4.0으로의 인바운드 연결(Inbound Connection) 제한
http://support.microsoft.com/kb/122920/ko
서버 서비스 구성과 조정
http://support.microsoft.com/kb/122920/
명령줄에서 공유 폴더 관리
[Windows] 윈도도우 부분 복구 ( FixWin )
다운로드 : http://www.thewindowsclub.com/repair-fix-windows-7-vista-problems-with-fixwin-utility
WLAN AutoConfig 시작 오류
[Windows] 윈도우에서 링크(Link)란 무엇인가? - 하드 링크, 심볼 링크, 정션
출처 : http://cappleblog.co.kr/538
윈도우에서는 윈도우 2000 이후 하드 링크(Hard Link)와 정션(Junction)이 윈도우 비스타 이후 심볼 링크(Symbolic Link)라는 기존의 윈도우에서는 없었던 새로운 개념이 사용되고 있습니다. [참고로 윈도우에서만 새로웠던 겁니다. ^^;] 이러한 링크는 윈도우 탐색기와 같은 파일 관리자가 아닌 NTFS 파일 시스템(File System) 차원에서 관리되는 것으로 파일에 대한 좀 더 유연한 접근과 관리를 가능케 해줍니다. 이번 글에서는 이러한 링크에 대한 개념을 잡아보는 시간을 가지도록 하겠습니다.
일단 이 개념을 정확하게 짚고 넘어가도록 하죠. 먼저 매우 기초적인 이야기를 하나 하겠습니다. 파일은 어디에 저장되어 있나요? 바로 디스크입니다. 이렇게 디스크에 저장되어 있는 파일의 본체를 실제 파일이라고 하겠습니다. 그리고 디스크에 저장되어 있는 파일들을 관리하는 건 파일 시스템입니다.
이제 중요한데요. 먼저 생각해야 할 것은 우리가 윈도우에서 어떠한 파일을 보고 있다면, 우리는 디스크에 기록되어 있는 실제 파일을 직접 보고 있는 게 아니라, 파일 시스템에 기록된 실제 파일에 대한 정보를 보고 있다는 겁니다. 그러한 파일 시스템의 정보에는 파일에 대한 여러 가지 고유 정보(파일 이름 등등)과 함께 실제 파일이 디스크의 어디에 저장되어 있는지 찾아갈 수 있는 위치 정보가 저장되어 있습니다.
이게 바로 링크(Link)입니다. 즉, 우리는 이러한 파일 시스템의 링크를 보고 있는 것이고, 그러한 링크를 통해 실제 파일에 접근하여 사용하는 거죠. 우리는(윈도우와 프로그램은) 이러한 방식으로 파일을 읽고 사용하는 겁니다. 이를 간단하게 그림으로 표현하면 아래와 같습니다. [아래의 그림은 볼륨(드라이브)와 파일 시스템을 개념적으로 분리한 모식입니다.]
그림을 보시면 아시겠지만 C:\CApple.txt 이라는 것도 그냥 링크 정보일 뿐입니다. 즉, 어떠한 파일의 경로와 이름이란 것은 실제 파일에 기록되어 있는 파일 자체의 데이터가 아닌, 그저 파일 시스템에서 관리되는 정보일 뿐인 거죠. 과거의 윈도우에서는 이렇게 실제 파일과 파일 시스템의 링크를 무조건 1:1 로 매칭시켰습니다. 즉, 실제 파일 하나에 파일 링크 하나! 이게 기본이었습니다.
그런데 윈도우 2000 부터 아래와 같은 새로운 개념이 사용되기 시작합니다.
즉, 하나의 실제 파일에 두 개 이상의 파일 링크를 연결하여 사용하기 시작한 거죠. 예로 위 그림에서 C:\CApple.txt 라는 파일과 C:\ShinB.txt 라는 파일은 별개의 파일처럼 보이지만, 실제론 $File1 라는 동일한 실제 파일에 동시에 연결되어 있는 완전히 같은 하나의 파일입니다. 둘 중에 어떤 파일로 접근해도 $File1 이라는 실제 파일에 연결되는 것이고, 그렇기에 둘 중에 아무 파일로 접근하여 내용을 수정하여도, 다른 파일에도 동시에 수정된 내용이 적용되는 것이죠.
이렇게 하나의 실제 파일에 두 개 이상의 파일 링크가 연결되어 있는 경우, 다른 하나의 파일을 삭제(Delete) 하더라도 여전히 다른 파일을 통해 실제 파일에 접근이 가능합니다. 즉, 실제 파일에 연결된 모든 파일 링크를 삭제하기 전까진 해당 실제 파일은 삭제(Delete)되지 않는 것이죠. [하지만 실제 파일까지 지우는 Wipe 는 안 됩니다.] 고로, 단 하나의 파일이라도 남아 있다면 실제 파일에는 접근이 가능한 겁니다. 또한 하나의 파일 이름을 바꾸더라도 이것이 다른 파일에 영향을 미치지 않습니다. 간단하죠?
이것을 하드 링크(Hard Link)라고 부릅니다. 실제로 아래와 같이 하드 링크를 생성해보았습니다. 하드 링크로 만들어진 또 다른 파일은 그야말로 완전히 별개의 파일로 보입니다.
파일 속성을 살펴 봐도 둘은 각자 별개의 온전한 파일입니다.
하지만 사실 둘은 하나의 실제 파일에 연결된 같은 파일인 거죠. 간단하죠?
그런데 윈도우 비스타에서는 이러한 하드 링크 외에도 링크에 대한 링크라는 개념도 새롭게 추가가 되었습니다. 즉, 아래와 같은 겁니다.
보시는 것과 같이 C:\WinTT.txt 라는 파일(링크)는 이전과 다르게 $File1 이라는 실제 파일이 아닌 C:\ShinB.txt 파일(링크)에 연결이 되어 있습니다. 즉, 링크에 링크가 연결된 거죠. 그래서 우리가(윈도우가, 프로그램이) C:\WinTT.txt 에 접근하면 곧바로 실제 파일이 아닌 C:\ShinB.txt 라는 링크를 한 번 거쳐서 실제 파일에 접근하게 됩니다. 그래서 이러한 링크에 대한 링크는 하드 링크와는 다르게 1차적인 속성은 바로 가기가 됩니다. 하지만 파일 형식은 하드 링크처럼 지정한대로 인식이 되고, 실제 파일과 동일하게 사용이 가능하며, 데이터가 아닌 링크를 가르키고 있기 때문에 용량은 제로가 됩니다.
이것은 .lnk 파일로 구현되는 바로 가기(Shortcut) 와 비슷하면서도 다른 개념입니다. .lnk 바로 가기는 .lnk 라는 완전히 별개의 파일(해당 .lnk 의 실제 파일도 가지고 있는)이 따로 존재하고, 이러한 .lnk 포맷은 윈도우의 익스플로러 쉘에서 지정된 파일로 이동을 시켜주는 하나의 파일 형식일 뿐입니다. 하지만 지금 이야기하고 있는 링크에 대한 링크는 윈도우가 아닌 파일 시스템 차원에서 연결된 것이며, 이렇게 생성된 파일은 그 자체로 윈도우나 프로그램에서 개별적인 파일처럼 취급이 됩니다.
간단하게 C:\ShinB.txt 파일에 대한 C:\WinTT.lnk 바로 가기(Shortcut)를 만들고, 이러한 바로 가기(Shortcut)를 익스플로러에서 실행하면 C:\ShinB.txt 파일이 열립니다. 하지만 C:\ShinB.txt 에 링크로 연결된 C:\WinTT.txt 는 그대로 C:\WinTT.txt 로 열립니다. 그리고 하드 링크와 같이 최종적으로 서로 동일한 실제 파일로 연결되기 때문에 C:\ShinB.txt 나 C:\WinTT.txt 둘 중에 아무 파일로 접근하여 내용을 수정하면, 다른 파일에도 동시에 수정된 내용이 적용되는 겁니다. 간단하죠?
그런데 이러한 링크에 대한 링크는 실제 파일에 직접 연결되어 있는 게 아니기 때문에 연결한 원본 링크가 사라지면 무용지물이 되는 문제가 있습니다. 즉, 아래와 같이 C:\ShinB.txt 파일이 사라지면 연결 흐름상 실제 파일에 접근할 수 없고, 결국 C:\WinTT.txt 파일은 그냥 더미 링크가 되어 버리는 거죠. 원본 링크 파일을 지우는 것 뿐만 아니라 원본 링크 파일의 이름이 바뀌어도 마찬가지로 링크에 대한 링크는 사용할 수 없게 됩니다.
이러한 방식의 링크를 심볼 링크(Symbolic Link)라고 합니다. 다른 말로 소프트 링크(Soft Link)라고 부르기도 합니다. 실제로 아래와 같이 심볼 링크를 생성해보았습니다. 심볼 링크로 만들어진 파일은 바로 가기 속성이지만, 별개의 독립된 파일로 인식되고, 실제 파일처럼 사용할 수 있습니다.
이야기한 것처럼 심볼 링크로 생성된 파일은 속성을 열어 보면 바로 가기이지만, 파일 형식과 이름은 일반적인 파일처럼 인식되고, 그 자신은 실제 파일이 아닌 다른 링크를 가르키고 있기 때문에 크기는 0 인 것을 확인할 수 있습니다.
지금까지 두 가지 링크에 대해서 이야기를 해봤는데요. 그냥 논리적인 개념상으로 지금까지 이야기한 것들 살펴보자면, 실제 파일은 현재 디스크에 존재하는 거죠. 그래서 실제로 존재하기에 딱딱하다고 봅니다. 하지만 링크는 이에 대한 무형의 정보라고 할 수 있죠. 그래서 부드러운 걸로 봅니다. 즉, 우리가 컴퓨터에서 하드웨어/소프트웨어로 나누듯이, 여기에서도 실제 파일은 하드웨어로, 링크는 소프트웨어로 나눌 수 있는 거죠. [그냥 서로를 개념적으로 따져본다면]
그래서 실제 파일과 직접 연결된 링크를 하드 링크(Hard Link)라고 부르며, 링크에 연결된 링크는 소프트 링크(Soft Link)라고 표현합니다. 그리고 소프트 링크의 정확한 명칭은 심볼 링크(Symbolic Link)이고요. [소프트 링크 = 심볼 링크] 아무튼, 최종적으로 지금까지 이야기한 것을 정리하면 아래와 같습니다.
이것이 바로 윈도우에서 이야기하는 하드 링크와 심볼 링크의 정체입니다. 별거 아니죠? 아래는 지금까지 알아 본 하드 링크와 심볼 링크로 연결된 여러 파일들의 연결을 나타내 본 것입니다.
위의 그림을 보면서 추가로 더 이야기하자면 하드 링크는 실제 파일에 직접 연결해야 하기 때문에 실제 파일이 위치한 동일 드라이브에서만 가능하며, 심볼 링크는 대상만 설정하면 되는 일종의 바로 가기인 연결이기 때문에 동일 드라이브는 물론 다른 드라이브로도 연결이 가능합 니다. 이것은 하드 링크가 가질 수 없는 심볼 링크만의 장점이죠. 실제 사용하면서 느낄 수 있는 하드 링크와 심볼 링크의 가장 큰 차이는 바로 여기에 있다고 할 수도 있겠네요. 또한 심볼 링크는 절대 경로는 물론 상대 경로로도 원본 대상을 지정할 수 있다는 사용할 수 있는 특징이 있습니다.
좀 더 이야기하자면 하나의 실제 파일에 여러 개의 하드 링크 연결이 가능한 것처럼, 하나의 하드 링크에 여러 개의 심볼 링크를 연결하는 것도 가능하며, 마찬가지로 하나의 심볼 링크에 여러 개의 심볼 링크를 연결하는 것도 가능합니다. 그리고 심볼 링크에 연결된 심볼 링크에 다시 심볼 링크를 연결하는 것처럼 다단계로 연결하는 것도 가능합니다. 물론 여러 단계에 걸친 모든 연결이 그러하듯 중간에 하나가 끊기면 그 뒤에 링크들은 더미가 되겠죠.
여기까지가 파일에 대한 하드 링크와 심볼(소프트) 링크에 대한 설명이었습니다. 다음은 폴더(디렉토리)로 넘어가보죠.
일단 폴더는 파일이 아닙니다. 폴더는 파일과 같이 실제로 존재하는 어떠한 데이터 개체가 아닌, 파일 시스템에서 구현된 일종의 논리적인 구조(구역, 공간)이라고 보시면 됩니다. 즉, 파일은 데이터로 하나의 물리적인 개체이지만, 폴더는 파일 시스템에서 설정된 논리적인 어떠한 공간 그 자체인 거죠. [개념을 놓고 보자면] 그래서 폴더에서는 하드 링크라는 개념이 없습니다. [일부는 정션을 하드 링크로 보던데, 이것은 제가 이해를 잘못한 건지 모르겠지만 '정션을 하드 링크로 볼 수 있나?' 라는 생각이 드네요.]
일단 폴더에서는 애초에 윈도우 비스타 이전 즉, 윈도우 XP 시절에도 정션(Junction)이라는 개념이 사용되고 있었습니다. 그리고 이러한 정션은 계속 이어져서 현재에도 사용되고 있죠. 정션이 가지고 있는 특성이나 개념은 심볼 링크와 크게 다르지 않습니다. 그리고 윈도우 비스타에 이르러서 지금까지 이야기한 심볼 링크(Symbolic Link)라는 개념이 추가 되었습니다. 이러한 폴더에 대한 심볼 링크의 특성은 파일에서의 심볼 링크의 특성과 동일합니다.
사실 정션과 심볼 링크를 구별 짓기란 게 참 애매할 정도로 실 사용에서의 정션과 심볼 링크의 특성은 매우 비슷합니다. 둘의 차이점이라면 심볼 링크는 상대 경로의 사용이 가능하며, 정션은 상대 경로는 지정할 수 없다는 것, 심볼 링크는 네트워크 드라이브로의 링크가 가능하며, 정션은 불가능하다는 점이 다른 것을 들 수 있습니다. 이 외에 실제로 사용하면서 느낄 수 있는 사실상의 특성은 동일하다고 보면 되며, 이러한 점을 미루어 봤을 때 정션을 폴더에 대한 구형 소프트 링크로 보고, 심볼 링크를 폴더에 대한 신형 소프트 링크로 보는 것이 좋을 듯합니다.
폴더에 대한 심볼 링크와 정션을 비교하자면 심볼 링크는 파일과 마찬가지로 1차적으로 바로 가기의 속성을 가지고 폴더로 인식 되며, 상대 경로의 사용이 가능하고, 다른 드라이브로 특히나 네트워크 드라이브로도 링크가 가능하다는 특징이 있습니다. 반면 정션은 폴더의 속성을 가지고 폴더로 인식이 되며, [이 부분은 파일의 하드 링크와 같죠. 하지만 아이콘은 또 바로 가기라는 것...] 절대 경로만 사용이 가능하며, 다른 드라이브로의 연결은 가능하지만, 대신 네트워크 드라이브로의 연결은 불가능하다는 차이가 있습니다. 그 외의 둘 모두 원본 폴더가 사라지면 더미 링크가 되는 것과 같은 특성들은 동일합니다.
아래는 실제로 하나의 폴더에 각각 정션 폴더와 심볼 링크 폴더를 생성해본 모습입니다. 일단 두 폴더 모두 윈도우 탐색기 상에서는 아이콘이 바로 가기로 표시됩니다.
하지만 해당 폴더로 들어가보면 일반적인 폴더와 마찬가지로 경로가 그대로 인식이 되는 것을 확인할 수 있으며, 원본 폴더의 파일이 둘 모두 정상적으로 연결되어 출력되는 것을 확인할 수 있습니다.
속성을 살펴 보면 위에서 이야기한 것과 같이 정션 폴더는 폴더로, 심볼 링크 폴더는 속성은 바로 가기로 인식되었음을 알 수 있습니다.
참고로 윈도우에선 예전부터의 호환성을 위한 것인지 윈도우 내부적으로는 심볼 링크보다는 정션을 주로 사용하는 모습을 보여 주고 있습니다. 폴더에선 이 외에 딱히 더 이야기할 것은 없네요.
간단합니다. 어떠한 서로 다른 경로에 위치한 파일이나 폴더를 동일하게 유지하기 위해서입니다. 즉, C:\Test\A.txt 라는 파일과 C:\Temp\B.txt 라는 파일의 내용이 완전히 실시간으로 동일해야만 하는 경우가 있을 수 있는 거죠. 또는 어차피 같은 의미이지만 하나의 대상에 대한 두 개의 전혀 다른 접근 경로가 필요할 때도 있습니다. 즉, 어느 경로로 접속하나 같은 파일이 필요하다는 거죠. 그래서 파일에 대한 동일성을 유지시키려면 하드 링크나 심볼 링크를, 폴더에 대한 동일성을 유지시키려면 정션 폴더나 심볼 링크 폴더를 사용하게 됩니다.
아주 간단하게 실제 예를 들어보자면 윈도우 XP 시절까지 사용자 폴더의 위치는 C:\Documents and Settings\사용자 계정 폴더였습니다. 하지만 윈도우 비스타부터는 C:\Users\사용자 계정 폴더로 그 위치가 바뀌었죠. 하지만 윈도우 XP 시절에 만들어진 프로그램들은 이렇게 새롭게 바뀐 사용자 폴더 경로를 알지 못하기에, 무조건 기존의 C:\Documents... 를 사용하려는 프로그램들이 많았습니다. 이 문제를 어떻게 해결 할까요?
방법은 간단합니다. C:\Users\사용자 계정 폴더를 원본으로 해서 C:\Documents and Settings\사용자 계정 경로로 정션 폴더나 심볼 링크 폴더를 생성하면 되는 겁니다. 그렇게 되면 기존의 프로그램들은 자신들이 사용하던대로 C:\Documents... 경로로 접근할 수 있고, 그렇게 해당 정션 폴더로 접근하면 자동으로 C:\Users... 폴더의 내용과 연결이 되는 거죠. 즉, 정션 폴더(심볼 링크 폴더)를 통해 두 개의 서로 다른 경로를 하나의 원본 폴더로 동시에 처리할 수 있는 겁니다.
이렇게 정션 폴더나 심볼 링크로 연결된 상태에서는 둘 중에 어느 경로로 접근하든 동일한 내용을 볼 수 있고, 둘 중에 어느 경로에 파일을 저장하든 두 경로 모두에서 동시에 사용할 수 있으니까요. [실제 파일은 원본에 저장되지만 연결되어 있기 때문에 변화는 동시에 적용됨] 간단하죠?
여기에 더해 더 이야기하자면 정션 폴더나 심볼 링크의 특성을 이용해 어떠한 드라이브의 특정 폴더를 통채로 다른 드라이브로 옮길 수도 있습니다. 즉, 나는 C:\Temp 라는 폴더를 사용하지만 이 폴더에 저장되는 파일들은 C: 드라이브가 아닌 용량이 좀 더 큰 D: 드라이브에 저장이 되길 원할 수도 있습니다. 그럴 땐 D: 드라이브에 원본 폴더를 하나 생성한 후 이 원본 폴더에 연결된 정션 폴더나 심볼 링크 폴더를 C: 드라이브에 생성하고, 해당 폴더를 사용하는 겁니다. 그럼 자연적으로 해당 폴더에 저장한 파일들은 D: 로 저장되는 거죠.
또한 하드 링크를 사용하면 여러곳에서 동시에 사용되는 완전히 동일한 파일들을 하나로 합쳐서 관리할 수도 있기 때문에 그만큼 디스크에서의 전체 파일 용량을 줄일 수 있는 이점도 있습니다. 쉽게 이야기하면 하드 링크를 통해 중복 파일을 하나로 통합할 수 있는 거죠. 뭐 그렇습니다. 어떻게 이번 내용이 도움이 되셨는지 모르겠네요. 윈도우에서 링크 기능에 대해서는 이정도면 될 듯 하네요. 사실 오늘 적으려고 했던 글은 아닌데 어쩌다 이 글이 나왔는지 모르겠네요. ^^;;; 이상입니다.
★ mklink 를 통해 윈도우에서 링크를 만드는 방법, 심볼 링크와 정션을 만들 때 주의해야 할 점