WHiSTLE's Restyling

Vista에서 사용자 폴더에 등록된 폴더 중 문서, 다운로드, 음악, 비디오 등 기본적으로 제공하는 폴더외의 내가 정한 폴더를 등록하고 싶은 경우가 있습니다.
이때 사용자 폴더 내에 새로운 폴더를 하나 만들어서 사용하면 되지만, 문서나 기타 다른 폴더들의 위치도 다른 드라이브로 옮겨서 사용하는데, 폴더내에 새로운 폴더를 생성한다는 꺼름직하죠.

그때 사용할 수 있는 것이 링크폴더를 만드는 것인데요.
Vista에서는 mklink라는 명령어를 제공하여 심볼릭 링크를 생성할 수 있도록 해줍니다.

mklink의 사용법입니다.

저는 D:\Projects라는 폴더를 사용자 폴더(C:\Users\Hwikyeom)내에 프로젝트라는 이름으로 링크폴더를 만들려고 합니다. 
이때 링크폴더는 사용자 폴더내에 동일한 이름의 폴더가 존재하지 않아야 합니다.
만일 이미 C:\Users\Hwikyeom\프로젝트 라는  폴더가 만들어져 있다면 "파일이 이미 있으므로 만들 수 없습니다." 라는 메시지가 나옵니다.

"기호화된 링크가 만들어 졌습니다."라는 메시지가 나왔다면, 링크폴더가 정상적으로 만들어 졌습니다.
탐색기에서 확인을 해보면

결과를 보면 탐색기의 트리뷰에서 프로젝트라는 폴더를 확인 할 수 있습니다.
그리고, 해당 폴더를 선택하면 위의 주소표시줄과 같이 D:\Project로 표시되는 것이 아니라 사용자폴더내의 프로젝트로 표시가 됨을 보실 수 있습니다.
하지만, 실제 내용은 D:\Projects 폴더의 내용을 표시하는 것이죠.

그렇다면, 폴더바로가기를 생성하였을 때와는 어떻게 다를까요?

폴더 바로가기는 LNK라는 파일을 생성하여 실행시 지정된 폴더로 이동시켜 주는 것입니다.
즉, 바로가기는 파일이므로 옆의 링크폴더와는 달리 트리뷰에 출력될 수 없습니다.
그리고, 바로가기를 실행했을 때는 주소 표시줄이

와 같이 지정된 폴더가 출력됩니다.

mklink는 폴더 뿐만이 아니라 파일에 대한 심볼릭링크의 생성도 가능하며, 옵션에 따라 하드링크나 또는 디렉터리 교차점의 생성도 가능합니다.

Vista 이전 버전에서는 linkd.exe를 이용하는 방법으로 링크폴더의 생성이 가능합니다. 이 방법에 대한 자세한 내용은 http://qaos.com/article.php?sid=2638 를 참고하세요.

그리고, 파일기반 심볼 링크에 대한 부분을 찾아서 참조합니다.

파일 기반 심볼 링크

Windows Vista의 I/O 관련 변경 사항으로는 파일 기반 심볼 링크, 보다 효율적인 I/O 완료 처리, 포괄적인 I/O 취소 지원, 우선 순위가 부여된 I/O 등이 있습니다.

많 은 사용자들이 NTFS에서 누락되었다고 생각하는 파일 시스템 기능인 심볼 파일 링크(UNIX에서는 소프트 링크라고 함)가 마침내 Windows Vista에 포함되었습니다. Windows 2000 버전의 NTFS에서는 다른 디렉터리를 가리키는 디렉터리를 만들 수 있게 해 주는 디렉터리 교차점이라는 심볼 디렉터리 링크가 사용되었지만 Windows Vista 이전 버전의 NTFS에서는 파일의 하드 링크만 지원했습니다.

