Go: 제안: os: Windows에서 FILE_SHARE_DELETE를 설정/열기/OpenFile() 설정

/cc @alexbrainman

https://golang.org/src/syscall/syscall_windows.go#L272의 syscall.Open()
sharemode := ... | FILE_SHARE_DELETE 사용해야 합니다.

왜 그래야 합니까?

알렉스

FILE_SHARE_DELETE는 위의 코드 예제를 활성화합니다. 이 예제는 MacOS 및 Linux에서 작동하지만 Windows에서는 실패합니다. 다음과 같은 경우에도 필요합니다.

fd, err := os.OpenFile(path, os.O_RDWR|os.O_CREATE, 0600)
defer fd.Close()
_, err = fd.Write(...)
err = fd.Sync()  // file now safe to share
err = os.Rename(path, path+"2")
_, err = fd.Read(...)

FILE_SHARE_DELETE는 위의 코드 예제를 활성화합니다. 이 예제는 MacOS 및 Linux에서 작동하지만 Windows에서는 실패합니다.

대신 MacOS 및 Linux 코드를 조정하지 않는 이유는 무엇입니까?

다음과 같은 경우에도 필요합니다.

무슨 말을 하려는지 이해가 되지 않습니다.

알렉스

@networkimprov Windows에서 Close() 후에 Remove를 호출해야 합니다.

path := "delete-after-open"
fd, err := os.OpenFile(path, os.O_RDWR|os.O_CREATE, 0600)
if err != nil { panic(err) }
fd.Close()
err = os.Remove(path)            // or os.Rename(path, path+"2")
if err != nil { panic(err) }

@alexbrainman 신뢰할 수 있는 파일 I/O를 수행할 때(데이터베이스의 경우), 임시 이름으로 파일을 만들고, 쓰고, fsync하고, 이름을 바꾸는 것이 표준 관행입니다.

열려 있는 파일은 기본적으로 Unix에서 이름을 바꾸거나 삭제할 수 있습니다. 이 기능에 대한 Windows 플래그가 설정되지 않은 것은 실수로 보입니다. Go 팀이 Linux 및 MacOS에서 작동하는 방식을 변경하도록 설득할지 모르겠습니다 :-)

@mattn pls는 내가 설명한 수정 사항을 적용하고 내가 게시한 코드를 시도합니다.

Go 팀이 Linux 및 MacOS에서 작동하는 방식을 변경하도록 설득할지 모르겠습니다 :-)

저는 지금 상황이 좋습니다.

알렉스

Windows에서 이 공통 기능을 생략할 이유가 있습니까?

프로그램 시작 시 Unix 동작을 선택할 수 있도록 syscall_windows.go에 스위치를 제공할 수 있습니까?

새 API나 플래그를 추가해도 괜찮습니다. 그러나 나는 현재의 행동을 바꾸는 것에 반대합니다. FILE_SHARE_DELETE는 Unix 동작과 동일하지 않기 때문입니다.

#include <windows.h>
#include <stdio.h>

int
main(int argc, char* argv[]) {
  HANDLE h = CreateFile("test.txt",
      GENERIC_READ | GENERIC_WRITE,
      FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,
      NULL, OPEN_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
  getchar();
  char buf[256] = {0};
  DWORD nread;
  printf("%d\n", ReadFile(h, buf, 256, &nread, NULL));
  printf("%s,%d\n", buf, nread);
  return 0;
}

Windows에서 이 코드를 완성하고 test.exe 로 실행해 보십시오. 이 앱이 키를 누르는 동안 새 cmd.exe를 열고 다음과 같이 "test.txt"를 삭제합니다.

파일은 삭제할 수 있지만 프로세스가 존재하는 동안에는 남아 있습니다. 따라서 이 변경 사항은 예상대로 잘 작동하지 않습니다.

디렉토리 항목이 제거되지 않았다는 것을 알고 있지만 문서는 다음과 같이 말합니다.

파일을 열기 위한 이후의 CreateFile 호출은 ERROR_ACCESS_DENIED와 함께 실패합니다.

그래서 나는 당신의 화면 기록을 이해하지 못합니다.

어쨌든 다음과 같은 스위치가 좋습니다.

syscall.OpenFileShareDelete = true

전에 직장에서 이것에 물린 적이 있음을 언급하고 싶습니다.

기본적으로 우리는:

f, err := os.Open(...)
if err != nil { ... }
defer f.Close()

// lots of code

if err := os.Rename(...); err != nil { ... }

코드는 유닉스 기반 CI 플랫폼에서 잘 실행되었지만 Windows에서는 폭발적이었습니다.

이상한 부작용이 없다고 가정하면 일이 제대로 작동 하면 좋을 것입니다.

IIRC, 우리는 Unix 의미 체계와 더 밀접하게 일치하도록 과거에 GOOS=windows & plan9 동작을 약간 조정했습니다. 의미 체계가 충분히 가깝다면 이것을 또 다른 경우로 만드는 것을 꺼리지 않을 것입니다. 그러나 @mattn 의 의견은 행동이 충분히 가깝지 않아 가치가 없을 수도 있다고 제안합니다.

하지만 글로벌 옵션을 보고 싶지는 않습니다. 그것은 디버깅 악몽처럼 보입니다.

@브래드피츠
아마도 아닐 것입니다. 여기 내 의견을 참조하십시오.
https://groups.google.com/forum/#!topic/golang -dev/R79TJAzsBfM
또는 원하는 경우 가능한 솔루션이 있으므로 여기에 내용을 복사할 수 있습니다. 기본 동작으로 구현하지는 않겠지만 이는 Windows 프로그램이 작동하는 방식과 일치하지 않고 오히려 유사한 교차를 생성하기 위한 해결 방법이기 때문입니다. - os 경험.

@guybrand 는 golang-dev 스레드에 다음과 같이 씁니다.

내 프로그램은 "my.data"라는 파일을 작성한 다음 다른 프로그램을 호출하고 종료될 때까지 기다리지 않습니다... 이 프로그램은 10초가 소요되는 이 파일을 업로드한다고 가정합니다(이 다른 프로그램을 "업로더"라고 부를 수 있음) .
...
내 프로그램이 Windows에서 .Remove를 호출할 때(FILE_SHARE_DELETE가 켜져 있음):
...
업로더는 파일이 제거되었다는 오류를 수신합니다(아마도 EOF).

"내 프로그램"이 os.Remove()를 호출하기 전에 "업로더"가 파일을 연다고 가정하면 Win API 문서와 모순된다고 생각합니다.

_DeleteFile은 닫을 때 파일을 삭제하도록 표시합니다. 따라서 파일에 대한 마지막 핸들이 닫힐 때까지 파일 삭제가 발생하지 않습니다. 파일을 열기 위한 CreateFile에 대한 후속 호출은 ERROR_ACCESS_DENIED._와 함께 실패합니다.

다시 "CreateFile의 _open_osfhandle()을 _fdopen에 페어링"할 때 예제 코드를 가리킬 수 있습니까?

FILE_SHARE_DELETE를 추가하면 많은 프로그래머가 실수로 Unix 동작을 시뮬레이션하는 데 사용합니다. 이 경우 각 OS에 대한 빌드 제약 조건으로 분리된 기능을 만들 수 있습니다. 그리고 os.NewFile() 반환해야 하며 Windows에서는 FILE_SHARE_DELETE를 사용합니다.

각 OS에 대한 빌드 제약으로 분리된 함수를 만듭니다... os.NewFile()을 반환하고 Windows에서 FILE_SHARE_DELETE를 사용합니다.

os.OpenFile()의 기능을 유지하려면 이 계획에서 다음을 모두 다시 구현해야 합니다.

os.OpenFile()
openFileNolog()
파일 열기()
openDir()
새로운 파일()
FixLongPath()
syscall.Open()
makeInheritSa()

@networkimprov

@guybrand 는 golang-dev 스레드에 다음과 같이 씁니다.

내 프로그램은 "my.data"라는 파일을 작성한 다음 다른 프로그램을 호출하고 종료될 때까지 기다리지 않습니다... 이 프로그램은 10초가 소요되는 이 파일을 업로드한다고 가정합니다(이 다른 프로그램을 "업로더"라고 부를 수 있음) .
...
내 프로그램이 Windows에서 .Remove를 호출할 때(FILE_SHARE_DELETE가 켜져 있음):
...
업로더는 파일이 제거되었다는 오류를 수신합니다(아마도 EOF).

"내 프로그램"이 os.Remove()를 호출하기 전에 "업로더"가 파일을 연다고 가정하면 Win API 문서와 모순되지 않습니까?

DeleteFile은 파일을 닫을 때 삭제할 파일을 표시합니다. 따라서 파일에 대한 마지막 핸들이 닫힐 때까지 파일 삭제가 발생하지 않습니다. 파일을 열기 위한 이후의 CreateFile 호출은 ERROR_ACCESS_DENIED와 함께 실패합니다.

다시 "CreateFile의 _open_osfhandle()을 _fdopen에 페어링"할 때 예제 코드를 가리킬 수 있습니까?

WINdows API에 모순이 없다고 생각합니다. 모순처럼 보이는 부분을 지적해 주십시오.

코드 샘플에 관해서는 약간의 Google 검색을 수행하여 다음을 찾았습니다.
http://blog.httrack.com/blog/2013/10/05/creating-deletable-and-movable-files-on-windows/

하지만
참고 - 이것은 내부적으로만 nix와 같은 동작을 제공하며, 이와 함께 작동하는 다른 외부 프로그램은 이를 중단합니다(표준 Windows API를 사용하는 99%

@networkimprov
"이것이 "dir my.data"처럼 들리면 파일이 표시됩니다. 제가 기억하는 한 이것은 Windows .... XP 또는 7(어느 것이 기억나지 않음) 이후로 변경되고(어쩌면 탐색기가 숨길 때까지) 동작이었습니다. 어떻게든) - 다음에 Windows 환경을 시작할 때 다시 테스트할 수 있습니다.(몇 주에 한 번 발생합니다...)

"이것이 파일에 대한 핸들이 있는 다른 프로세스가 여전히 파일을 읽고 쓸 수 있는 것처럼 들린다"는 의미인 경우 "EOF" 스타일 오류가 발생하는 이러한 파일에 대한 쓰기를 읽는 두 번째로 점심을 먹게 될 것입니다. - 하지만 다시 100% 긍정적인지 확인해야 합니다.

두 경우 모두 내 요점은 (이 시점에서 "기본 유사" 대 " os-agnostic" 지점에서 "측면"을 취하고 있음) - _fdopen 스타일 솔루션을 구현하더라도 서비스와 공동 작업하는 다른 모든 실행 파일이므로 다른 go 실행 파일(또는 fd를 직접 사용하는 드문 서비스)과만 상호 작용할 수 있습니다.

다른 말로 하면 - 당신의 앱은 다른 어떤 아이도 이해할 수 없는 "반에서 가장 똑똑한 아이"가 될 것입니다.
내가 생각할 수있는 많은 두 가지 예 :
입력 :
내 앱이 파일을 다운로드하고, 바이러스 백신이 파일을 식별하고 fd를 사용하면 파일을 삭제/격리(==이름 변경의 일종)합니다. 바이러스에 걸리다니...)
출력 :
내 앱은 파일을 다른("업로더"와 같은) 서비스로 파이프하고 삭제합니다. 모든 것이 제대로 작동하는지 확인하기 위해 귀찮게 테스터를 작성하기도 했습니다. 테스트는 통과했습니다.
이제 go test 대신 filezilla를 사용하고, dropbx API를 전송하고, 무엇이든
내 테스트가 작동하는 것과 같은 방식으로 실패하거나 작동하지 않을 것입니다 ...

이것을 기본 동작으로 변경하는 것이 여전히 의미가 있다고 생각하십니까?

Windows에서 이 공통 기능을 생략할 이유가 있습니까?

나는 그 질문을 생각해 본 적이 없다. 모르겠어요.

Windows에서 Go 파일이 작동하는 방식은 내 인생에서 사용한 다른 모든 개발자 도구와 일치합니다. Go 파일이 당신이 제안한 대로 작동한다면 그것은 나에게 놀라운 일이 될 것입니다. 나는 또한 그것이 많은 기존 프로그램을 깨뜨릴 것이라고 생각합니다.

알렉스

나는 또한 그것이 많은 기존 프로그램을 깨뜨릴 것이라고 생각합니다.

@alexbrainman 또한 기본값을 변경하는 대신 활성화하는 스위치를 제안했습니다.

@bradfitz syscall.SocketDisableIPv6이 있습니다. 이는 syscall.Open() 동작을 조정하는 플래그와 크게 다르지 않습니다.

syscall_windows*.go 상태 이후
func Open(경로 문자열, 모드 int, perm uint32) (fd 핸들, 오류 오류) {
....
공유 모드 := uint32(FILE_SHARE_READ | FILE_SHARE_WRITE)

그리고 type_windows*.go는
FILE_SHARE_DELETE = 0x00000004

모든 것이 준비되었습니다. 유일한 질문은 플래그를 구현하는 방법입니다.
나는 전역 옵션과 명시적이지 않은 것을 좋아하지 않으며, 한 명의 개발자가 os.DeleteUponLastHandleClosed = 1로 설정했다는 것을 기억할 수 있지만 장기간 또는 여러 개발자에게는 좋은 방법이 아닙니다.
다른 옵션은 다음과 같이 플래그에 대해 특정 예약 번호를 설정하는 것입니다.
fd, 오류 := os.OpenFile(경로, os.O_RDWR|os.O_CREATE|os.DELETE_WHEN_FREED, 0600)
DELETE_WHEN_FREED는 env의 경우 0이 될 수도 있습니다. 윈도우 외,

또 다른 옵션은 Windows에서 지원되지 않는 perm 매개변수를 사용하는 것이므로 약간 어색할 수 있습니다.
fd, 오류 := os.OpenFile(경로, os.O_RDWR|os.O_CREATE, 777)
777은 예약되어 있으므로 두 시스템을 모두 지원하는 1777 또는 -777이 필요합니다.
읽을 수 있는 DELETE_WHEN_FREED | 777

내가 생각할 수있는 마지막 옵션은 os.OpenDeletableFile(
nix의 os.OpenFile과
회전하다
공유 모드 := uint32(FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE)
창문에

위의 모든 솔루션은 구현이 간단하고 테스트하는 데 시간이 조금 더 걸리며(OS 간) 유권자만 있으면 됩니다...

기본값을 변경하거나 API 표면을 확장하지 않고 이 동작을 지원하는 한 가지 방법은 Windows에서 os.OpenFile 의 flag 매개변수에서 syscall.FILE_SHARE_DELETE 를 수락하고 이를 계산된 sharemode 값. Windows의 syscall.O_* (따라서 os.O_* ) 플래그는 어쨌든 구성된 값을 사용 하므로 포함하려는 Windows 관련 플래그와 충돌하지 않도록 설계할 수 있습니다. 다행히도 이미 syscall.FILE_SHARE_DELETE 와의 충돌을 피하고 있습니다.

어쨌든 저는 기본 동작을 변경하는 것을 강력히 반대합니다. FILE_SHARE_DELETE 를 기본값으로 설정하면 레이스 없는 파일 시스템 순회를 보장할 수 없다는 점에서 POSIX 시스템과 같은 위치에 놓이게 됩니다. 이 플래그를 선택 사항으로 하는 것은 Windows에서 openat , renameat , readlinkat 등과 동등한 것이 필요하지 않은 이유입니다.

여기서 우리가 무엇을 해야 하는지에 대해 깊이 생각하지 않았지만 한 가지만 분명히 하고 싶습니다.

프로그램 시작 시 Unix 동작을 선택할 수 있도록 syscall_windows.go에 스위치를 제공할 수 있습니까?

우리는 이것을 하지 않을 것입니다. 이는 단일 프로그램이 다른 동작을 예상하는 다른 패키지를 사용하는 것을 불가능하게 만듭니다.

@havoc-io
귀하의 제안은 syscall.FILE_SHARE_DELETE가 POSIX 표준 동작과 다르기 때문에 오류가 발생하기 쉬운 프로그램을 생성할 것입니다.
syscall_windows*.go의 작성자는 FILE_SHARE_DELETE 플래그(거기에 있음)를 알고 있었고 이를 사용하는 것이 선호되는 동작이 아니라고 결정했습니다.
왜요?

Liam의 코드를 가져오겠습니다.
fd.Close() 연기
삭제/이름 변경
그런 다음 읽기/쓰기

그래서 실제 정렬 순서는
열려있는
삭제된 것으로 표시
읽기/쓰기(아마도 교차 프로세스/교차 이동 루틴 읽기 쓰기)
닫다

현재 Windows 동작은 개발자에게 "이것은 잘못되었습니다"라고 경고하며 개발자는 삭제를 연기할 수도 있습니다.
FILE_SHARE_DELETE를 추가하면 창에서 "파일이 열려 있어도 삭제로 표시"할 수 있지만 삭제와 닫기 사이에 파일에 액세스하려고 시도하는 다른 프로세스/고루틴이 동시에 실행됩니다(이 코드에서 아마도 더 긴 작업일 것입니다) ) 실패할 것이다
결과: 일관된 "할 수 있습니다" 동작 대신 "가끔 - 특히 동시 사용자가 많을 때 실패하고 이유를 모르겠습니다.
따라서 문제를 해결하지 않고 개발자가 "한 번만 실행"하는 특정 사용 사례를 처리하기만 하면 됩니다.
내 투표는 물론 일관된 행동에 대한 것입니다 ...

Posix와 어떻게 다른가요?
삭제된 것으로 표시된 파일은 더 이상 파일 테이블에 없으며 다른 루틴/프로세스가 동일한 이름의 파일을 생성할 수 있도록 fd로만 존재합니다.

go 내에서 해결할 수 없는 차이점이 있으므로 "동일한 솔루션"을 찾는 것을 중단해야 한다고 생각합니다(대소문자 구분 파일 이름? :) Linux 5.2에서 그렇게 하도록 할 것입니다...)

전체적으로 임시 파일에 대한 솔루션을 찾는 것처럼 보입니다. 그렇다면 Windows는 "사용한 다음 휴지통에 버리는" 파일에 대한 표준 솔루션으로 간주될 수 있는 GetTempFileName을 지원합니다.

반면에 개발자가 창에서 삭제를 연기하도록 허용하려는 경우 가능합니다. 위의 제안을 참조하세요. 그러나 개발자 는 이에 대한 책임을 지고 의식을 이해해야 합니다. 따라서 좋은 이름 규칙이 있는 플래그여야 합니다.

이 기능의 주요 용도는 열린 파일을 만든 후 이름을 바꾸는 것입니다.

fd, err := os.OpenFile(path, os.O_RDWR|os.O_CREATE, 0600)
_, err = fd.Write(...)
err = fd.Sync()  // file now safe to share
err = os.Rename(path, shared_path)
// os.Close() at program exit

나는 당신이 os.O_WRNDEL 플래그를 추가하지 않는 이유를 모르겠습니다. 삭제된 파일은 디렉토리에 남아 있지만 os.Close() 전까지는 열 수 없습니다. 또한 파일을 삭제하기 전에 임시 디렉토리로 이동하면 Unix와 유사한 동작이 더 많이 제공된다는 점을 언급하십시오.

@guybrand 제 제안을 오해하고 FILE_SHARE_DELETE 가 기본적으로 활성화되어야 한다고 주장하는 것이 아닙니다. 사실 저는 제 의견의 두 번째 단락에서 언급한 이유로 반대합니다. 내 제안은 os 패키지의 파일 인프라를 계속 사용하면서 사용자가 FILE_SHARE_DELETE 동작(파일별로)을 선택할 수 있도록 하는 메커니즘이었습니다. 이 제안은 패키지의 API 표면을 확장하지 않고 그렇게 하는 메커니즘을 제공합니다.

os.O_WRNDEL 플래그를 추가하지 않는 이유를 모르겠습니다(Windows 이름 바꾸기/삭제, 다른 플랫폼에서는 작동하지 않음)

@networkimprov 완전히 유효한 플래그가 이미 존재하기 때문에 새 플래그를 정의할 필요가 없다는 점을 제외하고는 본질적으로 syscall.FILE_SHARE_DELETE 입니다. 유일한 구현 변경 사항은 Windows의 syscall.Open 에서 이 플래그를 감시하고 syscall.O_* / os.O_* 플래그에 대한 향후 추가 항목이 이 플래그와 충돌하지 않도록 확인하는 것입니다. os.OpenFile 대한 문서는 Windows에서 이 플래그의 수락을 반영하도록 업데이트될 수 있습니다.

@havoc-io 오해해서 죄송합니다. 다음에서 발췌한 내용입니다.
" ... syscall.FILE_SHARE_DELETE ...를 계산된 공유 모드로 수락하려면..."

os.O_WRNDEL을 추가하면 "동작이 무엇인지"와 관련하여 개발자에게 충분히 명시적이지 않다는 점을 제외하고는 두 번째 제안과 일치합니다. 아마도 os.WADRNDEL - Windows에서 지연된 이름 바꾸기/삭제 허용) .

