2011-01-14 3 views
3

일부 매우 큰 바이너리 파일에 대한 바이너리 편집기를 만들고 있습니다. 소프트웨어 요구 사항 중 하나는 편집기가 원본 파일을 수정할 수 없으므로 대상 파일은 원본의 편집 된 복사본이어야합니다.큰 바이너리 파일 편집을위한 트랜잭션 모델

저는 파일 복사가 한 번만 수행되는 방식으로 편집기를 디자인하려고합니다 (20 분 프로세스). 나는 파일을 편집하는 동안 잠글 수 있지만, 사용자가 프로그램을 종료하면 20 분 동안 복사 과정을 다시 거치게된다. 그들의 원래 편집 세션.

사용자가 복사 한 파일을 편집 가능한 파일로 "등록"하고 변경 사항이 모두 완료되면 파일을 "완료"할 수있는 간단한 프로세스가 있습니까?

이상적으로, 이러한 과정은 편집 가능한 파일이나 거래 정보가 변경되었는지 여부를 감지 에 나를 수있는 것 인 사이 변조 또는 파일이면 마무리가 다른 사본이 발생할 것이다 (편집 세션 다시 편집).

답변

1
  1. 중앙 집중식 위치에서 세션의 레코드 (db?)를 만들고 유지 관리하십시오.
  2. 세션은 사용자 이름 (IP가있는 경우) 또는 사용자를 고유하게 식별하기 위해 사용하려는 항목과 바이트의 해시로 구성됩니다. 해시가 파일 크기에 너무 부담이된다면 파일 날짜와 크기를 사용 해보십시오.
  3. 사용자가 편집기를 닫으면 세션 기록을 위의 정보로 업데이트하고 비활성으로 표시합니다.
  4. 사용자가 편집기를 다시 열면 사용자 이름과 파일 정보와 같은 주요 정보에 액세스 할 수 있어야합니다. 세션 레코드를 찾으면 다시 활성화 할 수있는 비활성 세션입니다. 그렇지 않으면 변경되거나 새 것으로 처리됩니다.

귀하의 요구 사항에 맞습니까?

+0

감사합니다. 바이너리 파일 형식에는 사본인지 여부를 나타내는 플래그가 있기 때문에 해당 플래그를 뒤집습니다. –

+0

그래도 개조 될 수있는 게 아닌가요? –

+0

예,하지만 파일 사양의 일부이므로 편집기에서 편집자가 편집하도록 허용하지 않습니다. –

1

사용자가 취한 행동을 기록하고 싶을 것입니다. 원본 데이터의 복사본에 쓰는 것을 피하기 위해 로그를 별도의 파일에 보관합니다. 사용자의 편집 내용을 타임 스탬프 정보와 함께 저장하십시오.

트랜잭션을 커밋 할 시간이되면 로그 파일의 변경 사항 목록을 읽고 시간 스탬프로 정렬하여 적용하십시오.

편집 프로세스 중에 사용자가 파일에서 데이터를 읽어야하는 경우 소스 파일의 관련 부분을 메모리로 읽어 와서 로그 파일의 해당 데이터에 변경 사항을 적용해야합니다.

이진 파일 형식에 따라 실제로 가장 어려운 부분이 될 수 있습니다. 어떻게 든 바이너리 파일의 내용을 색인 할 수있는 능력이 있다면 편집 로그에서 그 정보를 사용할 것입니다. 이렇게하면 필요한 데이터 만 로그 파일에서 가져올 수 있으며 해당 데이터에 적용 할 수있는 편집 내용을 결정할 수 있습니다.

크기가 크고 형태가없는 얼룩이 있다면 메모리에 전체 내용을 보관하고 읽고 수행 할 때마다 모든 변경 사항을 적용해야합니다. 여기에는 최적화의 여지가 있다고 생각합니다.하지만 모든 것은 여전히 ​​매우 가증 스럽습니다. 읽기 범위를 제한 할 수 없으면 언제든지 편집을 통해 데이터가 변경 될 수 있다고 가정해야합니다.

수정 사항을 안전하게 유지하는 것과 관련하여 까다로운 질문입니다.신뢰할 수있는 환경에서 실행중인 경우 비밀을 유지하고 정보를 인증하는 데 사용할 수 있습니다. 번거롭지 만 바이너리 파일, 편집 로그 및 애플리케이션에만 알려진 비밀의 해시를 해싱 할 수 있습니다. 비밀이 없으면 누구나 와서 파일을 수정하고 새 해시를 삽입 할 수 있습니다.

사용자가있는 컴퓨터 (예 : 바탕 화면)에서 실행중인 경우 비밀 유지는 정말 어려울 수 있습니다 특히 관리 코드를 사용합니다. 이것은 그 자체로 화제이며, 나는 당신에게 좋은 대답이 없습니다.

+0

감사합니다. 나는 "변화의 목록"아이디어에 대해 약간의 생각을했다. 실행 취소/다시 실행 기능을 구현해야하는 경우에도 여전히 유용 할 수 있습니다. –

1

'편집 중'플래그의 세션 정보를 넣는 고정 오프셋으로 파일의 필드를 가질 수 없습니까? 현재 수정 프로세스 (예 : 해당 PID)에 대한 참조가 포함될 수 있습니다. pid가 pid이면 우리 세션입니다. 우리의 PID가 아니라면 프로세스 목록을보십시오. 이 pid를 가진 프로세스가 존재한다면 그것은 합법적 인 편집기입니다. 그렇지 않다면, 우리는 충돌의 결과를보고, 충돌 복구를 시작합니다 (있는 경우). pid가 0이면 파일이 완전히 마무리되었습니다.

큰 파일을 읽을 수있는 경우 편집하기 전에 복사해야합니까?

편집 내용이 파일 크기보다 작 으면 원본 파일과 결과 사이에 'diffs'로 사용자 작업을 기록합니다. 동일한 지점을 반복해서 편집하는 경우 diff를 너무 많이 적용하지 않도록 diff에 "참여"하는 것이 유용 할 수 있습니다. 파일의 사용자보기는 물론 모든 diff가 동적으로 적용된 것입니다.

그 사이에 파일을 복사하고 편집 세션이 이상이면 파일이 모두 여기에 해당하므로 모든 diff 파일을 적용합니다. 허용되는 편집의 특성에 따라 시간이 오래 걸릴 수도 있고 그렇지 않을 수도 있습니다. 편집 세션이 20 분을 초과하면 사용자는 전혀 대기 시간을 알 수 없습니다. 아마도 diff 응용 프로그램의 시간 동안 파일을 잠글 것이고 아마도 복사 시간보다 짧을 것입니다.

1

트랜잭션 및 파일 시스템 작업을 고려 중이므로 트랜잭션 NTFS를 고려하는 것이 도움이 될 수 있습니다. 이것은 귀하의 질문에 대답하지 않지만 당신에게 가능성에 대한 신선한 통찰력을 줄 수 있습니다. 귀하의 질문에 C# 및 Windows 용 태그가 붙어 있으므로 http://offroadcoder.com/CategoryView,category,Transactions.aspx과 같은 .NET 래퍼를 볼 수 있습니다. Scott Klueppel은 TransactionScope의 익숙한 .NET 관용구를 사용하여 트랜잭션 NTFS를 수행하는 방법을 보여줍니다. 나는 스콧이 한 일에 대한 빠른 테스트를했고, 내가 본 것을 좋아한다.