Windows 에서 심볼 링크와 디렉터리 교차점을 해결하는 방식의 가장 큰 차이점은 처리가 발생하는 위치입니다. Windows에서 심볼 링크는 원격 파일 서버에 있는 위치를 참조할 때조차 로컬 시스템에서 처리됩니다. Windows에서는 원격 파일 서버를 참조하는 디렉터리 교차점을 해당 서버 내에서 처리합니다. 따라서 서버에 있는 심볼 링크는 다른 클라이언트 볼륨과 같이 클라이언트에서만 액세스할 수 있는 위치를 참조할 수 있지만 디렉터리 교차점은 참조할 수 없습니다. 이 문제를 해결하기 위해 Windows Vista에서는 파일과 디렉터리 모두에 대해 새로운 심볼 링크 유형을 지원합니다.

심 볼 링크에 내포된 의미를 이해할 수 있도록 다양한 파일 시스템 명령이 업데이트되었습니다. 예를 들어 Delete 명령은 링크를 따르는 대신 링크를 삭제하도록 업데이트되었습니다(링크를 따르면 대상이 삭제됨). 그러나 일부 응용 프로그램에서는 심볼 링크를 올바르게 처리할 수 없으므로 심볼 링크를 만들려면 기본적으로 관리자에게만 부여되는 새로운 심볼 링크 만들기 권한이 있어야 합니다.

Mklink 명령으로 명령 프롬프트에서 심볼 링크를 만들 수 있습니다. 명령 프롬프트에서 기본으로 제공하는 디렉터리 명령은 <SYMLINK>로 플래그를 지정하고 대상을 괄호 안에 표시하여 심볼 링크를 식별합니다(그림 5 참조). 심볼 링크는 Windows 탐색기에서도 확인할 수 있으며 바로 가기 화살표로 표시됩니다. 찾기 창에 링크 대상 열을 추가하여 탐색기에서 링크의 대상을 볼 수 있습니다.

원본경로 : http://technet.microsoft.com/ko-kr/magazine/cc162494.aspx

스마트플레이스 에 네이버에서 다음의 소스코드를 베꼈다는 취지의 포스트 "네이버가 다음의 소스코드를 무단복제한 것으로 의심됩니다" 가 올라와 화제가 되고 있습니다.

저도 웹개발자로서(지금은 윈도우 개발로 외도를 잠시하고 있습니다만) 글을 보면서 걸리는 구석이 없지 않더군요..

WEB개발의 특정상 서버에서 퍼플리싱된 클라이언트 스크립트 코드와 HTML코드등은 클라이언트 컴퓨터로 저장되어 출력되는 형태이기 때문에 언제든지 그 소스의 확인이 가능하죠.. 그래서 언제든지 남이 짜놓은 클라이언트단 스크립트 코드를 보는 것은 그다지 어려운 일이 아닙니다.
그 점 때문에 많은 개발자들이 기능에 대한 참조 또는 학습의 대상 등으로 많이 이용되고 있는 것도 사실이구요.
저 또한 업무상 필요로 해서 또는 새로운 기능에 대한 호기심등으로 타 사이트에서 구현해놓은 클라이언트단 코드를 참조하는 경우가 자주 있습니다.

프로그래머라는 직업이 최선의 구현을 위해서 연구하는 학자와는 달리 빠른 시간내에 해당 기능을 얼마나 높은 수준으로 구현해내느냐가 능력을 판가름하는 잣대로 이용되기 때문에 남의 코드를 참고하여 자기만의 코드로 승화해내는 것또한 프로그래머로서의 능력이 될 수 있습니다.

사실, 누구든 프로그래밍에 업을 두고 있는 사람이라면, 모든것을 자신이 필요한 모든 기능을 스스로 생각해서 자신이 직접 구현하는 것은 현실적으로 힘들죠. 학습을 위한 연습이라면 몰라도, 높은 수준의 완성도가 필요하고, 빠른 시일내에 개발을 완료해야만 하는 현업에서는 남이 작성해 놓은 코드에서 노하우를 습득하고, 자신의 것으로 받아들여 더욱더 향상시키는 것이야 말로, 개인의 능력향상 뿐아니라 전체적인 업계의 발전에도 기여를 한다고 생각합니다.