@alexbrainman 또한 기본값을 변경하는 대신 활성화하는 스위치를 제안했습니다.

관심 없어. 감사합니다.

알렉스

열려 있는 파일의 @guybrand 이름 변경이 지연되지 않는지 확인했습니다.

죄송합니다. 제안 사항이 무엇인지 다시 묻습니다. 여는 파일을 삭제하시겠습니까? 여는 파일의 이름을 바꾸시겠습니까? 둘 다?

우리 중 3명이 지금 새 깃발을 제안하고 있습니다. 예:

fd, err := os.OpenFile(path, os.O_RDWR|os.O_CREATE| os._WRNDEL, 0600)

fd, err := os.OpenFile(path, os.O_RDWR|os.O_CREATE| syscall.FILE_SHARE_DELETE, 0600)

우리 중 세 명이 지금 새 깃발을 제안하고 있습니다

새로운 플래그, 특히 코드를 읽는 누군가가 쉽게 구문 분석할 수 없는 플래그는 부적절하다고 생각합니다. syscall.FILE_SHARE_DELETE 사용하면 플랫폼에 특정한 일이 일어나고 있음을 독자에게 즉시 알릴 수 있어 훨씬 더 명확하고 명확해집니다.

이것은 POSIX 플랫폼에서 이미 허용됩니다. os 패키지에 통합되지 않은 많은 POSIX 특정(및 플랫폼별) open 플래그가 있습니다. 예를 들어 Darwin의 O_EVTONLY 플래그를 지원하기 위해 os._DEVTONLY 와 같은 것을 추가하는 것은 의미가 없습니다. syscall 패키지에서 os.OpenFile 직접 플래그를 전달할 수 있기 때문입니다

os.OpenFile(..., os.O_RDONLY | syscall.O_EVTONLY, ...)

이 경우 플랫폼별 플래그는 기본 open 시스템 호출로 전달됩니다.

FILE_SHARE_DELETE 행동이 사람들에게 진정으로 필요한 것이라면 대답은 단순히 os.OpenFile 가 Windows에서 기본 CreateFileW 호출까지 플래그를 유사하게 스레드할 수 있도록 하는 것입니다. 적어도 FILE_SHARE_DELETE .

예제 구현은 여기 에서 찾을 수

@networkimprov

우리 중 3명이 지금 새 깃발을 제안하고 있습니다. 예:

깃발을 어떻게 예상하십니까?

열려 있는 파일의 @guybrand 이름 변경이 지연되지 않는지 확인했습니다.

맞습니다. 하지만 파일이 열려 있는 동안 허용하려면 둘 다 FILE_SHARE_DELETE가 필요합니다.
내 제안된 용어를 참조하는 경우, 우리는 할 수 있습니다
os.WARNDFDEL - Windows에서 이름 변경을 허용하고 삭제 연기가 너무 깁니다. WINDOWS_ALLOW_OPENNED_FILE_RENAME_OR_DEFFERED_DELETE에서 약어를 사용하겠습니다.
더 나은 IMO입니다.

@guybrand 나는 이것에 대한 완벽하게 좋은 플래그가 수십 년 동안 주변에 os 패키지에 복잡한 이름과 불투명한 동작을 가진 새로운 플랫폼별 플래그를 추가하는 것의 가치를 실제로 보지 못합니다( FILE_SHARE_DELETE ). syscall.FILE_SHARE_DELETE 를 플래그로 사용하는 것이 훨씬 더 명확하고 명시적입니다. 위에서 언급했듯이 os 패키지에 추가되지 않았지만 여전히 허용되는 POSIX 관련 및 플랫폼별 플래그가 많이 있습니다.

syscall.FILE_SHARE_DELETE는 창 전용입니다. 우리는 다른 곳에서는 금지된 것이 필요합니다. 아마도 WIN 또는 WINDOWS 접두사와 함께 pkg os에 나타나야 합니까?

@mattn pls는 위의 @

우리는 다른 곳에서는 금지된 것이 필요합니다.

@networkimprov 플래그는 다른 곳에 존재할 필요가 없습니다. Windows 코드는 다음과 같습니다.

import (
    "syscall"
    "os"
)

file, err := os.OpenFile(..., os.O_RDWR | syscall.FILE_SHARE_DELETE, ...)

예, 이 코드는 플랫폼에서 게이트되어야 하지만 이 플래그의 동작은 POSIX 시스템의 동작과 일치하지 않기 때문에 어쨌든 그렇게 해야 할 것입니다. 당신이 모든 플랫폼에서 동일한 코드를 가지고의 편의를하려는 경우에는 (값으로 자신의 상수를 정의 할 수 있습니다 syscall.FILE_SHARE_DELETE Windows에서와 0 와 패스 비 Windows 시스템) os.OpenFile . os 패키지의 일부가 아닌 플랫폼별 O_* 플래그를 가져오려는 경우(예: Darwin의 경우 O_EVTONLY 또는 Linux의 경우 O_ASYNC ).

코드를 작성할 때 크로스 플랫폼이 될 것으로 예상합니다. FILE_SHARE_DELETE는 syscall_*에 존재하지 않습니다. Windows 하나뿐입니다(따라서 anf는 다른 시스템에서 컴파일되지 않습니다).

0x4 const를 다음과 같이 사용할 수 있습니까?
FILE_SHARE_DELETE = 0x00000004

못생긴거 빼고는
netbsd_arm
O_NDELAY = 0x4
O_NONBLOCK = 0x4

따라서 0x4를 사용하면 netbsd_arm에서 다르게 코드가 생성됩니다.

따라서 모든 플랫폼에 FILE_SHARE_DELETE를 추가하거나 Windows 플랫폼은 0x4, 다른 플랫폼은 0x0이므로 "폐기"하거나 이 문제에 대한 특정 플래그를 생성합니다.

그리고 어쨌든 syscall_windows*를 변경해야 합니다.
함수 열기(
...
공유 모드 := uint32(FILE_SHARE_READ | FILE_SHARE_WRITE | isDeleteOn )
여기서 isDeleteOn은 모드에 새 플래그가 포함되어 있는지 확인합니다.

@가이브랜드

코드를 작성할 때 크로스 플랫폼이 될 것으로 예상합니다.

동일한 os.OpenFile 호출이 여러 플랫폼에서 컴파일된다고 해서 코드가 플랫폼 간이라는 의미는 아닙니다. Windows에는 FILE_SHARE_DELETE 사용할 때 고려해야 하는 여러 가지 보안 고려 사항이 있으며 파일 수명 주기의 의미 체계는 POSIX와 Windows 시스템 간에 너무 다르기 때문에 파일 처리 코드는 플랫폼 간에 적어도 조금 다르게 보이지 않을 것입니다. FILE_SHARE_DELETE 사용하면 본질적으로 레이스 없는 파일 시스템 순회를 보장할 방법 없이(그리고 열기를 위한 POSIX의 unlink 파일 액세스의 이점 없이) POSIX.1-2008 이전 상황에 놓이게 됩니다. 파일).

어쨌든, 당신은의 값이있는 플래그를 원하는 경우 syscall.FILE_SHARE_DELETE Windows에서와 0 다른 플랫폼에서, 당신은 여전히 쉽게 다음 자신의 일정 빌드 태그에 의해 제어의 정의와 함께 그것을 할 수 os.OpenFile 를 호출하는 기본 코드는 모든 플랫폼에서 동일할 수 있습니다(해당 사용자 지정 플래그 사용).

다른 플랫폼의 syscall 패키지에 존재하는 플랫폼별 플래그가 많이 있지만 os 패키지에 의해 모두 노출될 수는 없으며 플랫폼에서 작동하지 않습니다. 지원합니다. 플랫폼별 코드 및 동작을 원하면 syscall 패키지에 도달해야 합니다.

이동 표준 라이브러리가 (잠재적으로) 여기해야하는 유일한 것은 지원입니다 syscall.FILE_SHARE_DELETE 에 syscall.Open (결과적으로 os.OpenFile ) Windows에서.

위에서 언급했듯이 FILE_SHARE_DELETE를 추가하면 많은 프로그래머가 실수로 Unix 동작을 시뮬레이션하는 데 사용합니다. 하지만 좋지 않습니다. 예를 들어 파일이 존재하는 것을 보기 위해 어플리케이션을 생성하는 경우를 생각해 보십시오. 응용 프로그램이 파일을 삭제하는 경우 다른 응용 프로그램에서 파일을 찾을 수 없는 것으로 간주됩니다. 그러나 FILE_SHARE_DELETE는 나중에 삭제하도록 표시만 합니다. 파일이 남아 있습니다. UNIX에서는 잘 작동하지만 Windows에서는 작동하지 않습니다. UNIX 동작을 시뮬레이션하기 위해 FILE_SHARE_DELETE를 사용하지 마십시오.

@mattn 나는 당신의 우려에 동의합니다 - 사람들은 미묘한 의미를 이해하지 않고 Windows 코드를 POSIX 시스템과 "동일하게 작동"시키기 위해 편의상 플래그를 사용하려고 할 수 있습니다. 그러나 해당 플래그에 액세스하기 위해 syscall 패키지로 이동해야 하는 경우 해당 플래그가 무엇을 하는지 이해하는 데 시간이 걸릴 수 있습니다.

@mattn , Unix와 유사한 동작의 경우 앱에는 플랫폼 중립 코드 2줄이 추가로 필요합니다.

fd, err := os.OpenFile(path, ... | syscall.FILE_SHARE_DELETE, 0600)
...
tmp_path := mkTempName()
err = os.Rename(path, tmp_path)  // works immediately; path is now available
err = os.Remove(tmp_path)

이것을 문서화하려면 os.OpenFile()에 대한 문서에서 한 문장이 필요합니다.

내 Windows 코드에서 작업하는 모든 사람이 적용해야 하는 패치를 pkg syscall에 배포하지 않도록 해주세요! https://github.com/golang/go/issues/32088#issuecomment -493876119도

저는 우리 모두가 대부분의 사실에 동의한다고 생각합니다. 다르게 표현하면 요약하고 행동 방침을 설정하겠습니다.

1. 동의: Windows와 POSIX는 위의 동작이 다르므로 동일한 동작을 목표로 해서는 안됩니다.
2. 동의: FILE_SHARE_DELETE를 플래그로 허용하는 요청이 유용합니다.
3. 제안: 버그가 아니라 기능 요청처럼 들리도록 티켓을 "지원 FILE_SHARE_DELETE"로 변경합니다.
4. 대부분 동의: 이 기능은 기본 패키지가 아닌 프로그램 수준의 개발자 플래그여야 합니다.

작업 항목:

