User Agent 확인 : http://whatsmyuseragent.com/
                          http://chrispederick.com/work/user-agent-switcher/features/test/


* Firefox

1. user agent switcher plugin 설치한다.
    https://addons.mozilla.org/ko/firefox/addon/user-agent-switcher


2. 아래 다운로드 경로에서 User Agent List (XML) 다운로드한다.

    참고 : http://forums.chrispederick.com/discussion/7/a-large-regularly-updated-import-list-of-user-agents
    다운로드 : http://techpatterns.com/forums/about304.html


3. 도구 - Default User Agent - Edit User Agents 클릭하여 다운로드 받은 User Agent List 파일을 Import 시킨다.   

useragentswitcher.xml


4. 도구 - Default User Agent 에서 User Agent를 변경한다.




* Chrome

1. F12 클릭 (개발자 도구) 후 우측 하단 톱니바퀴 아이콘을 클릭한다.

2. Overrides 탭을 클릭하면 User Agent를 변경할 수 있다.


- 확장기능 설치

1. 확장기능을 설치한다.
    https://chrome.google.com/webstore/detail/user-agent-switcher-for-c/djflhoibgkdhkhhcedjiklpkjnoahfmg


2. 우측 상단 아이콘 중 Chrome UA Spoofer 를 클릭하여 User Agent를 변경한다.

출처 : https://developers.google.com/chrome-developer-tools/docs/remote-debugging
         http://devday.tistory.com/3059
         http://zerq.tistory.com/126



1. 모바일 기기에 크롬을 설치한다.
    버전이 31인 경우 PC에서 화면을 볼 수 없고 (개발자도구 디버깅만 가능) 현재 32 베타 버전을 설치하면 모바일 화면을 PC에서 볼 수 있다.


2. 핸드폰 USB 드라이버를 PC에 설치한다.


3. PC에 크롬을 설치한다.
   버전이 31인 경우 아래 경로에 접근하여 사용으로 변경
   about:flags/#enable-devtools-experiments
   about:flags/#remote-debugging-raw-usb


4.1 크롬 확장 (ADB) 설치
    
https://chrome.google.com/webstore/detail/adb/dpngiggdglpdnjdoaefidgiigpemgage

4.2 ADB를 설치한 경우 아래 명령어를 cmd에서 실행하고 http://localhost:9222 로 접근하면 된다.
    adb forward tcp:9222 localabstract:chrome_devtools_remote

5. PC 크롬 버전이 31인 경우 아래 경로로 접근한다.
    about:inspect

    PC 크롬 버전이 32 이상인 경우 아래 메뉴로 접근한다.
    
Tools -> Inspect Devices


1. 첫 페이지 호출 시 실행 순서

pagebeforechange

pagebeforechange

pagebeforecreate

pagecreate

pagebeforeshow

pageshow

pagechange 



2. 다른 페이지 Link 시 다음 페이지 실행 순서

pagebeforechange

pagecontainerbeforeload

pagebeforecreate

pagecreate

pagebeforechange

pagebeforehide

pagebeforeshow

pagechange

pageshow  


3. 다른 페이지 Link 시 처음 페이지 실행 순서

pagebeforechange

pagebeforechange

pagebeforehide

pagebeforeshow

pagechange

pageremove

pageshow 



4. 같은 페이지 Link 시 같은 페이지 실행 순서

pagebeforechange

pagebeforecreate

pagecreate

pagebeforechange

pagebeforehide

pagebeforeshow

pageshow

pagechange  


5. 같은 페이지 Link 시 두 번 이상 실행 시 실행 순서

pagebeforechange

pagebeforechange

pagebeforehide

pagebeforeshow

pageshow

pagechange


참고 : http://apexsoftdevartment.blogspot.kr/2013/02/consolas.html
         http://bestmin.tistory.com/437

cour.ttf

courbd.ttf

courbi.ttf

couri.ttf



1. regedit 를 실행한다.

2. 아래 경로의 Courier New Key값을 찾아 수정한다.
HKEY_LOCAL_MACHINE > SOFTWARE > Microsoft > Windows NT > CurrentVersion > FontLink > SystemLink


3. 수정 값 
추가 > 다중 문자열 값
key : 
Courier New

MSMINCHO.TTC,MS Mincho
BATANG.TTC,BatangChe
MINGLIU.TTC,MingLiU
SIMSUN.TTC,SimSun
GULIM.TTC, GulimChe
DOTUMCHE.TTC,Dotum
GULIM.TTC,Gulim



---------------------------------------------------------------------------------------------------

Courier New 폰트가 설치되어 있는데 Editor 설정에서 Courier New 폰트가 보이지 않을 때

