얼마전 Eclipse workspace 증발의 원인을 대략 알것 같습니다.
2012.02.19 13:15
얼마전 2007년부터 모아오던 Java 소스코드를 Eclipse가 다 날려먹었습니다.
Workspace는 Network Drive에 물려져있고, 데스크탑과 노트북이 같은 Workspace를 쓰고 있습니다.
그런데 얼마전 노트북을 포맷하면서 운영체제를 Windows Server 2008 R2로 바꿨는데, 이게 화근이었네요.
데스크탑은 Windows 7 입니다.
.metadata에 보면 workspace 경로 외에, 플러그인의 설정파일 경로도 지정하게 되어있습니다.
그런데 원래는 데탑과 노트북 모두 Windows 7이었고 계정명도 동일해서 문제가 안됐던 거였네요.
workspace는 네트웍 드라이브로 공유중이지만, 플러그인 설정파일은 보통 개인계정에 종속되더군요.
즉 Windows7에서는 C:\Users\cloudn1ne 에 플러그인 환경설정이 저장됐고, 과거에는 놋북 데탑 모두 Windows 7이고 계정명도 같아서 문제가 없었지만
Windows Server 2008 R2에서는 기본계정이 C:\Users\Administrator라서 뭔가 애가 꼬여버린 것 같습니다.
혹시 이클립스 워크스페이스 공유하는 분 께서는.. 워크스페이스 자체를 버전관리하는 것도 좋을 것 같습니다.
(디렉터리 자체를 버전관리하는 툴을 찾는 중. Dropbox가 대안이 될 수도 있을 듯 하네요.)
코멘트 9
-
꼬소
02.19 13:24
-
클라우드나인
02.19 13:33
네트웍 드라이브 파일시스템이 ext3이라 복구는 생각도 못 하고 있습니다.
일요일에도 코딩하고 있어요. ^^ (내 일요일!)
-
꼬소
02.19 13:47
아 전설의 ext3;;;
ext3는 정말 날아가면 답이 없어요;;
ext3에서 파일 지우면 "종"되는 거에요...
(하마가 찾아간다.)
-
클라우드나인
02.19 14:31
운영체제 시험볼때 ext3의 inode 구조를 설명하라는 문제가 나왔는데, 그거 반점도 못 받았어요. -_-;
inode 구조 자체가 복잡한데, 파일 하나 복구하려면 inode 몇개를 '만들어내야'하는지 감도 안잡히니..
그냥 깨끗하게 포기했습니다. =_=
inode를 직접 만드는 것 보다 코딩 새로하는게 쉽고 빠를 것 같아요;;;
-
꼬소
02.19 14:45
저는 회사 와서 포랜식 책보고 ext3 구조 쪼오금.. 알았습니다.
그리고 ext3가 가능하면 디스크의 앞쪽 블럭부터 쓰기 때문에 파일이 지워 질 때... 복구 될 가능성이 적어진다는 것도 알았구요..
(inode보다 근본적인 데이터 지우미 ext3 ㄷㄷㄷ;;;)
그래서 ext3에서 지우면 그냥 포기 합니다;
-
클라우드나인
02.19 15:01
내친김에 ext4로 컨버전시켜야겠네요. ㅎㅎ ext4는 복구하기가 좀 편하다더라구요~
아니면 싹 밀고 이번 기회에 JFS로 고고씽? ㅎㅎ
-
꼬소
02.19 15:48
컨버전 시키기에는 데이터가 너무 많아서 저는 힘들겠어요..(어짜피 옮길 자리도 없어요... 하드값 내리기 전에는 꿈도;;)
그나저나 하드값은 언제 내리나요...
파일시스템이야 다 거기서 거기인데(;;;)
-
calm
02.19 17:42
음 혹시 전용 NAS를 쓰신다면, NAS 자체가 복구 옵션을 지원하는 경우도 있고...
versioning 관리하시려면 syncback 한 번 써보세요 :)
-
ext4도 파일 한번 지우면 복구가 만만치 않던데요. :-)
며칠전에 실수로 하나 지웠다가 그대로 복구 못하고 날려먹었습니다. OTL
5년전에 회사에서 소스 코드를 개발자 로컬 계정이나 PC에 보관하는게 얼마나 위험한 일인지 겪어보고 나서는
소스 코드는 그냥 무조건 형상관리 시스템에 때려넣는게 답이라고 보고 삽니다.
회사에서도 그때 크게 데어서,
개발자가 자기 계정이나 PC에만 있는 소스코드로 빌드한 바이너리는 존재 자체를 인정하지 않구요.
무조건 형상관리 서버에 올라간 소스를 연속빌드 시스템으로 빌드한 바이너리만 받아주고요.
코드는 복구 하셨나요??