1. syscall_windows.go 변경
   함수 열기(
   ...
   공유 모드 := uint32(FILE_SHARE_READ | FILE_SHARE_WRITE | (모드 및 FILE_SHARE_DELETE) )
2. 이 동작을 활용하려는 개발자는
   file, err := os.OpenFile(..., os.O_RDWR | syscall.FILE_SHARE_DELETE, ...)
   또는 그들이 그들의 프로그램이 크로스 플랫폼이 되기를 원한다면 다음과 같은 내부 플래그를 생성할 것입니다:

mycode_windows.go
const OPENFILEFLAG = syscall.FILE_SHARE_DELETE
mycode_others.go
const OPENFILEFLAG = 0

다음을 사용하십시오.
file, err := os.OpenFile(..., os.O_RDWR | OPENFILEFLAG, ...)

이에 동의하면 수정 작업이 최소화되며(하나의 라이너) 위험이 매우 낮습니다.

투표를 하면 빠르게 수정할 수 있습니다.

동의: FILE_SHARE_DELETE를 플래그로 허용하는 요청이 유용합니다.

이 문제의 목적이 무엇인지 이해하지 못하기 때문에 아직 이에 동의하지 않습니까?

@mattn pls는 https://github.com/golang/go/issues/32088#issuecomment -494305074를 참조

목적 : 개발자가 열린 파일의 이름을 바꾸거나 삭제할 수 있습니다.

누락된 사항: syscall_windows.go는 현재 하드 코딩되어 있습니다 .
func Open(path string, mode int, perm uint32) (fd Handle, err error) {
...
sharemode := uint32(**FILE_SHARE_READ | FILE_SHARE_WRITE**)

제안된 변경 사항:
개발자가 비트 4(FILE_SHARE_DELETE)가 켜진 모드 매개변수를 전달하면 공유 모드가 다음과 같이 변경됩니다.
sharemode := uint32(FILE_SHARE_READ | FILE_SHARE_WRITE | **(mode & FILE_SHARE_DELETE)** )

Rename() 또는 Remove() 전에 Close()를 호출하지 않는 이유가 여전히 궁금합니다. Go의 표준 라이브러리 코드를 읽을 수 있습니다. 파일은 Rename() 또는 Remove() 전에 Close()로 닫힙니다. Renamoe/Rename 다음에 Close()를 호출해야 하는 이유는 무엇입니까?

@networkimprov 가 고려하고 있는 비즈니스 사례가 무엇인지 잘 모르겠습니다. 임시 공유 파일이 될 것입니다. 내 앱과 다른 앱이 이 파일을 사용하고 있습니다. (내 앱이 충돌하더라도) 이 파일을 확인하고 싶습니다. 작업을 마친 후에는 더 이상 존재하지 않을 것이므로 생성하고 Remove()하고 앱을 닫거나 앱을 닫으면 파일이 제거됩니다.

하지만 @networkimprov 가 Rename()을 사용하려는 것처럼 보이므로 아마도 diff 사용 사례일 것입니다.

https://github.com/golang/go/issues/32088#issuecomment -494305074에서 언급했듯이 프로그램이 종료될 때까지 이름이 변경된 파일을 닫을 필요가 없습니다.

@mattn , pls는 C 및 C++ 개발자가 사용할 수 있는 OS 기능을 사용해서는 안 된다고 주장하지 않습니다.

내 앱이 충돌하더라도 이 파일이 완료되면 더 이상 존재하지 않게 하고 싶습니다.

@guybrand defer 문은 모든 유형의 충돌에서 실행되는 것이 보장되지 않으므로 파일 삭제를 확인 하려는 경우 os.Remove 작업을 연기하는 것은 신뢰할 수 있는 방법이 아닙니다. 그것에 대해 가십시오. 자동으로 삭제되는 파일을 원한다면 시스템이 삭제하는 임시 파일이 더 나은 선택입니다. 두 프로그램에서 공유하는 파일 위치를 원하면 파일 존재가 아닌 잠금(예: POSIX의 경우 fcntl 잠금 및 Windows의 경우 LockFileEx / UnlockFileEx )으로 조정해야 합니다. .

#32088(주석)에서 언급했듯이 프로그램이 종료될 때까지 이름이 변경된 파일을 닫을 필요가 없습니다.
@mattn , pls는 C 및 C++ 개발자가 사용할 수 있는 OS 기능을 사용해서는 안 된다고 주장하지 않습니다.

@networkimprov 열린 후 이름 바꾸기 작업은 유효한 사용 사례이지만 HANDLE 파일을 보유하고 있는 프로그램이라면 이미 그렇게 할 수 없습니까? FILE_SHARE_DELETE 의 유일한 목적은 파일이 열려 있는 동안 다른 프로세스가 파일의 이름을 바꿀 수 있도록 하는 것입니다. 어떤 경우에는, 당신이 사용할 수있는 FILE_SHARE_DELETE 지금, 당신은 단지 수동으로 호출 할 필요가 CreateFileW 와 떠나는 결과를 통과 os.NewFile . 이것이 어떻게 생겼는지에 대한 예를 여기에서 찾을 수 있습니다. 결과 HANDLE 는 os.NewFile 로 전달될 수 있습니다.

@mattn 나는 이 깃발이 유용한 도구라기보다 발총에 가깝다는 데 동의하기 시작했습니다. 명확히 하자면, 저는 실제로 이 플래그를 원하지 않으며, 그 존재에 대해 제가 볼 수 있는 유일한 주장은 POSIX와 Windows 간의 제어의 완전성과 패리티입니다. 반면에 위에서 언급했듯이 CreateFileW (이 플래그를 지정하여)를 수동으로 호출한 다음 결과를 os.NewFile 넘기는 것도 비교적 쉽습니다. 그것에 대한 지원을 추가하십시오.

@havoc-io os.File.Rename()이 없습니다. 그것은 좋은 해결책이 될 것이지만 상대적으로 무거운 리프트입니다.

다시 CreateFileW + os.NewFile(), https://github.com/golang/go/issues/32088#issuecomment -493876119를 참조

@havoc-io

내 앱이 충돌하더라도 이 파일이 완료되면 더 이상 존재하지 않게 하고 싶습니다.
@guybrand 모든 유형의 충돌에서 defer 문 실행이 보장되지 않습니다.
이것은 내가 "내 앱이 충돌하더라도"라고 말한 것과 정확히 일치했습니다.

그 존재에 대해 내가 볼 수 있는 유일한 인수는 POSIX와 Windows 간의 제어의 완전성과 패리티입니다.
나는 이것이 "POSIX와 Windows 간의 제어의 완전성과 패리티"를 가져올 것이라는 점에 동의하지 않습니다. IMO는 개발자가 행동이 동일하지 않을 때 동일하다고 생각하는 것을 혼란스럽게 할 뿐입니다. 위에서 몇 가지 예를 제시했습니다.

CreateFileW를 수동으로 호출하기 쉽습니다.
그것은 정말 쉬운 일이든 아니든, 다시 말해서 "우리는 이것을 지원하고 싶지 않습니다"라고 말하는 것입니다. 그건 그렇고 IMO는 내가 아니라

참고로, FILE_SHARE_DELETE 사용을 포기한 이유는 다음과 같습니다.

씨엘: https://codereview.appspot.com/8203043/

erlang/otp에서 커밋: https://github.com/erlang/otp/commit/0e02f488971b32ff9ab88a3f0cb144fe5db161b2

파이썬: https://bugs.python.org/issue15244

@havoc-io os.File.Rename()이 없습니다. 그것은 좋은 해결책이 될 것이지만 상대적으로 무거운 리프트입니다.
Re CreateFileW + os.NewFile(), #32088(주석)을 참조하세요.

@networkimprov 그냥 os.Rename(file.Name(), <target>) 쓰면 안되나요 ? 기본적으로 FILE_SHARE_DELETE 켜져 있지 않은 Go의 장점입니다. HANDLE 파일을 보유하고 있기 때문에 file.Name() 가 여전히 유효한 것을 가리킬 것이라는 것을 알고 있습니다. renameat 경우에도 POSIX에서 보장합니다. CreateFileW + os.NewFile 와 관련하여 귀하의 의견에 설명된 대부분의 스택은 관련 이 없으며 makeInheritSa 는 거의 확실히 귀하 가 원하지 fixLongPath 경로 기능일 것입니다. 이것은 아마도 당신이 설명한 사용 사례에 필요하지 않을 것입니다.

@guybrand 내 말의 의미를 명확히하기 위해 ...

완전성: API 표면 완전성(예 FILE_SHARE_DELETE 를 사용할 수 있는 기능)
제어 패리티: os.OpenFile 의 flag 매개변수를 통해 os.OpenFile CreateFileW 플래그를 지정하는 기능. 예를 들어, POSIX에서 syscall.O_NOFOLLOW 통해 os.OpenFile 를 라우팅할 수 있지만 Windows에서는 syscall.FILE_FLAG_OPEN_REPARSE_POINT 통해 os.OpenFile 를 라우팅할 수 없습니다. 다시 말하지만, os 패키지가 POSIX API를 중심으로 모델링되었기 때문에 여기에서 제어의 전체 패리티는 헛된 꿈이라고 생각합니다. 필요할 때 syscall.CreateFileW 에 도달하게 되어 매우 기쁩니다.

@mattn 링크 주셔서 감사합니다. Go CL은 syscall.Open() _default_를 패치하는 것이었습니다. 토론에서는 Open()에 대해 _flag_를 허용하지 않는 일반적인 이유를 제공하지 않습니다. 타사 패키지는 플래그가 없는 os.File을 반환할 수 있지만 호출자가 해당 파일의 이름을 바꾸거나 삭제하려고 시도하는 경우에만 문제가 됩니다. 드문 경우입니다.

Python 스레드는 위에서 쓴 것처럼 삭제하기 전에 열려 있는 파일의 이름을 바꿔야 한다고 언급합니다.

Erlang은 6년 넘게 file_share_delete를 _default_로 사용

위에 링크된 Erlang 경험과 Python 스레드를 반영하면 다음이 분명합니다.

1. File_share_delete는 기본적으로 크로스 플랫폼 환경에서 잘 작동합니다. 유일한 주의 사항은 원래 파일 이름을 다시 사용할 수 있는 경우 사용자 코드가 파일을 제거하기 직전에 고유한 이름으로 파일 이름을 바꿔야 한다는 것입니다(사소한 변경).
2. 대부분의 Windows 프로그램은 단순히 MSVC 런타임이 O_TEMPORARY와 함께 사용할 수만 있기 때문에 file_share_delete를 사용할 수 없습니다.

따라서 syscall.Open()은 기본적으로 file_share_delete 비활성화 하는

1.14 주기 동안 해당 접근 방식에 문제가 나타나면 명시적 플래그 방법을 대신 적용할 수 있습니다.

따라서 syscall.Open()은 기본적으로 file_share_delete를 사용해야 하고 syscall은 필요한 경우(예: 디버깅) 비활성화하는 전역 플래그를 제공해야 한다고 결론지었습니다.

@networkimprov 미묘하고 미묘하지 않은 방식으로 수많은 기존 프로그램을 깨는 것 외에도 문제의 사실은 지금 이 플래그 를 FILE_SHARE_DELETE 의 부재에 의존하는 프로그램 의 보안 문제가 될 것이라는 것입니다. . 특히, 열려 있는 파일 및 디렉토리의 불변성에 의존하는 프로그램에 대한 사용 시간 확인 취약점이 많이 발생합니다.

편집: 기본값을 변경하는 것이 왜 나쁜 생각이고 기존 프로그램을 거의 깨뜨릴 것인지에 대한 자세한 내용은

Go on Windows의 가장 일반적인 경우는 Linux 또는 기타 Unix에

코드가 GOOS=windows 동작에 의존하는 경우 Linux에서 손상되어 취약할 수 있습니다. 따라서 이미 보안 문제가 있을 수 있습니다.

os.Rename() 및 .Remove()는 Windows에서 차이점을 문서화하지 않으므로 아무도 그들이 존재한다고 추측하지 않습니다. 지금 문서화하면 기존 코드가 수정되지 않습니다. 비호환성을 수정하고 이에 대한 블로그 게시물을 게시하면 훨씬 더 도움이 될 것입니다.

Erlang은 file_share_delete를 기본값으로 채택하기 전에 잠시 사용되었습니다.

Go on Windows의 가장 일반적인 경우는 Linux 또는 기타 Unix에

코드가 GOOS=windows 동작에 의존하는 경우 Linux에서 손상되어 취약할 수 있습니다. 따라서 이미 보안 문제가 있을 수 있습니다.

@networkimprov

이 논리에 따라 Windows의 파일 열기 인프라도 POSIX의 기본 동작과 일치하도록 프로세스 생성 전반에 걸쳐 기본적으로 파일 설명자를 상속 가능하도록 수정해야 합니다. 기존 프로그램은 런타임/표준 라이브러리의 이전 기본 동작에 의존하는 것으로 비난받을 수 있으며 템플릿 CVE는 사용자가 프로그램을 위해 파일링할 수 있도록 릴리스 정보에 포함될 수 있습니다.

그러나 물론 그것이 완료된 것은 아니며 대신 Go의 런타임 및 표준 라이브러리가 뒤로 구부러져 POSIX의 기본 및 잘못 설계된 동작을 해결하고 Windows가 수행하는 작업을 미러링하려고 합니다.

상황은 공유 파일 액세스와 동일합니다. Windows는 틀림없이 디자인이 옳았고 POSIX.1-2008은 디자인 한계를 해결하기 위해 많은 기능을 추가해야 했습니다.

@mattn을 포함하여 위의 여러 번 언급 한 것처럼 또한, FILE_SHARE_DELETE POSIX와 같은 윈도우 동작합니다을하지 않습니다 개방 파일 - 여전히 다른 것보다이 플래그를 사용하여 훨씬 더 명백해질 것이다 중요한 행동 차이가있을 것입니다 os.Remove 및 os.Rename 동작.

귀하의 코드가 모든 플랫폼의 동작에 보편적으로 의존하는 경우 다른 플랫폼(Windows에서 POSIX 동작에 의존하는 것도 포함)에서 손상되고 취약할 수 있다고 주장합니다. 코드의 플랫폼 변형을 이해하고 해결하는 데 시간을 들이지 않는다면 플랫폼 간 개발을 하고 있지 않은 것입니다.

어쨌든 @ianlancetaylor는 이미 전역 플래그를 사용하여 이 기능을 켜는 것을 제어하는 ​​아이디어에

제 생각에는 여기서 유일하게 깨지지 않는(그리고 보안을 손상하지 않는) 옵션은 syscall.Open 의 flag 인수에 syscall.FILE_SHARE_DELETE 에 대한 지원을 추가하거나 그냥 강제로 FILE_SHARE_DELETE 기능을 사용하려는 사용자는 CreateFileW + os.NewFile . 예, 이 동작을 원하는 개발자의 약간의 작업이 필요하지만 Win32와 POSIX는 근본적으로 다른 짐승이며 런타임과 표준 라이브러리가 차이점을 포장하는 것만큼 좋은 일을 한다는 것이 놀랍습니다. 표준 라이브러리에 나타나는 이러한 플랫폼 사이에는 훨씬 더 중요한 차이점이 있습니다. 예를 들어 완전히 다른 권한 모델, os.File.Chmod 가 Windows에서 작동하지 않는다는 사실, os.Chown 가 Windows에서 작동하지 않는다는 사실 Windows, 내부 폴러가 서로 다른 플랫폼에서 서로 다른 유형의 파일을 지원한다는 사실 등. Go의 런타임 및 표준 라이브러리는 최선을 다하지만(잘 수행하지만) 플랫폼 간 개발 문제에 대한 만병 통치약은 아닙니다. 어느 시점에서 개발자는 이러한 차이점을 스스로 처리해야 합니다. 수정하기 위해 주요 변경 사항을 추가하는 것( 올바른 말을 하지 않았음을 주목하세요) 모호한 행동의 엣지 케이스는 나에게 의미가 없습니다.

이에 대한 사용 사례를 하나 더 공유하고 싶었습니다.

현재 Docker 엔진이 활성 로그의 이름을 .1이라는 이름으로 바꾸는 방식으로 Docker 로그 회전 논리가 작동하면 이전 이름으로 새 로그를 만듭니다.
docker logs --follow <container> 명령으로 로그를 적극적으로 추적하는 모든 클라이언트
파일 시스템 이벤트에서 다음을 알 수 있습니다.
https://github.com/moby/moby/blob/916eabd459fe707b5c4a86377d12e2ad1871b353/daemon/logger/loggerutils/logfile.go#L552 -L593

Windows가 이러한 이벤트를 즉시 알아차리도록 하는 논리도 있습니다.
https://github.com/moby/moby/blob/916eabd459fe707b5c4a86377d12e2ad1871b353/daemon/logger/loggerutils/logfile.go#L670 -L676

이 모든 것이 Linux에서는 잘 작동하지만 Windows에서는 로그 다음에 클라이언트가 있는 경우 The process cannot access the file because it is being used by another process. 오류가 발생하지 않습니다(문제: https://github.com/moby/moby/issues/39274 ).

로그를 따르는 클라이언트가 n개 있을 수 있으므로 먼저 열려 있는 모든 파일 핸들을 수집하고 파일 회전 전에 닫는 것이 매우 까다로울 수 있으므로 syscall.FILE_SHARE_DELETE 대한 지원을 정말 보고 싶습니다.

안녕! 빠른 배경: 저는 Chrome CI 인프라에서 일합니다. 우리는 저수준 작업자 코드를 Go로 이식하고 있습니다. 우리는 Windows에서 매일 수십만 개의 테스트 호출을 실행합니다.

나는 모든 의견을 읽었으며 다음이 각 개인의 의견에 대한 명확하고 정확한 요약이 되기를 바랍니다.

우리의 사용 사례는 @networkimprov 의 놀라운 특성과 달리 Windows에서 실행되도록 Windows에서 Go 실행 파일을 빌드하는 것입니다. 이 주석에서 이 "Windows에서 POSIX 동작 가정" 사용 사례는 무시하겠습니다. 이는 잘못된 가정이고 @mattn 을 끌어

마이그레이션의 일부로 #39274와 유사한 로그 파일 회전으로 인해 부분적으로 FILE_SHARE_DELETE가 필요합니다. 문제 #25965의 문제이기도 합니다.

https://codereview.appspot.com/8203043/ 에서 제안한 것처럼 전체 도구 체인 동작을 변경하는 @ianlancetaylor 는 좋은 생각이 아니라는 데 동의합니다. 파일 핸들을 잠금 파일로 사용할 때 이 제안을 염두에 두는 즉각적인 문제가 있습니다. 우리는 이 동작을 사용합니다. 그리고 @havoc-io가 말한 것. 그러니 이것도 무시합시다.

다시 말해서 이 의견의 나머지 부분에서 이러한 제안을 무시하겠습니다.

• POSIX와 똑같이 행동하려고 하면 작동하지 않을 것입니다.
• 사용자를 차단하는 옵트아웃(또는 옵트아웃 없음)으로 전역 동작을 변경합니다.

이렇게 하면 분명히 Windows 고유의 이름을 가진 호출별 플래그가 남게 됩니다. 이것이 바로 @guybrand가 제안한 것입니다.

@mattn 이의 제기가 이해가 되지 않습니다. @guybrand가 제안하는 것은 합리적입니다. 예 Windows는 파일 공유와 관련하여 다르게 작동합니다. 파일 삭제 권한과 비슷하지만 Windows에서는 매우 다릅니다 . 이미 여러 가지로 갈라지고 있습니다. "개발자가 그 동작을 오해할 수 있다"는 입장에서 Windows 전용 플래그에 대해 이의를 제기하는 것은 사실이 아니라 의견입니다. 개발자가 자신이 하는 일을 모르거나 MSDN의 설명서를 읽지 않을 것이라고 가정합니다. 이는 일반적인 경우 😎에 대한 정당한 이의입니다만, 적법한 사용 사례를 선택적 플래그로 차단한다는 이유로 강력한 이의는 아닙니다.

아이러니하게도 이것은 이 문제가 해결될 때까지 #25965를 수정하기 위해 CreateFileW 직접 호출하도록 'go run'을 변경해야 한다는 것을 의미합니다. 왜냐하면 FILE_FLAG_DELETE_ON_CLOSE 도 필요하기 때문입니다.

감사 해요!

새 속성이 있는 파일을 열거나 만들기 위해 새 기능(golang.org/x/sys?)을 구현해야 하는지 아니면 원래 동작을 변경해야 하는지 여부를 알기 위해 케이스가 어떻게 존재하는지 알고 싶습니다. 현재 위의 의견에서 알 수 있는 한:

1. 로깅을 위해 삭제 가능한(이름 변경 가능) 파일을 생성합니다.
2. 닫을 때 삭제될 임시 파일에 대한 파일을 만드는 중입니다.

1의 경우 속성이 있는 파일을 생성/열기 위해 새 함수에서 제공할 수 있습니다. 그리고 logger.SetOutput(file)을 사용하여 파일을 설정할 수 있습니다.

2의 경우 새로운 기능으로 생성/열 수도 있습니다.

BTW, 나는 # 25965가 이 문제와 관련이 없다고 생각합니다. 아마도 Windows의 한계일 것입니다.

(어쨌든 이 속성으로 열린 파일이 존재하는 디렉토리는 삭제할 수 없다)

@mattn 다음 사이의 균형을 설명할 수 있습니까?

• golang.org/x/sys에 완전히 새로운 기능 추가
• OpenFile()에 대한 새 플래그(이미 정의됨!)를 지원합니다. [1]

왜 우리가 두 번째 대신 첫 번째를 선호해야 하는지 이해가 되지 않습니다.

[1] 여기에서 os.OpenFile()의 동작을 변경한다고 가정했지만 문제가 Open()을 호출한다는 것을 방금 깨달았습니다.

우선 syscall 패키지는 이미 잠겨 있습니다. 그래서 syscall 패키지를 변경하지 않고 이 문제를 해결할 방법을 찾고 있습니다.

BTW, 나는 # 25965가 이 문제와 관련이 없다고 생각합니다. 아마도 Windows의 한계일 것입니다.

(어쨌든 이 속성으로 열린 파일이 존재하는 디렉토리는 삭제할 수 없다)

@mattn 그것은 완전히 사실이 아닙니다. FILE_SHARE_DELETE 플래그를 사용하면 해당 파일을 다른 폴더로 이동하여 원본 파일을 제거할 수 있습니다. 다음은 이에 대한 간단한 PowerShell 예입니다.

# Create folder and open new file with FILE_SHARE_DELETE flag
New-Item -Type Directory -Path C:\folder1
$file = [System.IO.File]::Open("C:\folder1\test.txt", "Create", "ReadWrite", "Delete")

# Create temp folder and move all open files to there
New-Item -Type Directory -Path C:\folder1-removing
Get-ChildItem -Path C:\folder1 -Recurse | Move-Item -Destination C:\folder1-removing\

# Remove original folder
Remove-Item -Path C:\folder1

# Trigger removal for files on temp folder (NOTE! Those will exist on disk until they are closed).
Get-ChildItem -Path C:\folder1-removing -File -Recurse | Remove-Item -Force

# Close file and remove temp folder
$file.Close()
Remove-Item -Path C:\folder1-removing

우선 syscall 패키지는 이미 잠겨 있습니다. 그래서 syscall 패키지를 변경하지 않고 이 문제를 해결할 방법을 찾고 있습니다.

@mattn API가 고정되는 문제일 뿐이라면 위에서 언급한 / 데모 에서 syscall.Open syscall.FILE_SHARE_DELETE 를 이해하도록 조정하면 API를 변경하지 않고 문제를 해결할 수 있습니다.

구현이 중단된 경우 golang.org/x/sys/windows 의 Open 함수를 변경한 다음 internal/syscall 패키지에 공급할 수 있습니다. file_windows.go 코드는 이미 internal/syscall 함수를 사용하고 있습니다. 유일한 불일치는 syscall.Open 가 이 플래그를 이해하지 못하지만 낮은 수준의 Windows API 기능에 액세스하려는 대부분의 사람들은 어쨌든 golang.org/x/sys/windows 사용하고 있으며 아마도 CreateFile 사용하고 있을 것입니다 Open CreateFile 대신 Open .

syscall 패키지 "잠금"을 시작한 제안은 다음과 같이 설명합니다.
_코어 저장소는 go.sys 패키지에 의존하지 않습니다_

따라서 x/sys를 변경하는 것은 os.OpenFile() 호출자에게 도움이 되지 않습니다. 그러나 internal/syscall은 Open()을 추가할 수 있으며 os.OpenFile()은 이를 호출합니다.

@maruel , Docker 프로젝트 및 아마도 다른 많은 사람들은 열린 파일의 os.Rename() 및 .Remove()에 대한 Unix 동작을 가정했습니다. 패키지 "os"가 Windows 관련 동작을 언급하지 않았지만 아직 __15개의 언급__이 있기 때문입니다. 다른 Windows 동작.

핵심 리포지토리는 go.sys 패키지에 의존하지 않습니다.
그러나 internal/syscall은 Open()을 추가할 수 있으며 os.OpenFile()은 이를 호출합니다.

@networkimprov 자 , internal/syscall 가 golang.org/x/sys 의 공급업체 하위 집합이라는 잘못된 인상을 받았지만 어느 쪽이든 그것이 올바른 전략이라고 생각합니다( internal/syscall/windows.Open ). 물론 이것은 syscall.Open 의 동작이 정지로 인해 변경되지 않는다는 가정하에 있습니다. 이상적으로는 golang.org/x/sys/windows.Open 해당 변경으로 잠재적으로 직접 수정될 수 있습니다.

syscall 패키지가 고정되어 있지만 버그를 수정하거나 심각한 결함을 해결하기 위해 변경할 수 있습니다. 특히 os 패키지를 더 잘 지원하도록 변경할 수 있습니다.

그러나 사람들이 syscall.Open 직접 호출하는 경우 syscall 패키지가 아니라 x/sys/windows 패키지를 사용해야 합니다.

그러나 사람들이 syscall.Open 직접 호출하는 경우 syscall 패키지가 아니라 x/sys/windows 패키지를 사용해야 합니다.

syscall.Open 직접 호출하려는 사람은 아무도 없는 것 같습니다. os.OpenFile 기초가 되기 때문에 토론의 대상일 뿐입니다( syscall.Open 에 FILE_SHARE_DELETE 에 대한 지원 추가 syscall.Open 는 os.OpenFile 와 함께 플래그 사용에 대한 지원을 추가합니다.

감사 해요. os 패키지에 대한 변경 사항을 지원하도록 syscall 패키지를 변경하는 것은 괜찮습니다.

@ianlancetaylor 와 @

• os.OpenFile()이 FILE_SHARE_DELETE(그리고 결국 잠재적인 후속 조치로 FILE_FLAG_DELETE_ON_CLOSE)를 허용하도록 명시적인 의도 로 syscall.Open()을 수정합니다.
• 새로운 Windows 전용 플래그를 설명하기 위해 os.OpenFile() 문서를 업데이트하십시오.
• os.OpenFile(), os.Rename() 및 os.Remove() 문서를 업데이트하여 POSIX와 Windows 간의 동작 차이를 명확히 하십시오.

세 번째 요점은 @networkimprov 문제를 해결하는 되지만 이러한 경우가 더 많은 문서를 보증할 만큼 충분히 미묘하다는 데

승인이 된다면 기꺼이 기여하겠습니다.

이렇게 하면 분명히 Windows 고유의 이름을 가진 호출별 플래그가 남게 됩니다.

새로운 os.Open 플래그를 제안하시겠습니까? 그런 다음 플래그는 모든 OS에서 지원되어야 합니다. 즉, OS 패키지의 요점은 OS 독립적이어야 합니다. 그렇다면 해당 플래그의 의미는 무엇입니까? 그리고 플래그가 문서화된 대로 작동하는지 확인하는 몇 가지 새로운 테스트가 필요합니다.

syscall 패키지를 사용하여 필요한 코드를 작성할 수 없는 이유를 모르겠습니다. 귀하의 코드가 다른 Windows 프로그램과 잘 공존할 것이라고 생각하지 않습니다. 그리고 특별한 상황에서는 괜찮을 수도 있습니다. 그러나 나는 사람들이 이 기능을 가볍게 사용하는 것을 원하지 않습니다. 따라서 표준 라이브러리의 일부가 되어서는 안 됩니다.

알렉스

@alexbrainman
이것을 봐주세요

@alexbrainman
이것을 봐주세요

나는 보았다. 제안한 모든 변경 사항이 다른 OS에서 어떻게 작동하는지 아직 알 수 없습니까? 제안된 변경 사항을 구현하려면 어떤 테스트를 거쳐야 합니까?

알렉스

이것을 인용

DELETE_WHEN_FREED는 env의 경우 0이 될 수도 있습니다. 창 이외의

따라서 다른 OS에서 테스트할 필요가 없으며 다음을 호출합니다.
fd, 오류 := os.OpenFile(경로, os.O_RDWR|os.O_CREATE|os.DELETE_WHEN_FREED, 0600)
Windows에서 const를 4 로 변환합니다.
fd, 오류 := os.OpenFile(경로, os.O_RDWR|os.O_CREATE| 4 , 0600)
다른 사람들 ( 0 )
fd, 오류 := os.OpenFile(경로, os.O_RDWR|os.O_CREATE| 0 , 0600)

다른 OS에서 테스트할 사항 없음

Windows에서만 사용할 수 있는 새로운 os 패키지 const 또는 변수를 추가하는 방법을 모르겠습니다.

c:\>go doc os
package os // import "os"

Package os provides a platform-independent interface to operating system
functionality. 
...
The os interface is intended to be uniform across all operating systems.
Features not generally available appear in the system-specific package
syscall.

알렉스

Alex 귀하의 이의 제기에 대한 답변은 https://github.com/golang/go/issues/32088#issuecomment -494157514에 처음 언급되었습니다.

시험은 사소하다

_, err := os.OpenFile(path, os.O_CREATE | syscall.FILE_SHARE_DELETE, 0);
err = os.Rename(path, path+"2")

누군가가 패치를 제출할 수 있는 시점에 왔습니다. @ianlancetaylor 가 수락할 것이라고 생각합니다.

#32188의 일부로 FILE_SHARE_DELETE 설정을 조사했지만 설정해도 os.Rename 및 io.ReadFile 호출의 오류 비율이 경험적으로 감소하지 않는다는 것을 발견했습니다. 어쨌든 재시도 루프는 여전히 필요했습니다.

나는 그 의미를 스스로 이해하지 못하기 때문에 이 플래그를 설정하는 것과 상당한 차이를 보이는 테스트를 보고 싶습니다.

몇 년 전에 FILE_SHARE_DELETE를 실험했는데 제대로 작동했습니다.
다르게.
내 Windows 환경을 다시 시작할 수 있습니다. 도움이 된다면 찾아보고,
그러나 그것은 ~Go 1.3 정도일 것입니다.

2019년 6월 10일 월요일, 17:44, Bryan C. Mills [email protected]
썼다:

#32188의 일부로 FILE_SHARE_DELETE 설정을 조사했습니다.
https://github.com/golang/go/issues/32188 , 하지만 설정을 찾았습니다.
os.Rename 및
io.ReadFile 호출; 어쨌든 재시도 루프는 여전히 필요했습니다.

나는 중요한
이 플래그를 설정하는 것과 눈에 띄는 차이점은
그 의미를 스스로 이해하십시오.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/golang/go/issues/32088?email_source=notifications&email_token=ABNEY4VVIVJ2IEWQPWCWBZTPZZSETA5CNFSM4HNPNYIKYY3PNVWYWK3TUL52HS4DFVREXG43VMVBW63LDNCGX
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/ABNEY4STTW7U526HPO6TUHDPZZSETANCNFSM4HNPNYIA
.

@bcmills , #32188 읽기 이름을 바꾸는 동안 _열리지 않은_ 파일의 os.Rename()에서 오류가 발생했다고 알고 있습니까? 모든 디렉터리 변경 작업에 대해 작성된 NTFS 저널을 능가하여 오류를 유발할 수 있다고 생각합니다. 하지만 어떤 오류가 있을지 모르겠습니다.

syscall.Open()에서 FILE_SHARE_DELETE를 활성화하기 위한 요청은 열린 파일에서 os.Rename()이 작동하도록 허용하는 것입니다. Win7에서 1.12로 해당 플래그를 테스트했는데 작동합니다. 그리고 그것 없이는 실패합니다.

나는 "로드 중" 창에서 os.Rename()을 특별히 테스트하지 않았지만 fsd를 활성화한 이후 열린 파일에서 os.Rename()에서 예기치 않은 오류를 보지 못했습니다. 그렇게 하면 보고하겠습니다.

이름을 바꾸는 동안 열리지 않은 파일의 os.Rename()에서 오류가 발생한 것으로 알고 있습니다.

예.

어떤 오류가 있을지 모르겠습니다.

경험적으로 내가 보고 있는 오류(from MoveFileEx , ReplaceFile 및/또는 CreateFile )는 ERROR_ACCESS_DENIED , ERROR_SHARING_VIOLATION , 및 ERROR_FILE_NOT_FOUND .

syscall.Open()에서 FILE_SHARE_DELETE를 활성화하기 위한 요청은 열린 파일에서 os.Rename()이 작동하도록 허용하는 것입니다. Win7에서 1.12로 해당 플래그를 테스트했는데 작동합니다. 그리고 그것 없이는 실패합니다.

오른쪽; 내가 해결하기 위해 노력하고있어 관련 문제에 대한 동시 통화가 가능하도록되어 os.Rename 성공하고, 호출 할 수 있도록 io.ReadFile 와 동시 os.Rename 성공하기를. 기존 핸들을 연 상태로 작업하기 위해 단일 os.Rename 를 얻는 것은 올바른 방향으로 가는 단계일 수 있지만 POSIX rename 를 사용하는 유형의 사용 사례에는 충분하지 않다고 생각합니다.

나는 그 의미를 스스로 이해하지 못하기 때문에 이 플래그를 설정하는 것과 상당한 차이를 보이는 테스트를 보고 싶습니다.

@bcmills PowerShell 예제는 Go보다 훨씬 빠르게 작성합니다.

New-Item -Type Directory -Path C:\folder1
for($i=0; $i -le 1000; $i++)
{
    $temp = [System.IO.File]::Open("C:\folder1\test.txt", "Create", "ReadWrite", "Delete")
    Set-Variable -Name "file$i" -Value $temp -Force
    $TempName = "C:\folder1\test.txt." + (New-Guid).Guid
    Rename-Item -Path C:\folder1\test.txt -NewName $TempName
    Remove-Item -Path $TempName -Force
}

완료되면 C:\folder1 아래에 천 개의 test.txt.??? 파일이 있지만 PowerShell을 닫으면 해당 파일이 제거됩니다.

따라서 FILE_SHARE_DELETE 플래그가 실제로 열려 있는 파일의 이름을 바꾸거나/이동/제거할 수 있도록 하지만 핸들이 열려 있는 한 디스크에 존재하기 때문에 대상 파일 이름이 고유한지 확인해야 합니다.

"POSIX 이름 바꾸기 사용"은 Windows에서 불가능하며 아마도 이것이 오류가 발생하는 이유일 것입니다.

포식스 :

파일 "filename" 생성
"파일 이름"에서 읽기/쓰기
"파일 이름" 삭제

파일 "filename" 생성
...
"파일 이름" 삭제

각 생성 파일에 diff fd가 있으므로 작동합니다.

윈도우:
파일 "filename" 생성
"파일 이름"에서 읽기/쓰기
"파일 이름" 삭제

파일 "filename" 생성 - 붐, 공유 위반

재구성하기가 매우 쉬워야합니다 ...

그러면 FILE_SHARE_DELETE는 무엇을 할 수 있습니까?
파일이 열려 있는 동안 지연된 삭제를 허용합니다.

그게 다야

2019년 6월 10일 월요일, 19:32, Olli Janatuinen [email protected]
썼다:

나는 중요한
이 플래그를 설정하는 것과 눈에 띄는 차이점은
그 의미를 스스로 이해하십시오.

@bcmills https://github.com/bcmills 내가 쓰는 PowerShell 예제
Go보다 훨씬 빠름

새 항목 유형 디렉토리 -경로 C:folder1for($i=0; $i -le 1000; $i++)
{
$temp = [System.IO.File]::Open("C:folder1test.txt", "만들기", "읽기 쓰기", "삭제")
변수 설정 - 이름 "file$i" -값 $temp -Force
$TempName = "C:folder1test.txt." + (New-Guid).Guid
항목 이름 바꾸기 - 경로 C:folder1test.txt -NewName $TempName
항목 제거 - 경로 $TempName -Force
}

완료되면 천 개의 test.txt가 있을 것입니다.??? 아래의 파일
C:folder1이지만 PowerShell을 닫으면 해당 파일이 제거됩니다.

따라서 실제로 어떤 FILE_SHARE_DELETE 플래그가 허용합니까?
열려 있는 파일의 이름을 바꾸거나/이동/제거하지만 여전히 대상이
파일 이름은 핸들이 있는 한 디스크에 존재하므로 고유합니다.
열려있습니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/golang/go/issues/32088?email_source=notifications&email_token=ABNEY4WSTWIUVNVHLYMBFY3PZZ62DA5CNFSM4HNPNYIKYY3PNVWWK3TUL52HS4DFVREXG43VMXVW63LDNMV
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/ABNEY4VS5XF3EXB6QPBWVQ3PZZ62DANCNFSM4HNPNYIA
.

성공하려면 os.Rename과 동시에 io.ReadFile에 대한 호출을 허용합니다.

@bcmills 관련 없는 파일에서 동일한 시퀀스를 시도하는 다른 스레드와 동시에 실행되지 않는다는 가정 하에 항상 fsd 플래그 세트로 작업해야 한다고 생각합니다. 그리고 일반적으로 플래그 없이는 실패해야 합니다.

테스트 스크립트의 해당 측면은 Windows syscall.Open()에서 버그를 올바르게 발견했습니다. 하지만 이 스레드에 댓글을 달고 있는 사람은 아무도 수정을 원하지 않습니다.

TLDR:
syscal_windows.go에 대한 사소한 안전 변경 및 예상대로 작동합니다.

설명:
그래서, 여기 내가 한 일이 있고, 예상대로 작동하며, 위험이 없습니다(IMO).

1. 조정 syscal_windows.go

func Open(path string, mode int, perm uint32) (fd Handle, err error) {

sharemode := uint32(FILE_SHARE_READ | FILE_SHARE_WRITE | (mode & FILE_SHARE_DELETE))

추가: "| (모드 & FILE_SHARE_DELETE)"
개발자가 모드 및 4 세트를 보내지 않는 경우(왜 그는 이전에는 작동하지 않았는지...) - 아무 것도 변경되지 않았으므로 다음과 같은 코드

os.OpenFile(filename,os.O_RDWR|os.O_CREATE, 0600)

변경 전과 동일하게 작동하며, 다음을 수행하는 개발자만

os.OpenFile(filename,os.O_RDWR|os.O_CREATE  | 4 , 0600)

변화를 "느낄" 것입니다

1. 코드를 실행

package main

import (
    "fmt"
    "os"
)

func main() {
    filename := "./myfile"
    if f ,err := os.OpenFile(filename,os.O_RDWR|os.O_CREATE|4, 0600);err!=nil{
        fmt.Printf("Open file %s error : %s" , filename, err.Error())
    } else if _,err:= f.WriteString("bla bla") ;err!=nil{
        fmt.Printf("writing to %s returned error : %s" , filename, err.Error())
    } else if err := os.Remove(filename);err!=nil{
        fmt.Printf("removing %s returned error : %s" , filename, err.Error())
    }
}

그리고 그것은 효과가 있었다

1. |4 없이 코드를 실행했지만 실패했습니다.
2. 약간의 추가로 코드를 실행했습니다.

package main

import (
    "fmt"
    "os"
)

func main() {
    filename := "./myfile"
    if f ,err := os.OpenFile(filename,os.O_RDWR|os.O_CREATE|4, 0600);err!=nil{
        fmt.Printf("Open file %s error : %s" , filename, err.Error())
    } else if _,err:= f.WriteString("bla bla") ;err!=nil{
        fmt.Printf("writing to %s returned error : %s" , filename, err.Error())
    } else if err := os.Remove(filename);err!=nil{
        fmt.Printf("removing %s returned error : %s" , filename, err.Error())
    } else if secondF ,err := os.OpenFile(filename,os.O_RDWR|os.O_CREATE|4, 0600);err!=nil{
        fmt.Printf("reOpen file %s error : %s" , filename, err.Error())
    } else {
        secondF.Close()
    }
}

물론 두 번째 F에서 실패했습니다.
그러나 그것은 Windows에서 예상되는 동작입니다. "로드 테스트"할 필요가 없습니다. 지연된 .Remove에는 동시성 옵션이 없습니다. 따라서 기존 코드를 손상시키지 않고 이 절반 줄 을 syscal_windows에 안전하게 추가할 수 있다고 생각 합니다. 삭제를 연기할 수

우리가 해야 할 모든 것(굵은 글씨):
syscal_windows.go:
공유 모드 := uint32(FILE_SHARE_READ | FILE_SHARE_WRITE | (모드 및 FILE_SHARE_DELETE) )

#32188의 일부로 FILE_SHARE_DELETE 설정을 조사했지만 설정해도 os.Rename 및 io.ReadFile 호출의 오류 비율이 경험적으로 감소하지 않는다는 것을 발견했습니다. 어쨌든 재시도 루프는 여전히 필요했습니다.

나는 그 의미를 스스로 이해하지 못하기 때문에 이 플래그를 설정하는 것과 상당한 차이를 보이는 테스트를 보고 싶습니다.

@bcmills는 이제 https://github.com/olljanat/go/commit/3828f1a5d0ebb69b4c459d5243799ded36ac1ee8 에서 이에 대한 단위/회귀 테스트를 찾을 수 있습니다. 현재 Windows에서 The process cannot access the file because it is being used by another process. 오류에 실패하고 FILE_SHARE_DELETE 이후에 작업을 시작합니다

메모! Windows에서 여전히 이동 로그인 해당 단계 필요 example.log.1 다른 이유 이름을 변경하기 때문에 임의 / 고유 한 이름으로 파일을 example.log 에 example.log.1 에 실패 Access is denied. 오류 FILE_SHARE_DELETE 플래그가 활성화된 경우에도 마찬가지입니다. 이는 개발자가 처리해야 하는 플랫폼별 사항입니다.

/cc @jhowardmsft @jterry75 @jstarks @ddebroy 참고로; 당신도 이것에 관심이 있을 수 있습니다.

@kevpar- 참고로 당신도 이 문제를 해결하기 위해 노력하고 있기 때문입니다.

스레드에 참여하는 사람들이 os.OpenFile()에서 Windows 전용 플래그를 통해 사용할 수 있는 것과 비교하여 이를 기본값으로 설정해야 하는 이유(예: 기존 코드가 손상됨)를 말할 수 있는 경우 파이프 업하십시오!

@networkimprov IMO 개발자는 내 로그 회전 예제와 같이 다른 Windows 관련 사항도 처리해야 하기 때문에 Windows 전용 플래그로 처리해야 합니다.

그러나 내가 볼 수 있듯이 두 명의 Microsoft 직원이 토론에 초대되었으므로 그들이 이것을 다르게 생각하는지 보는 것은 흥미로울 것입니다.

btw가 이에 대한 새로운 솔루션을 개발하기 시작한 사람이 있습니까? 자원 봉사자가 있습니까?

@oljanat
플래그로 수정하는 경우 수정 사항은 하나의 라이너입니다. 다음을 읽으십시오.
https://github.com/golang/go/issues/32088#issuecomment -500562223

여기에서 Windows 팀의 관점을 표현하려고 합니다. 옵션 없이 항상 FILE_SHARE_DELETE를 설정하는 것이 좋습니다. 일반적으로 Windows로/에서 쉽게 포팅할 수 있도록 Linux와의 일관된 동작을 선호하며 Windows 사용자 또는 소프트웨어가 규칙의 예외가 되기에 충분한 기본 !FILE_SHARE_DELETE 동작을 선호하는 이유를 모르겠습니다.

@mattn 의 의견과 달리 흥미로운 참고 사항: 최신 버전의 Windows에서는 "POSIX" 삭제를 수행하도록 DeleteFile(NTFS에서)을 업데이트했습니다. 닫을 파일에 대한 핸들입니다. 여전히 FILE_SHARE_DELETE를 존중하지만 이제 POSIX 연결 해제와 같이 작동합니다. 이 기능은 WSL용으로 추가되었으며 Windows 소프트웨어에서도 기본적으로 사용할 가치가 있는 것으로 간주되었습니다.

즉, 최신 버전의 Windows에서 mattn의 테스트 프로그램과 del, dir 등의 시퀀스를 실행하면 테스트 프로그램이 종료된 직후가 아니라 파일 삭제 직후 네임스페이스에서 파일이 사라지는 것을 볼 수 있습니다. 마치 리눅스처럼.

따라서 Windows 자체에서도 앱 호환성 위험이 훨씬 더 크지만 Windows가 아닌 소프트웨어를 Windows로 쉽게 이식할 수 있도록 약간의 변경을 가하고 있습니다. 나는 Go가 그렇게 하도록 정말로 격려한다.

@jstarks , 저를

Windows 배포가 현재 문서화되지 않은 동작에 의존하는 경우 fsd를 비활성화하는 전역 옵션을 제안합니다.

@ianlancetaylor 동의하십니까?

CreateFile의 기본 동작은 여는 파일을 삭제할 수 없다는 것이므로 기본 동작을 유지해야 한다고 생각합니다. 누군가는 원래의 행동을 원할 수 있습니다. 예를 들어, 파일을 삭제할 수 없는 방법을 사용하여 응용 프로그램이 작동하는지 확인하는 프로그래머가 있을 수 있습니다.

Python의 동작은 현재 Go의 동작과 동일합니다. 그리고 파이썬이 열린 파일을 삭제할 수 없는 동작을 변경할 계획이 있다는 소식을 들어본 적이 없습니다.

이 문제에 대해 진지한 의견을 낼 시간은 없었지만 글로벌 옵션이 좋은 선택이라고는 생각하지 않습니다. 우리는 현재 동작을 유지해야 하거나(아마도 다른 동작을 선택하기 위해 플래그를 추가해야 함) 동작을 변경해야 합니다(아마도 원래의 현재 동작을 선택하기 위해 플래그를 추가해야 함).

기본 동작을 변경할지 여부와 관련하여 우리는 동작을 변경하면 Unix 및 Windows 시스템에서 실행되도록 작성된 Go 프로그램이 수정될 가능성이 더 높은지 또는 동작을 변경할 가능성이 더 높은지 질문해야 한다고 생각합니다. Windows 시스템에서 실행되도록 작성된 Go 프로그램이 중단됩니다. 나는 그것에 대한 답을 모른다.

@mattn이 제안한 것처럼 다른 언어가 무엇을 하는지 묻는 것도 가치가 있습니다.

이것이 기본값이 되고 모든 Windows 배포가 이에 의존한다면 os.OpenFile() 플래그와 과도기를 위해 다시 전환하는 전역 옵션을 모두 원할 것이라고 생각합니다.

마지막으로 확인한 IPv6을 비활성화하는 전역 옵션이 있습니다.

영향을 발견하는 한 가지 방법은 팁에 변경하고(블로그에 발표?) 보고된 내용을 확인하는 것입니다.

문제 텍스트에는 Python과 Erlang이 모두 언급되어 있습니다.
Erlang은 6년 전에 이를 기본값으로 설정했습니다: erlang/ otp@0e02f48
Python은 MSVC 런타임의 제한으로 인해 원했지만 할 수 없었습니다. https://bugs.python.org/issue15244

여기에서 Windows 팀의 관점을 표현하려고 합니다. 옵션 없이 항상 FILE_SHARE_DELETE를 설정하는 것이 좋습니다. 일반적으로 Windows로/에서 쉽게 포팅할 수 있도록 Linux와의 일관된 동작을 선호하며 Windows 사용자 또는 소프트웨어가 규칙의 예외가 되기에 충분한 기본 !FILE_SHARE_DELETE 동작을 선호하는 이유를 모르겠습니다.

최신 버전의 Windows에서는 "POSIX" 삭제를 수행하도록 DeleteFile(NTFS에서)을 업데이트했습니다. 여기서 파일에 대한 열려 있는 모든 핸들이 닫힐 때까지 기다리지 않고 파일이 네임스페이스에서 즉시 제거됩니다. 여전히 FILE_SHARE_DELETE를 존중하지만 이제 POSIX 연결 해제와 같이 작동합니다. 이 기능은 WSL용으로 추가되었으며 Windows 소프트웨어에서도 기본적으로 사용할 가치가 있는 것으로 간주되었습니다.

@jstarks 매우 흥미로운 세부 사항입니다. Microsoft가 이전 OS 버전으로도 백포팅할 것으로 예상할 수 있습니까? 특히 최근에 출시된 LTSC 버전인 Windows Server 2019는 앞으로도 오랫동안 지원될 것이라고 생각합니다.

Microsoft가 그렇게 하는 것처럼 Go에서도 기본적으로 FILE_SHARE_DELETE를 활성화하는 것을 선호합니다.

Java, C# 및 내가 알고 있는 다른 모든 주요 언어는 기본 OS 동작을 사용합니다. 제 생각에는 기본 동작은 OS 구현자에게 맡겨야 합니다. Windows가 파일 열기와 관련하여 POSIX 접근 방식을 실제로 사용하려는 경우 해당 위험을 감수하고 DeleteFile에 대해 수행한 것처럼 수행해야 합니다.

Go 라이브러리에서 공유 삭제 파일을 생성/열 수 있어야 한다고 생각합니다. 파일 모드를 다룰 때 실용적인 예를 하나 들 수 있습니다. Hadoop을 Windows로 이식할 때 공유 삭제 파일 핸들 또는 스트림을 가져오기 위해 JNI에서 특별한 메서드를 만들기 위해 추가 노력을 기울여야 합니다.

https://github.com/apache/hadoop/search?q=getShareDeleteFileInputStream&unscoped_q=getShareDeleteFileInputStream

@jstarks

말할 때

최신 버전의 Windows에서는 파일이 네임스페이스에서 즉시 제거되는 "POSIX" 삭제를 수행하도록 DeleteFile(NTFS에서)을 업데이트했습니다.

열린 파일이 fd 및 아래 코드로만 유지된다는 것을 의미합니까?

package main

import (
    "fmt"
    "os"
)

func main() {
    filename := "./myfile"
    if f ,err := os.OpenFile(filename,os.O_RDWR|os.O_CREATE|4, 0600);err!=nil{
        fmt.Printf("Open file %s error : %s" , filename, err.Error())
    } else if _,err:= f.WriteString("bla bla") ;err!=nil{
        fmt.Printf("writing to %s returned error : %s" , filename, err.Error())
    } else if err := os.Remove(filename);err!=nil{
        fmt.Printf("removing %s returned error : %s" , filename, err.Error())
    } else if secondF ,err := os.OpenFile(filename,os.O_RDWR|os.O_CREATE|4, 0600);err!=nil{
        fmt.Printf("reOpen file %s error : %s" , filename, err.Error())
    } else {
        secondF.Close()
    }
}

실패하지 않을 것입니다

} else if secondF ,err := os.OpenFile(filename,os.O_RDWR|os.O_CREATE|4, 0600);err!=nil{

제안된 수정 사항 을 적용한 후?

그렇다면 정말 멋지군요!

기본 동작을 변경할지 여부와 관련하여 우리는 동작을 변경하면 Unix 및 Windows 시스템에서 실행되도록 작성된 Go 프로그램이 수정될 가능성이 더 높은지 또는 동작을 변경할 가능성이 더 높은지 질문해야 한다고 생각합니다. Windows 시스템에서 실행되도록 작성된 Go 프로그램이 중단됩니다. 나는 그것에 대한 답을 모른다.

Windows에서 Unix 프로그램을 실행하는 problem to be fixed 는 없습니다. Windows는 Unix와 다르게 열린 파일의 삭제를 처리합니다. 파일 이름의 대소문자 구분과 유사합니다. Unix는 대소문자를 구분하고 Windows는 대소문자를 구분하지 않습니다. 두 가지 차이점에 대해 우리가 할 수 있는 일은 없습니다.

그리고 John이 Microsoft가 상황을 바꾸려고 한다고 확신하는 동안 저는 변화가 올 때까지 기다릴 것입니다. 그리고 많은 Windows 사용자는 여전히 Windows 7 및 기타 모든 Windows 버전을 사용합니다. John도 Windows 7을 업데이트하시겠습니까?

Microsoft가 변경 사항을 처리하도록 해야 한다고 생각합니다. Go 사용자를 수정해도 Go가 아닌 개발자는 계속 남게 됩니다. 따라서 Microsoft는 이에 관계없이 이 문제를 처리해야 합니다.

또한 FILE_SHARE_DELETE에는 자체 바이올린이 있습니다. 예를 들어 https://bugs.python.org/issue15244 읽기

실제로 Unix와 의미가 완전히 같지는 않습니다.

파일을 삭제한 후에는 핸들이 닫힐 때까지 동일한 이름의 파일을 생성하거나 파일이 포함된 디렉토리를 삭제할 수 없습니다.

그러나 파일을 삭제하기 전에 루트 디렉토리와 같은 다른 위치로 파일을 이동하여 이 문제를 해결할 수 있습니다.

아마 우리가 알지 못하는 그런 사람들이 많이 있을 것입니다. FILE_SHARE_DELETE를 전혀 사용하지 않았습니다. 기본적으로 FILE_SHARE_DELETE를 사용하도록 Go 라이브러리를 변경한 다음 사용자가 깨진 프로그램에 대해 불평할 때까지 기다릴 것을 제안하시겠습니까?

@mattn이 제안한 것처럼 다른 언어가 무엇을 하는지 묻는 것도 가치가 있습니다.

Mingw C만 확인했습니다. Go처럼 작동합니다. fopen으로 파일을 열면 fclose가 호출될 때까지 파일을 삭제할 수 없습니다. Microsoft 개발 도구(C, C++, C#, VB 등)가 서로 다르다면 놀랄 것입니다.

그리고 우리가 어떻게 그런 기본 동작을 변경할 수 있는지 모르겠습니다. 일부 프로그램에는 특정 파일이 열려 있을 수 있으므로 다른 프로그램에서 삭제할 수 없습니다. 내 생각에는 Windows에서 유효한 접근 방식입니다. 앞으로 지원해야 합니다.

알렉스

7년 전에 추가된 내용은 다음과 같습니다.
https://sourceforge.net/p/mingw-w64/code/HEAD/tree/stable/v3.x/mingw-w64-headers/include/ntdef.h#l858

지금까지 문서화되지 않은 현재 Windows 동작에 의존하는 Go 앱 사례를 게시한 사람은 없습니다. 하지만 그로 인해 Windows에서 실패한 Go 앱의 경우를 최소 4건 이상 들었습니다.

위에서 언급했듯이 os.Remove() 이후에 파일 이름 재사용에 대한 간단한 수정 사항이 있으며 이를 문서화해야 합니다.
os.Rename(path, unique_path); os.Remove(unique_path)

지금까지 문서화되지 않은 현재 Windows 동작에 의존하는 Go 앱 사례를 게시한 사람은 없습니다.

이 사람들은 Go 버그를 보고하는 것이 가능하다는 사실조차 모릅니다.

이러한 사용자가 변경 사항이 있는지 문제 목록을 모니터링하여 영향을 줄 것이라고 기대해서는 안 됩니다. 그들에게는 살 삶이 있습니다. 그들이 사용하는 도구를 부수지 않는 것은 우리에게 달려 있습니다.

알렉스

알렉스, 당신이 설득력이 없는 것이 분명합니다. 그런 다음 사람들이 Go에서 이식 가능한 코드를 작성할 수 있도록 앞으로 두 가지 가능한 경로가 표시됩니다.

1. Open 대한 새로운 옵트인 플래그는 Windows의 경우 FILE_SHARE_DELETE 를 의미하고 다른 OS에서는 무시됩니다. 그런 다음 POSIX 의미 체계를 기대하는 코드를 작성하는 모든 사람이 이 플래그를 모든 곳에서 전달할 것을 권장합니다. 또는,
2. CreateFile을 FILE_SHARE_DELETE로 래핑하지만 그렇지 않으면 os.Open 처럼 작동하는 Open 라는 하나의 함수가 있는 새로운 Go 패키지 posix (어딘가의 일부 리포지토리에 있음). Windows가 아닌 플랫폼에서는 os.Open 직접 호출합니다. 우리는 그 다음 사용하는 POSIX 의미를 기대하는 사람의 코드를 작성하는 것이 좋습니다 것입니다 posix.Open 대신 os.Open 사방.

이 두 가지 접근 방식 모두 Linux 개발자는 Windows에서 POSIX 동작을 유지하기 위해 추가 조치를 취해야 하지만, 적어도 이것은 일회성 CreateFile 래퍼를 작성하는 것보다 낫습니다.

알렉스, 당신이 설득력이 없는 것이 분명합니다.

나는 설득되지 않는다. 하지만 나를 설득할 필요는 없고, 바둑팀을 설득해야 한다. 그들은 결정을 내릴 것입니다.

1. Open 대한 새로운 옵트인 플래그는 Windows의 경우 FILE_SHARE_DELETE 를 의미하고 다른 OS에서는 무시됩니다. 그런 다음 POSIX 의미 체계를 기대하는 코드를 작성하는 모든 사람이 이 플래그를 모든 곳에서 전달할 것을 권장합니다. 또는,

이 옵션도 마음에 들지 않습니다.

먼저 os 패키지는 모든 OS에서 사용할 수 있는 기능을 제공해야 합니다. 특정 OS는 syscall, golang.org/x/sys/windows, 또는 우리가 좋아하는 다른 패키지로 이동해야 합니다.

둘째, 내가 원하지 않더라도 내 프로그램에서 FILE_SHARE_DELETE 파일 형식으로 끝날까봐 걱정됩니다. FILE_SHARE_DELETE 파일 모드를 사용하기로 결정한 외부 패키지를 가져오는 경우를 상상해 보십시오. 내 코드 중 일부가 FILE_SHARE_DELETE 사용한다는 것을 어떻게 알 수 있습니까? 패키지 소스 코드를 grep해야합니다. 또는 패키지 문서는 사용자에게 경고해야 합니다. 일부 패키지 작성자가 FILE_SHARE_DELETE 와 함께 syscall.CreateFile을 직접 사용하는 경우에도 발생할 수 있다고 생각합니다. 하지만 FILE_SHARE_DELETE 가 os 패키지에 축복이 된다면 이게 더 일반적일 거라고 생각합니다. Windows에 대해 아무것도 모르는 Linux 사용자는 기본적으로 이 플래그를 사용하여 Linux 프로그램을 Windows로 "더 쉽게" 포트할 수 있을 것입니다.

셋째, FILE_SHARE_DELETE 플래그를 문서화해야 합니다. 우리는 POSIX라고 말할 수 없습니다. 플래그가 하는 일을 설명해야 합니다. 간단한 단어로. 또한 기억하십시오:

실제로 Unix와 의미가 완전히 같지는 않습니다.

파일을 삭제한 후에는 핸들이 닫힐 때까지 동일한 이름의 파일을 생성하거나 파일이 포함된 디렉토리를 삭제할 수 없습니다.

그러나 파일을 삭제하기 전에 루트 디렉토리와 같은 다른 위치로 파일을 이동하여 이 문제를 해결할 수 있습니다.

https://github.com/golang/go/issues/32088#issuecomment -504321027에서. 우리도 그것을 문서화해야 할 것입니다. 그리고 FILE_SHARE_DELETE 플래그가 제공하는 다른 모든 기능.

넷째, FILE_SHARE_DELETE 대한 새로운 테스트를 추가해야 합니다. 이러한 테스트는 무엇입니까? 일부 기능을 테스트하는 것을 잊었다가 나중에 FILE_SHARE_DELETE 플래그를 사용하여 기능을 달성할 수 없다는 것을 발견하면 어떻게 됩니까? FILE_SHARE_DELETE 플래그가 마음에 들지 않으면 제거할 수 없습니다. 한 번 들어가면 유지됩니다. 그리고 우리는 미래에 그것을 지원해야 합니다.

2. CreateFile을 FILE_SHARE_DELETE로 래핑하지만 그렇지 않으면 os.Open 로 작동하는 Open 함수가 있는 새로운 Go 패키지 posix (어느 저장소에 있음)

그게 어떻게 가능한지 모르겠다. 그러나 가능하면 패키지를 직접 만들 수 있어야 합니다. 예를 들어 github.com/jstarks/posix와 같습니다. 아니? golang.org/x/sys/windows/posix 또는 기타 항목에 패키지를 추가할 수 있지만 큰 차이는 없습니다.

알렉스

os 패키지는 모든 OS에서 사용할 수 있는 기능을 제공해야 합니다...
FILE_SHARE_DELETE 플래그를 문서화해야 합니다. 우리는 POSIX라고 말할 수 없습니다 ...
FILE_SHARE_DELETE에 대한 새 테스트를 추가해야 합니다. 이러한 테스트는 무엇입니까?

이 모든 것은 위에서 언급되었습니다.

FILE_SHARE_DELETE 파일 모드를 사용하기로 결정한 외부 패키지를 가져오는 경우. 내가 어떻게 알겠어

그것은 그것을 기본값으로 만들고 그것을 비활성화하기 위한 전역 플래그를 제공하기 위한 또 다른 인수입니다.

영향을 받는 Windows 앱을 찾기 위해 golang-nuts에 게시했습니다. 나는 그것을 계속 볼 수 있도록 며칠에 한 번씩 핑을 할 것이다. 그것이 많이 드러나지 않는다면 1.14의 기본 팁으로 설정하면 상황이 명확해질 것입니다.
https://groups.google.com/d/topic/golang-nuts/8BiP_mPoCd4/discussion

그것은 그것을 기본값으로 만들고 그것을 비활성화하기 위한 전역 플래그를 제공하기 위한 또 다른 인수입니다.

ㅋ 이 플래그는 Linux에서 무엇을 해야 합니까? 우리는 실제로 다른 프로세스에서 삭제할 수 없는 방식으로 Linux에서 파일을 여는 기능을 놓치고 있습니까? https://gavv.github.io/articles/file-locks/#open -file-description-locks-fcntl 기반으로 최신 버전의 Linux에서 구현할 수 있어야 합니다.

플래그(예: var OpenWithout_FILE_SHARE_DELETE = false )는 syscall.Open()의 동작에 영향을 미치므로 syscall_windows.go에 정의됩니다.

Linux 전용 플래그는 다른 이름을 가지며 syscall_linux.go에 정의됩니다. 나는 디렉토리에 대한 권한을 통하지 않고 Linux에서 열린 파일의 삭제를 방지하는 방법을 모릅니다. 제공한 링크는 "권고" 잠금에 대해 설명합니다.

@jstarks FILE_SHARE_DELETE 플래그 도입을 고려하기 전에 Go에서 실행 중인 실행 파일을 삭제할 수 없는 문제에 대해서도 결정해야 합니다. FILE_SHARE_DELETE 플래그가 여기에서 우리를 도울 수 있다고 생각하지 않습니다. 할 수 있습니까? 아직 실행 중인 실행 파일의 삭제를 구현할 수 없다면 POSIX 호환성을 주장할 수 없습니다. 그리고 FILE_SHARE_DELETE 플래그는 반쪽

더군다나 간혹 완료된 프로세스의 실행 파일을 삭제하지 못하는 경우도 있습니다. 자세한 내용은 예를 들어 #25965, #19491 및 #32188을 참조하십시오. 기본적으로 신호를 보낼 때까지 프로세스 핸들에서 WaitForSingleObject를 호출합니다. 그러나 실행 파일이 삭제될 수 있다는 보장은 없습니다. 파일 삭제를 시도하기 전에 5밀리초의 대기 시간을 추가해야 했습니다. 그리고 그것이 항상 작동하는 것은 아닙니다 - https://github.com/golang/go/issues/25965#issuecomment -482037476

또한 이 문제와 관련이 없지만 관심을 가져주시면 windows-arm 포트를 되살리는 데 도움이 될 수 있습니다. 자세한 내용은 #32135를 참조하십시오. 기본적으로 @jordanrh1은 Go를 windows-arm으로 이식했지만 더 이상 windows-arm 빌더가 없습니다. 그래서 우리는 포트가 여전히 작동 중인지 고장 났는지조차 모릅니다. 빌더를 실행하는 데 도움을 줄 수 있다면 Windows-am 포트를 계속 지원하려고 할 수 있습니다. 그렇지 않으면 포트가 제거될 수 있습니다. - https://github.com/golang/go/wiki/PortingPolicy 누군가가 Windows 10 Iot에서 Go 프로그램을 실행하는 데 관심이 있는지 모르겠지만 이미 이 지원을 받고 있습니다. 작업하는 빌더가 없다는 이유로 느슨해지면 슬플 것입니다.

감사합니다.

알렉스

임시 실행 파일 삭제를 위한 제안된 솔루션: https://github.com/golang/go/issues/25965#issuecomment -495636291

golang-nuts 게시물의 결과가 없습니다. 새 스레드를 시작했습니다.
https://groups.google.com/d/topic/golang-nuts/aRvSo3iKvJY/discussion

내가 조사해야 한다고 생각하는 최소한 하나의 가설적이지 않은 문제는 파일 잠금 및 이에 의존하는 프로그램에 대한 영향일 것입니다.

FILE_SHARE_DELETE 모든 파일 핸들을 여는 것은 FILE_SHARE_DELETE 지정된 파일이 제거될 수 있기 때문에 LockFileEx 의 의미를 POSIX 권고 잠금의 의미로 효과적으로 약화시킵니다. 잠금이 해제된 경우에도 해당 파일의 영역에 보관됩니다. ¹

물론 이것은 os.File.Fd 에서 반환된 설명자로 이루어진 LockFileEx 호출에만 적용되지만 가장 인기 있는 Go 파일 잠금 라이브러리 (현재 Docker 포함하여 33개의 알려진 가져오기 가 있음) 에서 수행 된 . , gVisor 및 Kubernetes). 이는 Terraform 에서도 수행되며 LockFileEx 는 다른 Go 코드 로드에 사용됩니다.

나는 여전히 이 변화가 최선의 경우(최악의 경우 CVE-factory)에서 무분별한 시도처럼 보인다고 생각합니다. 나는 불확실한 이점이 발생할 명확한 코드 손상보다 얼마나 중요한지 정말로 알지 못합니다.

나는 또한 대부분의 golang-nuts 사용자가 이 변경 사항의 의미를 완전히 이해하지 못할 것이라고 생각합니다. Go 팀의 허가가 있으면 golang-dev에 대한 게시물이 토론을 생성하는 데 더 효과적일 수 있습니다(특히 이것이 핵심 변경 사항이기 때문에). 사실, 그것은 기술적으로 이동 툴체인에 영향을 또한 사용 LockFileEx 상기 방식을 .

¹ 예, 일부 Windows 잠금 적용이 여전히 POSIX보다 더 강력하다는 것을 압니다. 그러나 파일을 핵으로 만들 수 있다면 리소스 예약을 위해 잠금 파일을 사용하는 것은 불가능합니다.

문제를 열었을 때 golang-dev에 게시했습니다.
https://groups.google.com/d/topic/golang-dev/R79TJAzsBfM/discussion

나열한 라이브러리 중 GOOS=windows 동작에 _의존_하는 라이브러리가 있습니까? 당신은 이 변경이 기존 코드를 깨뜨릴 것이라고 반복해서 주장했지만 어떠한 증거도 제공하지 않았습니다.

지지할 수 없는 선정적인 발언은 자제해 주십시오. 그것은 아무 것도 설명하지 않으며 나는 그것이 불쾌하다고 생각합니다.

문제를 열었을 때 golang-dev에 게시했습니다. https://groups.google.com/d/topic/golang-dev/R79TJAzsBfM/discussion

거기에 있는 모든 사람들이 각자의 이유로 아이디어를 포기한 것 같지만(이 스레드에서 이전에 언급한 것과 비슷함) 아이디어가 이제 Go 1.14에서 이 변경 사항을 적용하기 위해 떠돌아다니고 있다면 그에 대한 후속 조치입니다. 스레드가 유용할 수 있습니다(이 토론에 대한 미리 알림 링크 포함).

나열한 라이브러리 중 GOOS=windows 동작에 의존 하는 라이브러리가 있습니까? 당신은 이 변경이 기존 코드를 깨뜨릴 것이라고 반복해서 주장했지만 어떠한 증거도 제공하지 않았습니다.

확실히 말하려면 ( 많은 코드에 대한) 완전한 보안 평가가 필요합니다. 나는 사람들이 이 플래그의 도입으로 눈에 띄게 바뀔 행동에 의존하고 있다는 충분한 증거를 확실히 제공했다고 생각합니다. 그리고 그것은 GitHub에서 공개적으로 사용 가능한 코드일 뿐입니다.

지지할 수 없는 선정적인 발언은 자제해 주십시오. 그것은 아무 것도 설명하지 않으며 나는 그것이 불쾌하다고 생각합니다.

링크와 코드가 충분히 지원되지 않으면 귀하의 책에 무엇이 포함될지 모르겠습니다. 이 변경으로 인해 컴파일이 중지되는 코드를 찾지는 않겠지만, 확실히 다르게 동작하는 코드를 찾을 수 있으며 많은 사람들은 이러한 동작 변경으로 인해 해당 코드가 "깨진" 것으로 간주할 것입니다.

내 반대를 개인적으로 받아들이지 마십시오. 여기 있는 모든 사람(당신을 포함하여)이 언어를 개선하기 위해 의견을 추가하려고 한다고 생각합니다. 핵심 변화를 옹호하려면 건강한 저항을 기대해야 합니다.

위에서 설명했듯이 FILE_SHARE_DELETE로 파일을 삭제하는 것은 UNIX와 같은 기능이 없습니다. 예를 들어 이 단계를 시도하십시오.

메인.c

#include <windows.h>
#include <stdio.h>

int
main() {
  // ensure delete the file
  DeleteFile("test.txt");

  // create test.txt with FILE_SHARE_DELETE
  HANDLE h = CreateFile("test.txt",
      GENERIC_READ | GENERIC_WRITE,
      FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,
      NULL, OPEN_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
  puts("waiting 10sec, please run watch.exe on another cmd.exe");
  Sleep(10000);
  if (DeleteFile("test.txt")) {
    puts("deleted");
  }
  getchar();
  return 0;
}

watch.c

#include <stdio.h>
#include <shlwapi.h>

int
main() {
  // waiting test.txt will be removed.
  while (PathFileExists("test.txt")) {
    puts("watching...");
    Sleep(1000);
  }
  // now test.txt should not exists. So this is possible to create new file
  system("notepad test.txt");
  return 0;
}

메이크파일

all : main.exe watch.exe

watch.exe : watch.c
    gcc -o watch.exe watch.c -lshlwapi

main.exe : main.c
    gcc -o main.exe main.c

먼저 main.exe를 실행하고 다음으로 watch.exe를 실행하십시오. UNIX에서 unlink(2)는 즉시 파일을 제거합니다. 따라서 파일이 존재하는 것을 감시하는 다른 프로세스가 동일한 파일 이름으로 새 파일을 생성할 수 있습니다. 그러나 Windows에서 notepad.exe는 Windows가 파일을 즉시 삭제하지 않기 때문에 "액세스 위반"이라는 오류 대화 상자를 표시합니다. 나는 당신에게 이것으로 무슨 일이 일어날 지 말할 수 없습니다. 보안 문제? 중요한 파일을 분실하셨습니까? 죄송합니다. 잘 모르겠습니다.

@havoc-io Windows는 파일이 닫힐 때까지 열린 파일을 삭제하지 않으며 열린 파일에 대한 잠금만 유지합니다. 따라서 잠금 사용은 os.Remove() 실패에 대한 의존성을 의미하지 않습니다. Pls는 특히 해당 실패에 따라 달라지는 예를 제공합니다.

다음 주에 golang-dev 스레드에 ping을 보내겠습니다. 2명의 ppl이 그것에 응답했습니다; 한 사람은 이 문제를 읽지 않았으며 어느 쪽도 예를 제공하지 않았습니다.

선정적이고 지지할 수 없는 주장은 "건전한 저항"이 아닙니다.

@havoc-io Windows는 파일이 닫힐 때까지 열린 파일을 삭제하지 않으며 열린 파일에 대한 잠금만 유지합니다. 따라서 잠금 사용은 os.Remove() 실패에 대한 의존성을 의미하지 않습니다. Pls는 특히 해당 실패에 따라 달라지는 예를 제공합니다.

@networkimprov 두 가지 다른 유형의 잠금을

잠금 파일( LockFileEx 로 잠겨 있음)은 일반적으로 리소스를 보호하는 데 사용됩니다. 한 가지 예는 실행 중인 데몬의 인스턴스가 하나만 있는지 확인하는 것입니다. Windows Go 데몬이 파일을 연 다음 파일에서 LockFileEx 를 실행하고 배타적 잠금을 성공적으로 획득하면 잠금 파일이 그 아래에서 제거되지 않을 것이라고 정당하게 가정할 수 있습니다. 그러나 FILE_SHARE_DELETE 가 기본적으로 활성화되어 있으면 이러한 가정을 하는 모든 기존 코드가 더 이상 올바르지 않습니다. 일부 추가 에이전트가 해당 잠금 파일을 제거해야 하는 경우(예: 사용자가 실수로 디렉토리를 삭제하는 경우) 새 데몬이 시작하기로 결정할 때 원래 데몬이 여전히 실행 중일 수 있습니다.

LOCKFILE_FAIL_IMMEDIATELY 플래그가 생략되어 LockFileEx 가 잠금 획득을 위해 차례를 기다리게 하는 경우 잠금 파일을 파이프라인 명령에 사용할 수도 있습니다. 잠금 파일이 실수로 제거되면 파이프라인에 있어야 하는 여러 명령이 한 번에 실행될 수 있습니다.

선정적이고 지지할 수 없는 주장은 "건전한 저항"이 아닙니다.

아무도 이 스레드에서 선정적이거나 지지할 수 없는 주장을 하지 않습니다. 나를 포함하여 당신의 제안에 동의하지 않은 모든 사람은 코드가 뒷받침하는 건전한 주장을 제공했습니다. 당신의 제안을 지지 한 사람들도 마찬가지입니다.

Pls는 WinAPI 문서를 검토합니다. Windows는 파일이 닫힐 때까지 열린 파일을 삭제하지 않으며 열린 파일에 대한 LockFileEx() 잠금만 보유하므로 삭제에 관계없이 파일이 닫힐 때 잠금이 지속되지 않습니다. 삭제 후 잠긴(즉, 열기) 파일을 열려고 하면 오류가 표시되므로 두 번째 잠금을 획득할 수 없습니다. 잠금을 기다리는 스레드에는 파일이 열려 있으므로 삭제로 인해 중단되지 않습니다.

문서를 잘못 읽지 않는 한 마지막 두 시나리오는 지원되지 않습니다. 그리고 이것은 선정적이었고 지원되지 않았습니다. "이 변경은 최악의 경우에 ... CVE 공장처럼 보입니다. 저는 실제로 발생하게 될 명확한 코드 손상보다 모호한 이점이 얼마나 큰지 모르겠습니다."

@networkimprov 문제는 리소스 제한 잠금 파일이 일반적으로 파일 경로를 기반으로 한다는 것입니다. 기본 파일 객체는 파일이 닫힐 때까지 삭제되지 않을 수 있지만 DeleteFile 를 통해 제거되면 파일 시스템 ¹ 의 이전 경로에서 액세스할 수 없으며 다른 잠금 파일을 생성할 수 있습니다. 해당 경로에서 잠금 파일의 목적을 무효화합니다.

나는 그것이 선정적인 논평이라고 생각하지 않습니다. 코드가 더 이상 사실이 아닌 특정 OS 불변성에 의존하는 경우 이와 같은 것이 보안 문제를 일으킬 수 있다는 것은 꽤 분명한 것 같습니다. 그리고 여기의 이점은 꽤 모호해 보이고(여러 사람들이 언급했듯이: 이것은 Windows 동작을 POSIX와 일치시키지 않음) 파손은 꽤 분명해 보입니다(적어도 특정 잠금 동작을 깨뜨림).

¹ 적어도 테스트할 때와 이 의견을 기반으로 하는 경우인 것 같습니다.

https://github.com/golang/go/issues/ 에서 "최신 버전의 Windows에서는 파일이 네임스페이스에서 즉시 제거되는 'POSIX' 삭제를 수행하도록 DeleteFile(NTFS)을 업데이트했습니다."

다시 혜택, 나는 당신이 전체 스레드를 검토해야한다고 생각합니다.

AFAIK 해당 버전의 Windows가 출시되지 않았습니다.

@networkimprov 이미 Windows 10의 경우라고 생각합니다. 파일을 열 때 FILE_SHARE_DELETE 를 CreateFileW 로 지정하면 LockFileEx 잠긴 파일을 제거할 수 있을 것 같습니다.

DeleteFileW()는 해당 시나리오에서 오류를 제공하지 않습니다. 파일 시스템에서 즉시 제거되었는지, 파일/앱 닫기 시 제거되었는지 어떻게 알 수 있습니까? 파일을 제거한 후 파일을 열거나 다시 만들려고 했습니까?

실제로 이는 기술적으로 Go 도구 체인에 영향을 미치며, _또한_ 앞서 언급한 방식으로 LockFileEx 를 사용합니다.

go 명령 내에서 우리는 POSIX 의미 체계를 매우 원하며 FILE_SHARE_DELETE 의 부재에 어떤 식으로든 의존해서는 안 됩니다. 사실, 나는 Windows 파일 잠금이 POSIX에서 벗어나는 방식을 _해결하기 위해 특별히 cmd/go/internal/robustio 패키지를 추가했습니다.

@ianlancetaylor 현재 (문서화되지 않은) Windows syscall.Open() 동작에 의존하는 모든 프로젝트에서 의견을 구하는 golang-nuts & -dev에 반복적으로 게시했습니다. 단 한 건의 사용 사례도 등장하지 않았습니다.

FILE_SHARE_DELETE가 필요한 여러 사용 사례가 위에 나타났으므로(Microsoft에서 특별히 사용하도록 요청했기 때문에) 시험판 1.14에서 기본적으로 이 플래그를 설정하고 주기 동안 원래 동작 표면에 대한 사용 사례가 있는지 다시 평가해 보겠습니다.

이 스레드의 앞부분에서 제안한 것처럼 이 플래그 없이 open() 호출이 필요한 사람은 CreateFileW() & os.NewFile() 사용하여 자신의 호출을 실행할 수 있습니다.

최소한 이것에 대한 손잡이를 노출할 수 있습니까?

이것은 Windows에서 로그 회전을 구현하는 데 매우 유용합니다.

이것은 Windows에서 로그 회전을 구현하는 데 매우 유용합니다.

확실하지는 않지만 파일 핸들이 닫히지 않으면 FILE_SHARE_DELETE가 원래 파일 이름으로 새 파일을 생성하는 것을 허용하지 않기 때문에 작동하지 않을 것이라고 생각합니다.

@Random-Liu Open()에서 fsd를 활성화하거나 비활성화하는 방법을 묻고 있습니까?

@mattn 그것은 나를 위해 작동합니다. os.Rename 이전 로그 파일 이후에 원래 이름으로 새 로그 파일을 만들고 데몬에게 로그 파일을 다시 열도록 알릴 수 있습니다.

@networkimprov FILE_SHARE_DELETE 활성화하는 방법을 원합니다. 저는 현재 syscall.CreateFile 직접 사용하고 있습니다.

내 Windows 버전:

Major  Minor  Build  Revision
-----  -----  -----  --------
10     0      17763  0

@Random-Liu 하지만 UNIX 동작을 시뮬레이션하는 데 이것을 사용할 수는 없는 것 같습니다.

https://github.com/golang/go/issues/32088#issuecomment -510345908

외부 응용 프로그램은 원래 파일 이름에 액세스할 수 없습니다.

mattn, 그 점을 계속 반복할 필요가 없습니다. 핸들이 닫히기 전에 파일 이름을 재사용할 수 있어야 하는 경우 파일을 삭제하기 전에 파일 이름을 변경해야 할 필요성(Windows에서)을 문서화해야 한다고 이미 언급했습니다.

응용 프로그램 자체에서 닫기 전에 파일 이름을 바꾸면 logrotate를 하려는 사용자에게 장점이 없다고 생각합니다.

@ianlancetaylor 다시 시도: https://github.com/golang/go/issues/32088#issuecomment -526074116

이 문제를 릴리스 차단기로 표시했습니다.

@bcmills CL 게시에 관심이

이 줄: https://golang.org/src/syscall/syscall_windows.go#L291
필요한 것: sharemode := uint32(FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE)

편집: 파일을 생성한 다음 파일을 닫기 전에 이름을 바꾸려고 시도하는지 확인하는 테스트입니다.

문제가 동결되기 전에 표면화할 시간이 있으므로 빨리 필요합니다...

또한 os.Remove() 문서는 Windows에서 파일이 닫히기 전에 파일 이름을 재사용할 수 있어야 하는 경우 제거하기 전에 열려 있는 파일의 이름을 바꿔야 한다고 언급해야 합니다. Windows는 파일이 닫힐 때까지 열려 있는 파일에 대한 삭제를 완료하지 않습니다.

최신 버전의 Windows가 https://github.com/golang/go/issues/32088#issuecomment -502850674를 충족하는 것 같습니다. 자세한 내용은 https://github.com/papertrail/go-tail/pull/10#issuecomment -529460973을 참조 FILE_SHARE_DELETE 공유 모드로 열린 경우입니다. 삭제하기 전에 이름을 바꿀 필요가 없습니다. Go에서 기본적으로 FILE_SHARE_DELETE 를 설정하는 것이 마침내 의미가 있을까요?

그것이 의도입니다. CL을 제출할 사람만 있으면 됩니다. (그렇게 하고 싶지만 CLA에 서명할 수 없습니다.)
내 이전 두 의견은 필요한 변경 사항을 설명합니다 ...

@jstarks @jordanrh1 @thaJeztah

의문:
일관된 행동을 얻으려면 어떻게 해야 합니까?
프로그램이 "최신 Windows"에서 실행되는 경우 "삭제 보류" 파일과 유사한 이름을 가진 파일을 생성할 수 있으며 이전 버전은 오류가 발생하면 중단됩니다.

이것은 실제로 "테스트 / 품질 보증을 통과했지만 대부분의 대상에서 작동하지 않습니다"라고 말할 수 있습니다.
"보통 작동하지만 언젠가는 작동하지 않습니다"(지금부터 2년 후에 "파일이 이미 종료됨" 오류가 발생하는 개발자는 재현할 수 없음).

우리는 '이전' 버전을 식별하는 방법을 알아내고 해당 버전의 기본 동작을 변경하거나 "대기 중인 삭제가 있는 경우" 오류를 개선해야 합니다. 어떻게 할 수 있을지 모르겠습니다.
그리고 우리가 할 수 없다면 불일치를 어떻게 처리합니까?

@guybrand 는 위에서 언급했듯이 Windows에서 "파일을 닫기 전에 파일 이름을 다시 사용할 수 있어야 하는 경우 제거하기 전에 열려 있는 파일의 이름을 바꿔야 합니다."라고 문서화할 것입니다.

이것은 POSIX뿐만 ​​아니라 이전 및 새 Windows 버전에서 작동합니다.

다른 접근 방식처럼 들립니다. "새 Windows 또는 POSIX에서도 재사용하기 전에 항상 이름 바꾸기"
나는 그것을 좋아합니다. 그것은 모든 곳에서 성공할 일반적인 관행을 지지합니다.

https://golang.org/cl/194957 에서 이 문제를 언급 변경: syscall: allow FILE_SHARE_DELETE on syscall.Open on Windows

golang-nuts 스레드가 여기 에 있으며 응답이 없습니다. 이것은 golang-nuts 를 읽고 이 행동에 대해 아는 사람이 아무도 그것에 의존하지 않는다는 것을 나타내는 것 같습니다.

golang-dev 쓰레드는 here and here 이고 후자(최근 쓰레드)도 이의를 제기하지 않았습니다.

@alexbrainman -2는 명백한 결정 부족을 기반으로 구현하도록 CL을 NeedsDecision 로 다시 지정했습니다.

개인적으로 이 스레드의 Microsoft 사람들이 FILE_SHARE_DELETE (https://github.com/golang/go/issues/32088 #issuecomment-502850674), 그리고 golang-nuts 아무도 신경 쓰지 않는 것 같으니 우리가 해야 한다고 생각합니다.

이 스레드에서 내가 본 반대 의견은 두 가지 범주로 분류되는 것 같습니다.

1. @alexbrainman (https://github.com/golang/go/issues/32088#issuecomment-504321027)과 @mattn (https://github.com/golang/go/issues/32088#issuecomment-494417146)의 우려 동작이 여전히 POSIX와 일치하지 않기 때문에 POSIX 의미 체계를 기대하는 사용자가 혼란스러울 수 있습니다. (하지만 이미 Windows의 Open 가 POSIX 의미 체계를 제공하지 않는 경우가 있으므로 그 우려는 제안된 변경과 무관하게 보입니다.)

2. @havoc-io의 우려(https://github.com/golang/go/issues/32088#issuecomment-510314947)는 FILE_SHARE_DELETE 가 Windows에서 실행할 때 파일 잠금 패키지가 제공하는 불변성을 감소시키는 것 같습니다. . 그러나 그 주장은 나에게 약간 혼란스러워 보입니다. 왜냐하면 예시로 들어 있는 구체적인 패키지( github.com/gofrs/flock )는 "잠금 동작이 각 플랫폼에서 동일하다고 보장되지 않는다"고 명시적으로 언급하고 빠른 감사에서 구체적인 예 중 어느 것도 잠금과 파일 삭제 사이의 Windows 관련 상호 작용에 의존하지 않는 것 같습니다.

https://github.com/golang/go/issues/32088#issuecomment -498690757의 댓글은 저를 흥미롭게 만듭니다.

https://codereview.appspot.com/8203043/ 에서 제안한 것처럼 전체 도구 체인 동작을 변경하는 @ianlancetaylor 는 좋은 생각이 아니라는 데 동의합니다. 파일 핸들을 잠금 파일로 사용할 때 이 제안을 염두에 두는 즉각적인 문제가 있습니다. 우리는 이 동작을 사용합니다.

@maruel , 귀하의 프로그램이 파일 잠금과 파일 삭제 또는 이름 변경 간의 Windows 관련 상호 작용에 의존하는 방식에 대해 좀 더 자세히 설명해 주시겠습니까?

Chrome 인프라에서는 파일 존재를 잠금 메커니즘으로 사용합니다. 이 사용 사례에 대해 너무 걱정하지 말라고 말하고 싶습니다. 실제로 내가 이해한 바에 따르면 O_CREATE + FILE_FLAG_DELETE_ON_CLOSE 의미 체계는 이러한 요구에 충분하며 이것은 우리가 이미 파이썬 코드 베이스에서 수행하는 Global\\ 네임스페이스의 뮤텍스로 대체될 수 있습니다.

이 솔루션은 언급되지 않았습니다.

path := "delete-after-open"
fd, err := os.OpenFile(path, os.O_RDWR|os.O_CREATE, 0600)
if err != nil { ... }
// defer statements are executed in LIFO
defer os.Remove(path)            // or defer os.Rename(path, path+"2")
if err != nil { ... }
defer fd.Close()

두 가지 단점이 있습니다.

• Close()가 Open() 바로 뒤에 있지 않습니다.
• 오류 코드를 복구하는 것은 더 복잡합니다

@iwdgo 이 솔루션은 단일 프로세스 사용을 위한 것입니다. 위의 논의 대부분은 여러 프로세스의 동시 액세스에 관한 것입니다. 그것이 깃발을 중요하게 만드는 이유입니다.

문제에 대한 @bcmills 요약 을 보완하기 위해 세 가지 다른 플랫폼 간 개발 도구를 살펴보았습니다.

Mingw-w64 는 7년 전에 이를 기본값으로 설정했습니다.
https://sourceforge.net/p/mingw-w64/code/HEAD/tree/stable/v3.x/mingw-w64-headers/include/ntdef.h#l858

Erlang 은 6년 전에 그것을 기본값으로 만들었습니다: erlang/ otp@0e02f48

Python 은 고려 당시 MSVC 런타임의 제한으로 인해 이를 채택할 수 없었습니다. https://bugs.python.org/issue15244

두 번째 golang-nuts 스레드도 이의를 제기하지 않았습니다.
https://groups.google.com/d/topic/golang-nuts/aRvSo3iKvJY/discussion

Open()에 대해 FILE_SHARE_DELETE를 기본값으로 설정하시겠습니까? 우리의 논의는 그렇지 않아야 합니다.

1. @alexbrainman ( #32088 (comment) ) ...의 우려는 행동이 여전히 POSIX와 일치하지 않기 때문에 ...

내 주요 관심사는 사람들의 프로그램을 깨는 것입니다. @minux 가 https://codereview.appspot.com/8203043/#msg10 에서 말한 것과 유사합니다.

또 다른 이유: Windows를 사용하는 사람들은 이름을 바꿀 수 없거나
열린 파일을 제거하는 것이 표준이며 이미 그 사실에 익숙해졌습니다.

여기서 Go 1.0 프로그램 동작을 조용히 변경할 수는 없습니다. 아마도 사람들이
실제로 그것에 의존합니다.

Go 1.0 호환성 약속은 어떻게 되었나요? https://golang.org/doc/go1compat의 어디에 go-nuts에서 의도를 발표하면 열린 파일 동작을 변경해도 괜찮다는 내용이 있습니까?

Go 2를 도입하면 이 동작을 변경할 수 있을까요? 모듈을 사용하여 기존 코드가 손상되지 않도록 보호할 수 있습니까? 그것이 모듈이 설계된 것이라고 가정하는 것이 잘못된 것입니까?

개인적으로 이 스레드의 Microsoft 사람들이 FILE_SHARE_DELETE 를 사용하도록 기본 동작을 변경하는 것을 지원한다는 점을 감안할 때 결정이 명확해 보입니다.

Microsoft가 이 주제에 대해 권한이 있는 경우 Microsoft 개발 도구가 수행하는 작업을 살펴보아야 합니다.

나는이 프로그램을 사용 https://play.golang.org/p/4ZPmV6Df3SD을 @mattn가 게시 것과 유사한 https://github.com/golang/go/issues/32088#issuecomment -493753714 나는 최근에 C 컴파일러를 내장

x64용 Microsoft (R) C/C++ 최적화 컴파일러 버전 19.16.27030.1
저작권 (C) Microsoft Corporation. 판권 소유.

그리고 프로그램을 실행하면 프로그램이 존재하기 전까지 C:\Users\Alex\AppData\Local\Temp\a.txt 파일을 삭제할 수 없습니다.

비슷한 C# 프로그램과 동일 https://play.golang.org/p/SuM2iWYpZir 최근 사용한

Microsoft(R) Visual C# 컴파일러 버전 2.10.0.0(b9fb1610)
저작권 (C) Microsoft Corporation. 판권 소유.

마찬가지로 이 C 프로그램 https://play.golang.org/p/6HgxePzEW_W 는 최근 Mingw로 구축되었습니다.

gcc(x86_64-win32-seh-rev0, MinGW-W64 프로젝트에서 빌드) 7.3.0
Copyright (C) 2017 Free Software Foundation, Inc.

같은 효과가 있습니다. 따라서 이러한 도구에는 기본적으로 FILE_SHARE_DELETE 플래그가 설정되어 있지 않습니다.

그리고 개인적으로 나는 그 변화의 어떤 이점도 보지 못합니다. 여기에는 내 Go 기여도 포함됩니다. 프로세스가 실행되는 동안에는 여전히 실행 파일을 삭제할 수 없습니다. 프로세스에 현재 디렉토리가 설정되어 있는 경우 디렉토리를 삭제하는 데 여전히 문제가 있습니다.

알렉스

Open()에 대해 FILE_SHARE_DELETE를 기본값으로 설정하시겠습니까?

의도는 os.Open이 기본적으로 FILE_SHARE_DELETE를 사용하도록 하는 것입니다. https://golang.org/cl/194957 이 계획입니다.

알렉스

내 주요 관심사는 사람들의 프로그램을 깨는 것입니다.

지금까지 아무도 Go로 연 파일의 이름을 바꾸거나 제거하려고 할 때 오류가 발생하기 때문에 중단되는 프로그램의 단일 예를 지적할 수 없습니다. 그러나 현재 동작으로 인해 Windows에서 Go 앱이 중단되는 문서화된 사례가 있습니다.

Go 1.0 호환성 약속은 어떻게 되었나요?

os.Rename() 및 .Remove()에 대한 Go 문서는 이 Windows 기능에 대해 침묵하지만 다른 Windows 관련 동작에 대해 15개 언급합니다 . BTW, Go 2가 배송되었습니다: https://blog.golang.org/go2-here-we-come

gcc(x86_64-win32-seh-rev0, MinGW-W64 프로젝트에서 빌드) 7.3.0

누구의 C-lib를 gcc와 함께 사용하고 있습니까? 아마도 Microsoft의 것입니까? Mingw-w64는 v6.0에 있으며 FILE_SHARE_VALID_FLAGS에 FILE_SHARE_DELETE가 포함되어 있습니다.

Python에 대해 위에서 설명한 것처럼 과거에 MSVC 런타임은 알 수 없는 이유로 특정 CreateFile() 플래그 조합을 허용하지 않았습니다. 그것이 여전히 사실인지는 모르겠지만 MS가 C-lib fopen()을 변경하지 않은 이유일 수 있습니다.

나는 그 변화의 어떤 이점도 보지 못한다.

이점은 여러 사람이 위에서 반복적으로 설명했습니다. 특히 열린 파일에서 os.Rename()을 허용합니다.

토론이 쉽게 수렴되지 않기 때문에 제안으로 표시합니다.

지금까지의 문제와 논의를 요약하자면 다음과 같습니다.

• Unix 시스템에서 한 프로세스가 파일을 열면 두 번째 프로세스가 해당 파일을 제거할 수 있습니다. 원래 프로세스는 읽기 및 쓰기를 포함하여 파일(더 이상 이름이 없음)을 계속 사용할 수 있으며 성공합니다. 파일 내용은 마지막으로 열린 참조가 사라질 때까지 디스크에서 제거되지 않습니다.

• Windows 시스템에서 기본적으로 한 프로세스가 파일을 열면 두 번째 프로세스는 해당 파일을 제거할 수 _없습니다. 파일은 열려 있는 다른 프로세스가 없을 때만 제거할 수 있습니다. FILE_SHARE_DELETE 플래그는 이 동작을 변경합니다. 파일에 대한 모든 열린 참조가 FILE_SHARE_DELETE로 열린 경우 다른 프로세스가 DeleteFile을 호출할 수 있으며 실패하는 대신 성공합니다.

FILE_SHARE_DELETE를 사용한 Windows 동작은 여전히 ​​Unix와 미묘하게 다른 것 같습니다. MSDN 페이지 는 다음과 같이 말합니다.

응용 프로그램이 일반 I/O 또는 메모리 매핑된 파일로 열려 있는 다른 핸들이 있는 파일을 삭제하려고 하면 DeleteFile 함수가 실패합니다(다른 핸들이 열릴 때 FILE_SHARE_DELETE가 지정되어야 함).

DeleteFile 함수는 파일을 닫을 때 삭제할 파일을 표시합니다. 따라서 파일에 대한 마지막 핸들이 닫힐 때까지 파일 삭제가 발생하지 않습니다. 파일을 열기 위한 이후의 CreateFile 호출은 ERROR_ACCESS_DENIED와 함께 실패합니다.

즉, _name_ 파일은 열린 참조가 사라질 때까지 파일 시스템에서 제거되지 않습니다. 이것은 열린 참조가 닫히기 전에 이름이 사라지는 Unix와 다릅니다. 따라서 동일한 이름의 파일을 다시 생성하기 위해 파일을 제거하는 경우 Unix에서는 작동하지만 Windows에서는 작동하지 않으며 FILE_SHARE_DELETE에서도 작동하지 않습니다.

원래 제안은 이 플래그를 항상 설정하도록 syscall.Open을 변경하는 것이었습니다. syscall이 커널 인터페이스에 가깝다고 가정하면 해당 플래그를 추가하는 것이 적절하지 않은 것 같습니다. 그러나 os.Open / os.OpenFile 중에 설정해야 하는지 여부를 대신 고려할 수 있습니다.

@alexbrainman 은 Unix와 Windows가 다르며, 이 플래그를 설정하더라도 여전히 다를 것이기 때문에 사용자 뒤에서 이러한 변경을 수행하여 문제를 혼동해서는 안 된다고 주장했습니다.

Microsoft의 @jstarks 는 Microsoft가 FILE_SHARE_DELETE를 자동으로 설정하는 것을 선호하며 Windows의 "최신 버전"(어느 것이 출시되었는지 불분명)이 DeleteFile에서 반환될 때 이름의 Unix 의미 체계가 사라지도록 DeleteFile을 변경한다고 말합니다. 따라서 최신 Windows에서 이 작업을 수행하면 Unix와 Windows에서 동일한 동작을 얻을 수 있습니다.

@networkimprov 는 우리가 변경해야 하며 중단될 프로그램의 실제 예가 없다고 주장합니다.

@alexbrainman은 여전히 확신이없는 것 같습니다.

@mattn 은 또한 부분적으로 (적어도 모든 사람이 최신 Windows를 사용할 때까지) Unix와 다를 것이기 때문에 플래그를 자동으로 설정하지 않아야 한다고 제안했습니다.

전반적으로 패키지 os는 이식 가능한 API를 제공하려고 하며 특히 Windows 변경으로 인해 플래그를 자동으로 설정하면 도움이 될 것 같습니다. 특히 O_CLOEXEC(close-on-exec)와 같이 사용자에게 덜 놀라운 동작을 만들기 위해 os.Open에서 자동으로 설정하는 다른 플래그가 있습니다. os.Open에서 이 플래그를 설정하기 때문에 Windows에서 중단되는 모든 프로그램은 Unix에서도 반드시 중단될 것입니다. 그렇죠?

특히 Microsoft의 엔지니어 중 한 명이 설정해야 한다고 하므로 패키지 os에 설정해도 괜찮을 것 같습니다. 플래그 세트를 원하지 않는 사람들은 여전히 ​​패키지 syscall로 폴백할 수 있습니다.

@alexbrainman 및 @mattn , 했다고 가정합니다. 우리는 일부 프로그램이 더 잘 작동한다는 것을 알고 있습니다. 고장날 수 있는 실제(또는 가능성이 있는) 프로그램의 구체적인 예가 있습니까? 이러한 프로그램은 Unix에서 이미 중단되지 않았습니까? 감사 해요.

@rsc , 입력해 주셔서 감사합니다. 패키지 "os"에서 이것을 활성화하면 저에게 효과적입니다. 이것이 채택되면 완전성을 위해 FILE_SHARE_DELETE를 활성화하는 syscall.Open() 플래그가 제공되어야 합니다.

요약을 명확히 하기 위해 프로세스 경계는 요소가 아닙니다. 효과는 단일 프로세스 내에서 동일합니다. 그리고 플래그는 파일 이름 변경에도 영향을 줍니다. 플래그를 사용하면 파일 삭제와 달리 즉시 완료됩니다. (그리고 삭제 직후 파일 이름 가용성에 대한 해결 방법을 허용합니다.)

@networkimprov 감사합니다. 예, 프로세스 경계가 엄격하게 관련이 없다는 것을 이해합니다. 상황을 설명하기 쉽게 만듭니다.

제목을 변경하고 문제 텍스트에서 실행 계획을 수정했습니다.

a) os.Create/Open/OpenFile()은 Windows에서 항상 file_share_delete를 활성화해야 합니다.
b) Windows의 syscall.Open()은 file_share_delete를 활성화하는 플래그를 수락해야 합니다.
c) Windows의 syscall은 새 플래그에 대한 상수를 내보내야 합니다.

os.Remove() 문서는 Windows에서 열려 있는 파일을 삭제한 후 파일 이름을 재사용하려면 os.Rename(path, unique_path); os.Remove(unique_path) 수행해야 합니다.

현재 Go의 os.Open 동작을 사용하여 배타적 처리를 구현하는 사용자가 있을 가능성을 거부할 수 없습니다.

그러나 현재 동작으로 인해 Windows에서 Go 앱이 중단되는 문서화된 사례가 있습니다.

이것들은 무엇입니까? 문제 번호는 무엇입니까? 그리고 break 라는 단어는 무엇을 의미합니까? 그들은 언제 부서졌습니까?

누구의 C-lib를 gcc와 함께 사용하고 있습니까? 아마도 Microsoft의 것입니까? Mingw-w64는 v6.0에 있으며 FILE_SHARE_VALID_FLAGS에 FILE_SHARE_DELETE가 포함되어 있습니다.

모르겠어요. 방금 인터넷에서 x86_64-7.3.0-release-win32-seh-rt_v5-rev0.7z 파일을 다운로드했습니다. 구글링하시면 됩니다. 버전 7.3입니다.

나는 그 변화의 어떤 이점도 보지 못한다.

이점은 위에서 반복적으로 설명되었지만 ...

견적에서 personally 라는 단어를 남겼습니다. 나는 내 자신의 필요에 대해 이야기합니다. 여기에는 내 Go 프로젝트 기여도 포함됩니다.

지금까지의 문제와 논의를 요약하자면 다음과 같습니다.

Windows의 Microsoft 개발자 도구가 기본적으로 이 플래그를 제공하지 않는다고 말하지 않았습니다. 내 의견 참조 https://github.com/golang/go/issues/32088#issuecomment -531713562

Go 1 호환성에 대한 내 의견도 무시했습니다.

Go 1.0 호환성 약속은 어떻게 되었나요? https://golang.org/doc/go1compat의 어디에 go-nuts에서 의도를 발표하면 열린 파일 동작을 변경해도 괜찮다는 내용이 있습니까?

이 변경 사항이 Go 1.0 호환성 약속에 어떻게 부합합니까?

전반적으로 패키지 os는 이식 가능한 API를 제공하려고 하며 특히 Windows 변경으로 인해 플래그를 자동으로 설정하면 도움이 될 것 같습니다.

나는 이 변경이 사람들이 Unix 소프트웨어를 Windows로 이식하는 것을 목표로 한다는 데 동의합니다.

불행히도 Windows 사용자를 희생시킵니다. Windows의 다른 프로그램이나 도구가 이 방식으로 작동하지 않기 때문에 이러한 변경은 Windows 사용자와 개발자에게 놀라운 일일 것입니다. 미래에 있을지도 모르지만 아직은 아닙니다.

그리고 Unix 소프트웨어를 Windows로 이식하는 사람들에게도 이 변경은 IMHO에 좋지 않은 영향을 미치고 있습니다. 내 의견에서 We still won't be able to delete executable files while process is running. We will still have problems deleting directories if any process have their current directories set there. 부분을 참조하십시오. https://github.com/golang/go/issues/32088#issuecomment -531713562

특히 O_CLOEXEC(close-on-exec)와 같이 사용자에게 덜 놀라운 동작을 만들기 위해 os.Open에서 자동으로 설정하는 다른 플래그가 있습니다. os.Open에서 이 플래그를 설정하기 때문에 Windows에서 중단되는 모든 프로그램은 Unix에서도 반드시 중단될 것입니다. 그렇죠?

나는 당신이 여기에서 무엇을 의미하는지 모르겠습니다. Windows에서 O_CLOEXEC는 파일 핸들이 자식 프로세스로 탈출하는 것을 방지하는 것을 의미합니다. 그리고 O_CLOEXEC는 항상 Windows의 os.Open에 설정됩니다. 따라서 os.Open으로 열린 파일은 Windows의 자식 프로세스에서 액세스할 수 없습니다. 그래서 무엇? 합리적으로 들립니다.

이러한 프로그램은 Unix에서 이미 중단되지 않았습니까?

나는 당신의 질문을 이해하지 못합니다.

고장날 수 있는 실제(또는 가능성이 있는) 프로그램의 구체적인 예가 있습니까?

그런 프로그램이 있는지 모르겠습니다. 말할 수 없습니다. 내가 작성한 모든 프로그램을 기억하지 못합니다. 그들이하는 일을 기억하지 못합니다.

그러나 Windows 서비스가 미리 정의된 파일을 열고 c:\mysvc.txt 라고 말하면 계속 열려 있다고 상상할 수 있습니다. 서비스가 활성 상태인지 확인하고 필요한 경우 서비스를 다시 시작하는 다른 프로그램을 상상해 보십시오. 이 다른 프로그램은 c:\mysvc.txt 삭제를 시도하고 파일이 사라지면 서비스 프로세스가 죽었다고 안전하게 가정할 수 있습니다.

또한 일부 프로그램은 사용자가 파일을 삭제하거나 이동하는 것을 방지할 수 있습니다. https://stackoverflow.com/questions/11318663/prevent-a-user-from-deleting-moving-or-renaming-a-file

알렉스

다음은 Windows에서 Go의 데이터 포인트 재배포입니다.
Win8은 7년 전에 출시되었습니다.
Win8+에 영향을 미치는 이 Go 버그는 5개월 전에 보고되었습니다: #31528

@rsc Go로 열린 파일의 이름을 바꾸거나 제거하려고 할 때 오류가 발생할 것으로 예상되는 모든 프로그램은 Unix에서 손상됩니다. 예를 들어 Alex의 c:\mysvc.txt 시나리오입니다.

Windows에서 개발하고 Linux/etc에 배포하는 경우(또는 그 반대의 경우도 마찬가지) 버그의 원인이 될 수 있습니다.

우리의 사용 사례는 파일에 기록하는 로거가 있다는 것입니다.
로그 파일은 회전을 지원합니다(예: 로그 파일이 > maxSize이면 다음 쓰기 후 회전).
또한 이러한 파일을 열어 읽는 동안 열어 두는 판독기가 있습니다.

FILE_SHARE_DELETE 를 설정하는 기능도 없으면 활성 독자가 있는 동안 회전(이름 변경 및/또는 삭제)을 수행할 수 없습니다.

@mattn :

현재 Go의 os.Open 동작을 사용하여 배타적 처리를 구현하는 사용자가 있을 가능성을 거부할 수 없습니다.

그럴 수도 있지만 그러한 코드는 어쨌든 Unix에서 올바르지 않습니다. 패키지 os는 이식 가능한 인터페이스를 의미합니다. 또한 우리는 가능성보다 _actual_ 프로그램에 더 관심이 있습니다.

@alexbrainman :

Windows의 Microsoft 개발자 도구가 기본적으로 이 플래그를 제공하지 않는다고 말하지 않았습니다. 내 댓글 보기 #32088(댓글)

예, 하지만 그것은 C입니다. 우리는 Go에 대해 이야기하고 있습니다. 우리는 일반적으로 C API를 모방하지 않습니다. 우리는 패키지 os에서 대부분 이식 가능한 추상화를 제공하려고 노력하고 있습니다. O_CLOEXEC에 대한 요점은 Unix 시스템에서 os.Open이 해당 C 호출에서 기본적으로 설정되어 있지 않더라도 O_CLOEXEC를 설정한다는 것입니다. 우리는 모든 시스템에서 거의 동일하게 작동하는 유용한 기본값을 제공하려고 _do_ 합니다.

Go 1 호환성에 관한 한, 한 OS의 모서리 동작을 다른 OS와 더 잘 맞도록 변경하는 것은 괜찮아 보입니다. 우리는 모든 시스템 간 비호환성을 항상 유지하겠다고 약속하지 않습니다.

Window 특정 동작을 주장하는 Windows 사용자는 항상 패키지 syscall을 사용할 수 있는 옵션이 있습니다. 이는 도달하려는 동작이 실제로 Windows에만 적용된다는 것을 분명히 합니다.

다시 말하지만, 깨질 실제 프로그램의 구체적인 예가 있습니까?

@cpuguy83 , 도움이 될 프로그램의 실제 사용 사례에 감사드립니다.

@rsc 당신이 말했듯이, 나는 아직 FILE_SHARE_DELETE의 파괴 효과를 파악하지 못했습니다. 마찬가지로 이 변경으로 logrotate를 구현할 수 있다는 확인은 발견되지 않았습니다.

그러나 Go가 파일을 삭제할 수 있는 이 변경 사항을 포함하면 Go가 이 변경 사항으로 Windows에서 logrotate를 구현할 수 없더라도 사용자는 이 동작을 예상할 것입니다. 따라서 우리는 이 변화에 대해 신중하게 생각해야 합니다. 기본적으로 Windows는 FILE_SHARE_DELETE 플래그가 지정되지 않은 파일을 삭제할 수 없습니다. 사용자는 이 변경으로 Go가 모든 파일을 삭제할 수 있다고 생각할 수 있습니다. 특히 핸들이 있는 os.NewFile에 의해 생성된 파일은 이 플래그가 설정되지 않아도 os.File 구조체의 메서드를 조작할 수 있습니다. 프로그래머는 Windows에서 파일을 삭제할 수 있는지 여부를 알아야 한다고 생각합니다. 기본값 대신 os.OpenFile에 대한 플래그로 FILE_SHARE_DELETE를 전달할 수 있는 메커니즘을 선호합니다. 기본 동작은 OS의 동작을 따라야 한다고 생각합니다.

예, 하지만 그것은 C입니다. 우리는 Go에 대해 이야기하고 있습니다.

그리고 C#도요. 나는 조사하지 않았지만 Windows의 다른 개발 도구가 이런 식으로 작동한다고 확신합니다.

Go 1 호환성에 관한 한, 한 OS의 모서리 동작을 다른 OS와 더 잘 맞도록 변경하는 것은 괜찮아 보입니다.

Windows 사용자가 아닌 경우에는 예외입니다. Windows 사용자의 경우 이 동작은 표준입니다.

다시 말하지만, 깨질 실제 프로그램의 구체적인 예가 있습니까?

구체적인 내 서비스 예를 고려하십시오.

@cpuguy83 , 도움이 될 프로그램의 실제 사용 사례에 감사드립니다.

@cpuguy83 귀하의 문제에 대해 더 자세히

기본적으로 Windows는 FILE_SHARE_DELETE 플래그가 지정되지 않은 파일을 삭제할 수 없습니다. 사용자는 이 변경으로 Go가 모든 파일을 삭제할 수 있다고 생각할 수 있습니다.

나는 이것이 좋은 지적이라는 데 동의합니다. Go 프로그램에서 연 파일만 삭제할 수 있습니다. 그러나 Go 프로그램이 아닌 다른 모든 파일은 여전히 ​​삭제할 수 없습니다. 그러면 os.Remove가 예측할 수 없게 됩니다. 작동할 때도 있고 작동하지 않을 때도 있습니다.

알렉스

열린 파일의 이름을 바꾸는 패치된 syscall.Open()을 호출하는 코드가 있습니다. 이것이 로그 회전을 구현하는 방법입니다. 효과가있다.

// several processes or goroutines do this
   fd, err := os.OpenFile("log", os.O_CREATE|os.O_APPEND|os.O_WRONLY, ...)
   _, err = fd.Write(log_entry) // one or more times
   err = fd.Close()

// log rotator process does this
   err := os.Rename("log", "log_old") // active writers not disturbed
   fmt.Println(err) // "sharing violation" without FILE_SHARE_DELETE

그러나 당신은 그것을 말할 사람이 필요하지 않았습니다 :-/

당연히 os.NewFile()의 os.File은 os.Create/Open/OpenFile()의 속성과 많은 다른 속성을 가질 수 있습니다. 이는 놀라운 일이 아니라 기능입니다.

Microsoft C fopen() 동작이 Windows 기본 동작이라고 주장합니다. 그건 사실이 아니야. CreateFile() 기본 공유 모드는 없습니다. FILE_SHARE_READ | FILE_SHARE_WRITE 가 아닙니다.

배포된 Windows 프로그램은 일반적으로 __다른 공급업체의 프로그램__이 항상 특정 방식으로 파일을 여는 것으로 가정한다고 주장합니다. 이 경우 Microsoft는 기본적으로 file_share_delete를 활성화하도록 요청하지 않았을 것입니다.

@networkimprov

그러나 당신은 그것을 말할 사람이 필요하지 않았습니다 :-/

외부 프로세스가 어떤 경우에도 파일을 올바르게 제거하고 이름을 바꿀 수 있는지 알고 싶습니다.

내가 알고 싶은 것은 변경 사항을 포함시킨 후 Go에서 로그 파일이 출력되고 외부 프로세스에서 실행한 logrotate가 제대로 작동하며 오류 없이 프로덕션 준비 상태로 작동한다는 것입니다.

@alexbrainman

불행히도 코드는 복잡하지만 이것은 실제 실제 코드입니다: https://github.com/moby/moby/blob/master/daemon/logger/loggerutils/logfile.go

제안된 완화 방법은 현재 os.OpenFile 및 syscall.Open을 분기하는 것입니다. https://github.com/moby/moby/pull/39974/files

분명히 하자면, OpenFile에서 FILE_SHARE_DELETE 또는 syscall.Open 로 전달하는 옵션만 있으면 이 경우를 처리하기에 충분할 것입니다.

불행히도 코드는 복잡하지만 이것은 실제 실제 코드입니다: https://github.com/moby/moby/blob/master/daemon/logger/loggerutils/logfile.go

제안된 완화 방법은 현재 os.OpenFile 및 syscall.Open을 분기하는 것입니다. https://github.com/moby/moby/pull/39974/files

@ cpuguy83 포인터 주셔서 감사합니다.

불행히도 이 문제를 간략히 살펴본 결과 현재 문제가 해결책인지 판단하기에 충분한 정보를 제공하지 못합니다. 나는 repro (아마도 https://github.com/moby/moby/issues/39274#issuecomment-497966709 )로 시작하여 거기에서 가져와야 할 것입니다. 언제 이 일에 시간을 할애할 수 있을지 모르겠습니다. 내 계획보다 더 나은 제안이 있으면 알려주십시오.

알렉스

아래는 표준 관행 로그 회전의 작업 데모입니다. 각 고루틴 100개는 로그 파일을 열 때마다 0.1-2초 간격으로 50줄을 기록하고 다른 고루틴은 1분 간격으로 로그를 회전합니다. 나는 오류가 없는 Win7 노트북에서 어제 몇 시간 동안 이것을 실행했습니다.

FILE_SHARE_DELETE를 활성화하는 syscall.Open()에 대한 패치로 빌드되었습니다. 그렇지 않으면 실패합니다. 이 플래그 없이 더 복잡한 로깅 체계를 구성할 수 있지만 다른 많은 용도가 있습니다. 내 코드는 다른 이유로 열려 있는 파일의 이름을 바꿉니다.

@rsc , 여전히 의심

package main

import (
   "fmt"
   "os"
   "math/rand"
   "syscall"
   "time"
)

const kLogFile = "winrotate"

func main() {
   syscall.Open_FileShareDelete = true
   rand.Seed(time.Now().UnixNano())

   for a := 0; a < 100; a++ {
      go runLog()
   }

   fmt.Println("rotating to "+ kLogFile +"N.txt")
   for a := 0; true; a++ {
      if a >= 5 {
         a = 0
      }
      time.Sleep(60 * time.Second)
      err := os.Rename(kLogFile +".txt", kLogFile + string('0'+a) +".txt")
      if err != nil {
         fmt.Println(err)
         os.Exit(1)
      }
   }
}

const kLineVal = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ"

func runLog() {
   aLine := make([]byte, 102)
   for {
      aFd, err := os.OpenFile(kLogFile +".txt", os.O_CREATE|os.O_APPEND|os.O_WRONLY, 0600)
      if err != nil {
         fmt.Println(err)
         return
      }
      for _, aV := range kLineVal {
         for a := range aLine {
            aLine[a] = byte(aV)
         }
         aEnd := aV - ('z' - 100) // limit line len to 100
         copy(aLine[aEnd:], []byte{'\r','\n'})
         _, err = aFd.Write(aLine[:aEnd + 2])
         if err != nil {
            fmt.Println(err)
            return
         }
         time.Sleep(time.Duration(100 + rand.Intn(1900)) * time.Millisecond)
      }
      err = aFd.Close()
      if err != nil {
         fmt.Println(err)
         return
      }
   }
}

syscall_windows.go에 대한 패치:

diff --git a/src/syscall/syscall_windows.go b/src/syscall/syscall_windows.go
index de05840..e1455d5 100644
--- a/src/syscall/syscall_windows.go
+++ b/src/syscall/syscall_windows.go
@@ -245,6 +245,8 @@ func makeInheritSa() *SecurityAttributes {
    return &sa
 }

+var Open_FileShareDelete = false
+
 func Open(path string, mode int, perm uint32) (fd Handle, err error) {
    if len(path) == 0 {
        return InvalidHandle, ERROR_FILE_NOT_FOUND
@@ -270,6 +272,9 @@ func Open(path string, mode int, perm uint32) (fd Handle, err error) {
        access |= FILE_APPEND_DATA
    }
    sharemode := uint32(FILE_SHARE_READ | FILE_SHARE_WRITE)
+   if Open_FileShareDelete {
+       sharemode |= FILE_SHARE_DELETE
+   }
    var sa *SecurityAttributes
    if mode&O_CLOEXEC == 0 {
        sa = makeInheritSa()

@networkimprov 외부 프로세스에 의해 파일 이름이 변경되지 않습니다. 파일 이름 바꾸기가 동일한 프로세스에서 수행되는 경우 이를 구현하는 몇 가지 다른 방법이 있습니다.

https://github.com/mattn/go-sizedwriter/blob/master/_example/example.go#L14

아래는 표준 관행 로그 회전의 작업 데모입니다.

@networkimprov님 , 예를 들어 주셔서 감사합니다. 이제 당신이 무엇을 하려고 하는지 알 수 있습니다.

코드의 유일한 문제는 일부 외부 프로세스가 FILE_SHARE_DELETE 없이 작성 중인 파일을 열면 Go에서 변경한 사항에 관계없이 지금과 동일한 문제가 발생한다는 것입니다.

@cpuguy83 @networkimprov 예제에서 그가 시도하고 있는 사진을 제공하기 때문에 (여기에서 약속한 대로 https://github.com/golang/go/issues/32088#issuecomment-536233195 ) 귀하의 문제를 보지 않을 것입니다. 할 것.

알렉스

Alex, 외부 액세스가 허용되는 경우 이름 바꾸기 시도를 반복하거나 허용되지 않는 경우 활성 로그 파일을 제한할 수 있습니다.

Mattn, 회전 이름 바꾸기는 일반적으로 별도의 프로세스로 수행됩니다.

여기에는 명확한 합의가 없는 것 같습니다. Unix 배경을 가진 개발자는 이에 찬성하는 것처럼 보이지만 가장 활동적인 Windows 개발자 중 두 명( @alexbranman 및 @mattn)은 그렇지 않습니다. 또한 변경 사항은 FILE_SHARE_DELETE에 대해 새로운 Unix와 유사한 동작이 있는 최신 버전의 Windows만 통합합니다.

몇 년 후에 이 주제를 다시 방문하여 새 플래그 동작이 얼마나 널리 사용 가능한지와 다른 언어가 공통 동작으로 수렴되었는지 여부를 확인하는 것이 좋습니다. 누군가가 이를 다시 생각하기 위해 2년 정도 후에 새로운 문제를 제기하고 싶다면 괜찮을 것입니다.

그러나 현재로서는 합의의 부족을 감안할 때 이것이 감소할 것으로 보입니다.

최종 의견을 위해 일주일 동안 열려 있습니다.

옵션을 사용 가능하게 만드는 것에 대한 논쟁이 있습니까?

우리가 차임할 더 많은 목소리를 찾고 있다면 나는 확실히 _무언가_를 하는 것에 찬성할 것입니다. 현재 유일한 해결책은 Go의 표준 라이브러리에서 말 그대로 많은 양의 코드를 복사하고 한 줄을 변경한 다음 해당 포크를 영원히 유지하는 것입니다. 로그 모니터 또는 라이브 "꼬리"의 모든 구현은 결국 이것을 수행하는 것 같습니다.

예를 보려면 https://github.com/elastic/beats/blob/master/libbeat/common/file/file_windows.go#L85 -L103을 참조

내가 올바르게 따랐다면 이 제안은 실제로 두 부분으로 구성됩니다.

1. 파일을 열 때 FILE_SHARE_DELETE 플래그 사용 허용 -
   구현은 쉽고 안전해야 하며 개발자는 명시적으로
   새 파일을 열 때 이 모드를 요청하십시오
2. 기본적으로 이 플래그를 켜십시오 - 위험할 수 있으며 잘 지원되는 경우에만
   마지막 Windows 10 빌드를 사용할 때.

모두가 1에 동의한다면 개발자가 플래그를 허용할 수 있습니다.
지금은 명시적으로 요청하고 몇 년 후에 2를 다시 방문하십시오.

2019년 10월 2일 수요일 19:32 Mark Dascher, [email protected]이 다음과 같이 썼습니다.

우리가 차임 할 더 많은 목소리를 찾고 있다면 확실히 찬성 할 것입니다.
뭔가 를 하는
Go의 표준 라이브러리에서 코드 묶음을 한 줄 변경한 다음
그 포크를 영원히 유지하십시오. 로그 모니터 또는 라이브의 모든 구현
"꼬리"는 결국 이렇게 하는 것 같습니다.

예를 보려면 다음을 참조하십시오.
https://github.com/elastic/beats/blob/master/libbeat/common/file/file_windows.go#L85 -L103

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/golang/go/issues/32088?email_source=notifications&email_token=ABNEY4VFQLSYVI66ENT6G4LQMTLJ7A5CNFSM4HNPNYIKYY15NVWWK3TUL52HS4DFVEXG43VMVBW63LN
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/ABNEY4U5L3WFZYNIUOSEY2TQMTLJ7ANCNFSM4HNPNYIA
.

확실히 _적어도_는 1. 가 있어야 합니다(파일을 열 때 FILE_SHARE_DELETE 플래그 사용 허용).

내 이전 제안 을 다시 방문 하고 예제 구현에 대한 후속 조치 를 취하기만 하면 됩니다.

syscall.FILE_SHARE_DELETE 플래그는 os.OpenFile 의 flag 매개변수에 잘 맞고 온디맨드 방식으로 이 동작을 활성화하는 간단한 메커니즘을 제공합니다. Windows의 다른 os.O_* 플래그와 충돌하지 않으며(이를 적용/엔지니어링할 수 있음) 시스템별 파일 열기 동작을 지정하는 관용적 방법을 제공합니다( os ' ■ POSIX 지향 인터페이스는 Windows에서 관용적인 것으로 간주될 수 있습니다. 이것은 POSIX 플랫폼(예: Linux의 syscall.O_DIRECTORY )에서 시스템별 파일 열기 동작을 전달하는 데 이미 사용된 것과 동일한 경로입니다.

기본적으로 활성화하지 않기로 결정한 경우(내 생각에 이것이 올바른 호출이라고 생각함), 나는 플래그에 사용 사례(@networkimprov가 지적한 것을 포함하여)가 있고 다음과 같이 하는 것이 유용할 것이라는 데 동의합니다. CreateFileW 호출에 의존하고 상용구 코드를 복사하지 않고도 켤 수 있습니다.

개발자가 필요할 때 FILE_SHARE_DELETE 를 설정하고 Go 표준 라이브러리 코드의 분기된 청크를 방지하는 옵션을 허용하는 위의 대안 [1]을 고려하십시오.

__Rust__는 기본적으로 이 플래그를 설정하고 FILE_SHARE_* 옵션 중 하나를 _스위치 끄기__ 허용합니다.
https://doc.rust-lang.org/std/os/windows/fs/trait.OpenOptionsExt.html

@rsc 제안에 대해 제기된 기술적 주장 중 어떤 것이 반박되지 않았는지 물어봐도 될까요?

@networkimprov 전체 제안과 토론을 읽은 후 ossyscall 패키지에 새 창 특정 플래그를 추가하는 것에 대해 명시적으로 이 문제를 닫고 새 문제를 다시 열어야 한다고 생각합니다. 이렇게 하면 새 동작이 옵트아웃이 아닌 옵트인이 됩니다. 현재 제안은 기존 코드를 변경하는 것을 의미하므로 사람들이 걱정합니다.

@rsc 제안에 대해 제기된 기술적 주장 중 어떤 것이 반박되지 않았는지 물어봐도 될까요?

죄송하지만 제안 절차 는 그렇지 않습니다. 다른 사람들의 주장을 "논박"하는 것만으로는 충분하지 않습니다. "제안 과정의 목표는 적시에 결과에 대한 일반적인 합의에 도달하는 것입니다." 앞으로 나아갈 방향에 대한 명확한 합의가 없습니다. 기술적 주장이 제기되었지만 Windows 포트(즉, @alexbrainman 및 @mattn)에 상당한 기여를 한 주요 Go 개발자를 설득하지 못했습니다. 명확한 합의가 결여된 것 외에도 지금 당장 무엇을 해야 할 시급성에 대한 명확한 징후가 없습니다. Go는 이 문제가 제기되기 전 거의 10년 동안 Windows에서 잘 작동했습니다. 내가 이해하는 한 모든 것을 그대로 두는 것은 Go가 항상 그랬던 것처럼 계속 작동할 것임을 의미합니다.

이 파일이 거부된 (여전히 가능성이 있음) 이벤트에서 FILE_SHARE_DELETE로 파일을 열 수 있는 더 쉬운 방법을 제공하기 위해 #34681을 제출했습니다. 매우 길어진 이 스레드를 계속하는 것보다 그 아이디어로 제한된 새로운 스레드를 시작하는 것이 더 도움이 되는 것 같았습니다.

@rsc , 거절하기 전에 Alex가 당신의 O_ALLOW_DELETE 제안에 대해 어떻게 생각하는지 들어봅시다.

이 토론 초기에 그는 file_share_delete를 설정하는 새로운 os.OpenFile() 플래그에 반대했습니다. 같은 이유로 os.Create/Open/OpenFile() 제안에 동의하지 않았습니다. 그는 MSVC fopen()이 그렇게 할 수 없기 때문에 다른 프로그램에서는 아무도 그런 식으로 파일을 열지 않는다고 가정하는 것을 우려합니다. 따라서 해당(아직 지정되지 않은) 프로그램은 플래그를 설정한 Go 프로그램을 중단합니다.

Alex, 외부 액세스가 허용되면 이름 바꾸기 시도를 반복할 수 있습니다.

이름 바꾸기를 반복할 준비가 되었다면 Go 리포지토리 코드에서 아무 것도 변경할 필요가 없습니다. 귀하의 프로그램은 지금처럼 잘 작동할 것입니다.

현재 유일한 해결책은 Go의 표준 라이브러리에서 말 그대로 많은 양의 코드를 복사하고 한 줄을 변경한 다음 해당 포크를 영원히 유지하는 것입니다.

코드를 별도의 패키지에 복사하는 것이 좋다고 생각합니다. https://github.com/moby/moby/pull/39974를 조사하는 동안 저도 같은 생각을 했습니다. 유지해야 할 코드가 많지 않다고 생각합니다. 사실 나는 그것을 구현했다.

https://github.com/alexbrainman/goissue34681

그대로 복사하거나 사용하십시오. 아마도 이 기능에 대한 많은 관심이 있기 때문에 다른 사람들이 공유하고 사용할 수 있는 적절한 패키지를 실제로 만들 수 있습니다. 이렇게 하면 최신 상태로 유지하고 버그를 수정할 수 있습니다.

@rsc , 거절하기 전에 Alex가 당신의 O_ALLOW_DELETE 제안에 대해 어떻게 생각하는지 들어봅시다.

제발, 시도

https://github.com/alexbrainman/goissue34681

첫 번째. 어떤 이유로든 만족하지 못한다면 Go 리포지토리에 새로운 기능을 추가하는 것에 대해 논의할 수 있습니다.

감사합니다.

알렉스

이 답변에 정말 실망했습니다.

대부분 이해조차 되지 않는 이 방대한 양의 코드를 복사하는 것입니다.
이 작업을 수행하는 이유) 단일 옵션을 추가할 수 있도록
시스템 자체가 지원하는 Go, 대부분은 그렇지 않다고 가정합니다.
고의로 옵션을 전달할 수단을 제공하지 않습니다.
syscall.Open은 터무니없는 상황처럼 보입니다.

이 옵션을 전달하기 위해 syscall.Open을 다시 작성해야 하는 이유는 무엇입니까?

2019년 10월 5일(토) 18:43 Alex Brainman [email protected]에서 다음과 같이 썼습니다.

Alex, 외부 액세스가 허용되면 이름 바꾸기 시도를 반복할 수 있습니다.

이름 바꾸기를 반복할 준비가 되었다면 아무 것도 변경할 필요가 없습니다.
Go repo 코드에서. 귀하의 프로그램은 지금처럼 잘 작동할 것입니다.

지금 당장은 유일한 해결책은 말 그대로 여러 코드를 복사하는 것입니다.
Go의 표준 라이브러리에서 한 줄을 변경한 다음 해당 포크를 영원히 유지합니다.

코드를 별도의 패키지에 복사하는 것이 좋다고 생각합니다. 조사하면서
moby/moby#39974 https://github.com/moby/moby/pull/39974 나는 같은 것을 얻었다
아이디어. 유지해야 할 코드가 많지 않다고 생각합니다. 사실 나는
그냥 구현

https://github.com/alexbrainman/goissue34681

그대로 복사하거나 사용하십시오. 아마도 관심이 너무 많다는 점을 감안할 때
이 기능을 사용하면 실제로 공유할 수 있는 적절한 패키지를 만듭니다.
다른 사람들이 사용합니다. 이렇게 하면 최신 상태로 유지하고 버그를 수정할 수 있습니다.

@rsc https://github.com/rsc , 이것을 거부하기 전에 무엇을 듣고
Alex는 당신의 O_ALLOW_DELETE 제안을 생각합니다.

제발, 시도

https://github.com/alexbrainman/goissue34681

첫 번째. 어떤 이유로 만족하지 않으면 새로운 추가에 대해 논의할 수 있습니다.
기능을 Go 저장소로 이동합니다.

감사합니다.

알렉스

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/golang/go/issues/32088?email_source=notifications&email_token=AAGDCZXHULQEMHAPTO6ZUJTQNFGE7A5CNFSM4HNPNYIKYY3PNVWWK3TUL52HS4DFVEXG43VMXQHJDNMV
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AAGDCZWYUNMCTAGO567AV73QNFGE7ANCNFSM4HNPNYIA
.

>

• 브라이언 고프

이 답변에 정말 실망했습니다.

그렇게 느끼셨다면 죄송합니다. 하지만 실제로 내 패키지를 사용하려고 했습니까?

알렉스

@rsc , Alex도 os.OpenFile() 플래그에 반대하므로 아무 것도 하지 않아야 합니까?

이 기능을 빌드 플래그 뒤에 두는 것은 어떻습니까?

"Go가 거의 10년 동안 Windows에서 잘 작동했는지" 여부에 관해서는 열려 있는 파일의 이름을 바꿔야 하는 경우 확실히 그렇지 않았습니다. (지난 7년 동안 Windows 8/10 노트북에서도 고장났습니다.)

내 자신의 os.OpenFile 및 syscall.Open 포크가 이미 moby/moby에 있습니다.

왜 우리는 여기에서 그렇게 무시합니까?

2019년 10월 8일 화요일 01:47 Alex Brainman [email protected]에서 다음과 같이 썼습니다.

이 답변에 정말 실망했습니다.

그렇게 느끼셨다면 죄송합니다. 하지만 실제로 내 패키지를 사용하려고 했습니까?

알렉스

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/golang/go/issues/32088?email_source=notifications&email_token=AAGDCZRV72GY4IJQJVJWMYTQNRCIHA5CNFSM4HNPNYIKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AAGDCZRNYSMIE6BX77XJVWDQNRCIHANCNFSM4HNPNYIA
.

>

• 브라이언 고프

나는 이 특정한 제안을 거절할 것을 제안합니다. 우리는 os.OpenFile의 기존 동작에 의존하는 Windows 사용자를 위해 TOCTOU 보안 버그를 많이 소개하지 않을 것입니다.

여기서 더 큰 질문은 "Windows의 CreateFile 및 NtCreateFile 기능에 대해 다양하고 흥미로운 플래그를 Go 사용자에게 어떻게 노출할 수 있습니까?"입니다. 나는 우리가 다른 제안에서 그것들을 다룰 수 있을 것이라고 기대하지만, 확실히 여기에서 제안하는 것처럼 기본적으로 그것들을 모두 켜는 것은 아닙니다.

@zx2c4 전체 스레드를 읽었습니까? 반복적인 시도에도 불구하고 기존의 문서화되지 않은 행동에 의존하는 Go 사용자의 사례는 단 한 건도 식별할 수 없었습니다.

https://github.com/golang/go/issues/32088#issuecomment -537590826 이후 일주일이 지났지만 여전히 명확한 합의가 이루어지지 않아 이를 거부해야 합니다.

거부됨

https://github.com/golang/go/issues/34681#issuecomment -565853605에 장단점이 있는 옵션 요약을 게시했습니다.