C:\Windows\Fonts 에 Courier New 폰트를 찾아서 마우스 우클릭 후 표시를 눌러준다.

Courier New 폰트가 숨김으로 되어 있어서 나오지 않음.

출처 : http://stackoverflow.com/questions/1150163/stretch-and-scale-a-css-image-in-the-background-with-css-only


 html {
    background: url(images/homeBg.jpg) no-repeat center center fixed;
    webkit-background-size: cover;
    moz-background-size: cover;
    o-background-size: cover;
    background-size: cover;
    filter: progid:DXImageTransform.Microsoft.AlphaImageLoader(src='images/homeBg.jpg',     sizingMethod='scale');
    -ms-filter: progid:DXImageTransform.Microsoft.AlphaImageLoader(src='images/homeBg', sizingMethod='scale');
}



출처 : http://blog.nekrs.com/195


Tomcat 서버에서 로그인 페이지처럼 특정 페이지는 HTTPS를 이용하고, 나머지 페이지는 HTTP를 사용하려고 한다. 이때 HTTPS->HTTP로 이동하면서 세션은 공유되지 않는 문제가 있다. 다음은 이 문제를 해결하는 방법 중 하나이다.

RequestWrapper 클래스를 하나 만듭니다. 이 클래스는 HTTPS 요청일 경우 쿠키에 세션 정보를 조작하는 역할을 합니다.

 public class HttpsRequestWrapper extends HttpServletRequestWrapper{
 private HttpServletResponse response = null;
 public HttpsRequestWrapper (HttpServletRequest request) {
  super(request);
 }
 public void setResponse (HttpServletResponse response) {
  this.response = response;
 }
 public HttpSession getSession () {
  HttpSession session = super.getSession();
  processSessionCookie(session);
  return session;
 }
 public HttpSession getSession (boolean create) {
  HttpSession session = super.getSession(create);
  processSessionCookie(session);
  return session;
 }
 private void processSessionCookie (HttpSession session) {
  if (null == response || null == session)  return;

  Object cookieOverWritten = getAttribute("COOKIE_OVERWRITTEN_FLAG");
  if (null == cookieOverWritten && isSecure() && isRequestedSessionIdFromCookie() && session.isNew())  {
   Cookie cookie = new Cookie("JSESSIONID", session.getId());
   cookie.setMaxAge(-1);
   String contextPath = getContextPath();
   if ((contextPath != null) && (contextPath.length() > 0))   {
    cookie.setPath(contextPath);
   }   else   {
    cookie.setPath("/");
   }  
   response.addCookie(cookie);
   setAttribute("COOKIE_OVERWRITTEN_FLAG", "true");
  }
 }
}

그리고 Filter 클래스를 만듭니다. 이 필터는 기본 Request를 HttpsRequestWrapper로 변경하는 역할을 합니다. 그리고 이 필터는 다른 필터보다 우선 실행되어야 합니다.

public class HttpsFilter implements Filter{
 public void doFilter (ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
   HttpsRequestWrapper httpsRequest = new HttpsRequestWrapper((HttpServletRequest)request);
   httpsRequest.setResponse((HttpServletResponse)response);
   chain.doFilter(httpsRequest, response);
 }




 

출처 : http://blog.naver.com/innerlog?Redirect=Log&logNo=40184670892

참고 : https://www.lesstif.com/pages/viewpage.action?pageId=12451848

javax.net.ssl.SSLHandshakeException의 경우 통상적으로 유효한 SSL인증서가 없을때 발생한다.

내 경우에는 Spring 3.0에서 SimpleEmail을 이용한 메일발송시에 발생했는데

smtp.naver.com:465 를 사용하였는데 아무리 검색을 해봐도 인증서를 만들어야 된다던가 하는 답 뿐이었다.

방화벽 문제일 수 있다고 해서 확인해봤더니 방화벽은 꺼놓은 상태이고...

 

알고보니 바이러스 백신이 구동되고 있어서였다. 

 

아래 첨부파일은 jre에 유효하지 않은 인증서 등록하는 Class

InstallCert.java