이번 문제는 그 대상이 우리나라 웹환경의 쌍두마차라고 할 수 있는 네이버나 다음이기 때문에 이렇게 큰 반향을 일으키고 있는 것이겠죠?

네이밍부터 주석부분까지 동일하여 copy&paste 수준이기 때문에 누군가가 가져다 그대로 사용한 것 또한 사실인듯하고요. 촉박한 개발일정에 쫓겨 자기것으로 소화하는 과정을 생략한 부분이 생길수 있다는 것도 사실 같은 개발자로서 이해하지 못하는 것도 아닙니다.

또한, 인터넷상에는 이러한 copy&paste 코드가 무궁무진하게 널려있을 것이며, 많은 개발자가 그다지 자유롭지는 못할 듯 싶습니다. 물론, 자기는 copy&paste를 하지 않는다고 하시는 분들도 많이 계시겠지만, 변수명을 바꾸고 코드의 들여쓰기를 조정하고, 약간의 추가 코드를 넣었다고 자신이 모든점을 고려하고 생각해서 처음부터 직접 만든 자신만의 코드는 아닌것은 자명하니깐요.

이번 문제로 인하여 네이버 또는 다음이라는 업체 또는 서비스가 매도될 만한 사항은 아닌 듯 합니다. 이번에 문제가 된 코드의 경우 단지 메일에서의 정말 작은 하나의 기능에서 제기된 문제이며, 보통 개발환경에서 이런 하나의 작은 기능에 대한 구현부분은 개발자가 판단하여 개발하며, 코드의 무단도용여부를 회사에서 체크 하지는 않습니다.
어느 한 개발자의 실수 또는 양심의 문제이지, 네이버 또는 다음이라는 업체나 그 업체의 전체 서비스를 싸잡아 매도해서는 안된다고 봅니다.
물론, 개발자가 소속된 회사로서 도의적인 책임이야 가져야겠지만요.

저는 이번 문제가 네이버의 카피냐, 아니면 다음의 카피냐, 그것도 아니면 둘 다 카피냐 가 중요한 것이 아니라, 이번에 대두된 문제를 계기로 웹에서 배포된 클라이언트 사이드 스크립트나 혹은 다른 컨텐츠들의 재 이용이나 참조가 어디까지가 허용이고 어디가 한계인지에 대한 사회적인 합의점을 도출되는 계기가 되었으면 하는 바람입니다.

몇일전 그동안 사용하던 서버 및 신규 서비스 서버로 사용할 서버 몇 대가 입고되어..
토요일 밤부터 일요일 아침까지 철야 서버 교체 및 서버 확장 작업을 실시 하였습니다.

그 중 그동안 Windows2000, ASP로 사용하던 회사 홈페이지 서버도 교체가 되었습니다.
Windows2003을 설치하고, ASP로 작성된 홈페이지 소스를 옮기고 테스트를 진행하던중
파일 다운로드 기능을 테스트 하던 중 문제가 발생하였습니다.

작은 용량의 첨부파일의 다운로드는 문제가 없었는데, 약 10메가 정도 되는 파일의 다운로드가 되지 않는 것이었습니다.

첨부파일의 다운로드는 ADODB.Stream 객체를 사용하여 파일을 강제로 다운로드 시키는 것이였습니다.

해결 방법을 모색하던 중 IIS 6.0에서는 ASP 에서 기본 4M이상의 파일은 다운로드를 받을 수 없게 설정이 되어 있었습니다.

이는 기본 다운로드 버퍼링 용량을 4MB로 제한한 IIS 6.0의 설정때문이었습니다.
이 IIS 기본 설정은 C:\Windows\system32\inetsrv\MetaBase.xml 에 저장 되어 있으며, 위의 메타베이스 XML파일에서 AspBufferingLimit 값을 원하는 사이즈만큼 늘려주면 해결이 가능합니다.

다운로드제한 : AspBufferingLimit="4194304" - 4MB
업로드제한 : AspMaxRequestEntityAllowed="204800" - 200KB

위 두가지 값을 원하는 용량만큼 설정해주시면 파일 전송에 대한 문제를 해결하실 수 있습니다.