 InstallcertJava.java

 

출처 : http://cappleblog.co.kr/538

우리가 윈도우에서 보는 모든 파일은 파일 시스템의 링크(Link)이다.

Link : 명사 연결 동사 연결하다

윈도우에서는 윈도우 2000 이후 하드 링크(Hard Link)정션(Junction)이 윈도우 비스타 이후 심볼 링크(Symbolic Link)라는 기존의 윈도우에서는 없었던 새로운 개념이 사용되고 있습니다. [참고로 윈도우에서만 새로웠던 겁니다. ^^;] 이러한 링크는 윈도우 탐색기와 같은 파일 관리자가 아닌 NTFS 파일 시스템(File System) 차원에서 관리되는 것으로 파일에 대한 좀 더 유연한 접근과 관리를 가능케 해줍니다. 이번 글에서는 이러한 링크에 대한 개념을 잡아보는 시간을 가지도록 하겠습니다.


"우리가 윈도우에서 보는 모든 파일은 실제 파일에 대한 파일 시스템의 링크(Link)이다."


일단 이 개념을 정확하게 짚고 넘어가도록 하죠. 먼저 매우 기초적인 이야기를 하나 하겠습니다. 파일은 어디에 저장되어 있나요? 바로 디스크입니다. 이렇게 디스크에 저장되어 있는 파일의 본체를 실제 파일이라고 하겠습니다. 그리고 디스크에 저장되어 있는 파일들을 관리하는 건 파일 시스템입니다.

이제 중요한데요. 먼저 생각해야 할 것은 우리가 윈도우에서 어떠한 파일을 보고 있다면, 우리는 디스크에 기록되어 있는 실제 파일을 직접 보고 있는 게 아니라, 파일 시스템에 기록된 실제 파일에 대한 정보를 보고 있다는 겁니다. 그러한 파일 시스템의 정보에는 파일에 대한 여러 가지 고유 정보(파일 이름 등등)과 함께 실제 파일이 디스크의 어디에 저장되어 있는지 찾아갈 수 있는 위치 정보가 저장되어 있습니다.

이게 바로 링크(Link)입니다. 즉, 우리는 이러한 파일 시스템의 링크를 보고 있는 것이고, 그러한 링크를 통해 실제 파일에 접근하여 사용하는 거죠. 우리는(윈도우와 프로그램은) 이러한 방식으로 파일을 읽고 사용하는 겁니다. 이를 간단하게 그림으로 표현하면 아래와 같습니다. [아래의 그림은 볼륨(드라이브)와 파일 시스템을 개념적으로 분리한 모식입니다.]



그림을 보시면 아시겠지만 C:\CApple.txt 이라는 것도 그냥 링크 정보일 뿐입니다. 즉, 어떠한 파일의 경로와 이름이란 것은 실제 파일에 기록되어 있는 파일 자체의 데이터가 아닌, 그저 파일 시스템에서 관리되는 정보일 뿐인 거죠. 과거의 윈도우에서는 이렇게 실제 파일과 파일 시스템의 링크를 무조건 1:1 로 매칭시켰습니다. 즉, 실제 파일 하나에 파일 링크 하나! 이게 기본이었습니다.






하드 링크(Hard Link)와 심볼 링크(Symbolic Link)

그런데 윈도우 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)이고요. [소프트 링크 = 심볼 링크] 아무튼, 최종적으로 지금까지 이야기한 것을 정리하면 아래와 같습니다.




이것이 바로 윈도우에서 이야기하는 하드 링크와 심볼 링크의 정체입니다. 별거 아니죠? 아래는 지금까지 알아 본 하드 링크와 심볼 링크로 연결된 여러 파일들의 연결을 나타내 본 것입니다.



위의 그림을 보면서 추가로 더 이야기하자면 하드 링크는 실제 파일에 직접 연결해야 하기 때문에 실제 파일이 위치한 동일 드라이브에서만 가능하며, 심볼 링크는 대상만 설정하면 되는 일종의 바로 가기인 연결이기 때문에 동일 드라이브는 물론 다른 드라이브로도 연결이 가능합 니다. 이것은 하드 링크가 가질 수 없는 심볼 링크만의 장점이죠. 실제 사용하면서 느낄 수 있는 하드 링크와 심볼 링크의 가장 큰 차이는 바로 여기에 있다고 할 수도 있겠네요. 또한 심볼 링크는 절대 경로는 물론 상대 경로로도 원본 대상을 지정할 수 있다는 사용할 수 있는 특징이 있습니다.

좀 더 이야기하자면 하나의 실제 파일에 여러 개의 하드 링크 연결이 가능한 것처럼, 하나의 하드 링크에 여러 개의 심볼 링크를 연결하는 것도 가능하며, 마찬가지로 하나의 심볼 링크에 여러 개의 심볼 링크를 연결하는 것도 가능합니다. 그리고 심볼 링크에 연결된 심볼 링크에 다시 심볼 링크를 연결하는 것처럼 다단계로 연결하는 것도 가능합니다. 물론 여러 단계에 걸친 모든 연결이 그러하듯 중간에 하나가 끊기면 그 뒤에 링크들은 더미가 되겠죠.

여기까지가 파일에 대한 하드 링크와 심볼(소프트) 링크에 대한 설명이었습니다. 다음은 폴더(디렉토리)로 넘어가보죠.






폴더에 대한 심볼 링크(Symbolic Link)와 정션(Junction)

일단 폴더는 파일이 아닙니다. 폴더는 파일과 같이 실제로 존재하는 어떠한 데이터 개체가 아닌, 파일 시스템에서 구현된 일종의 논리적인 구조(구역, 공간)이라고 보시면 됩니다. 즉, 파일은 데이터로 하나의 물리적인 개체이지만, 폴더는 파일 시스템에서 설정된 논리적인 어떠한 공간 그 자체인 거죠. [개념을 놓고 보자면] 그래서 폴더에서는 하드 링크라는 개념이 없습니다. [일부는 정션을 하드 링크로 보던데, 이것은 제가 이해를 잘못한 건지 모르겠지만 '정션을 하드 링크로 볼 수 있나?' 라는 생각이 드네요.]

일단 폴더에서는 애초에 윈도우 비스타 이전 즉, 윈도우 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: 로 저장되는 거죠.


또한 하드 링크를 사용하면 여러곳에서 동시에 사용되는 완전히 동일한 파일들을 하나로 합쳐서 관리할 수도 있기 때문에 그만큼 디스크에서의 전체 파일 용량을 줄일 수 있는 이점도 있습니다. 쉽게 이야기하면 하드 링크를 통해 중복 파일을 하나로 통합할 수 있는 거죠. 뭐 그렇습니다. 어떻게 이번 내용이 도움이 되셨는지 모르겠네요. 윈도우에서 링크 기능에 대해서는 이정도면 될 듯 하네요. 사실 오늘 적으려고 했던 글은 아닌데 어쩌다 이 글이 나왔는지 모르겠네요. ^^;;; 이상입니다.




윈도우7 64bit ODBC를 사용하면서 32bit 응용프로그램에서 ODBC를 사용할 경우

"지정된 DSN은 드라이버와 응용프로그램 간 아키텍처 불일치를 포함합니다"

라는 오류 메시지를 발견하게 된다.

 

처리 방법
1. ODBC 32bit용을 설치한다.
2. C:\Windows\SysWOW64\odbcad32.exe를 실행한 후 ODBC 관리자에서 등록한다.

출처 : http://blog.daum.net/jeromek/20

using System; using System.Net; using System.Collections; using System.IO; namespace XPost { public class HTTPClient { string url; public enum Method { POST, GET }; private bool requestExecuted = false; private Method method = Method.POST; private System.Net.HttpStatusCode retstatus; private string cookies = null; private string referer = null; private string ua = null; private WebResponse response; private ArrayList nameValuePairs = new ArrayList(); public void setMethod(HTTPClient.Method m) { this.method = m; } public HTTPClient(string url) { this.url = url; } public void executeRequest() { if(this.requestExecuted) { return; } WebRequest wr = null; if(Method.POST == this.method) { wr = WebRequest.Create(this.url); wr.Method = "POST"; ((System.Net.HttpWebRequest)wr).ContentType = "application/x-www-form-urlencoded"; } else { bool fst = true; string turl = this.url + "?"; foreach(string[] pair in nameValuePairs) { if(!fst) { turl = turl + "&"; } else { fst = false; } turl = turl + pair[0] + "=" + pair[1]; } wr = WebRequest.Create(turl); } if(this.cookies != null && !this.cookies.Equals("")) { wr.Headers.Set("Cookie", this.cookies); } if(this.referer != null && !this.referer.Equals("") && wr is System.Net.HttpWebRequest) { ((HttpWebRequest)wr).Referer = this.referer; } if(this.ua != null && !this.ua.Equals("")) { wr.Headers.Set("User-Agent", this.ua); } System.IO.StreamWriter sw = new System.IO.StreamWriter( wr.GetRequestStream()); bool first = true; foreach(string[] pair in nameValuePairs) { if(!first) { sw.Write("&"); } else { first = false; } sw.Write(pair[0] + "=" + pair[1]); } sw.Close(); WebResponse resp = wr.GetResponse(); this.response = resp; this.retstatus = ((System.Net.HttpWebResponse) this.response).StatusCode; this.requestExecuted = true; } public void WriteResponseToConsole() { if(this.response != null) { Console.WriteLine((new StreamReader(this.response.GetResponseStream())).ReadToEnd()); } } public void setReferer(string r) { this.referer = r; } public System.Net.HttpStatusCode getResponseCode() { return this.retstatus; } public string getReturnedCookies() { if(!this.requestExecuted) { return null; } return this.response.Headers.Get("Cookie"); } public void setNewCookies(string s) { this.cookies = s; } public void addNameValuePair(string name, string val) { string[] pair = { System.Web.HttpUtility.UrlEncode( name), System.Web.HttpUtility.UrlEncode( val)}; this.nameValuePairs.Add(pair); } } } 


 

+ Recent posts