
내 애플리케이션은 하드코딩된 "Logs" 디렉터리에 로그를 작성하고 있으며 내 애플리케이션의 런타임 디렉터리 아래에 있습니다.
오늘 한 고객이 해당 로그를 다른 장소(다른 컴퓨터)에 보관할 수 있는지 물었습니다.
첫 번째 테스트로 심볼릭 링크를 만들어 보았습니다.
- 신청을 중단했습니다.
- "Logs" 디렉터리를 제거했습니다.
- 내 컴퓨터에서 WSL을 사용하여
ln -s /mnt/c/Temp_Folder/TestLog/ /mnt/c/<Application>/Logs
. - 나는 신청서를 시작했다.
디렉토리에 어떤 로그도 나타나지 않았습니다 C:\Temp_Folder\TestLog\
.
다른 이유가 있습니다.
- Windows 컴퓨터에서 Linux 기술을 사용하려는 것은 완전히 어리석은 생각입니다.
- 작동할 수도 있지만 몇 가지 추가 사항을 고려해야 합니다.
두 번째 선택이길 바라지만, 그렇다면 어떤 점을 고려해야 할까요?
이후 수정괴롭히다님의 답변:ln -s
다음과 같은 Windows 기술을 사용할 수 있다면 왜 WSL을 사용합니까 mklink
? :-)
이 아이디어는 마음에 들지만 안타깝게도 다음 실험에서 볼 수 있듯이 작동하지 않는 것 같습니다.
C:\<Runtime_Dir>mklink /D Logs E:\TestLog\
=> result:
29/03/2024 08:21 <SYMLINKD> Logs [E:\TestLog\]
=> 실제로 Logs
디렉터리 심볼릭 링크가 생성되었지만 애플리케이션을 실행하면 더 이상 로그가 기록되지 않는 것 같습니다(콘솔 창에서 생성되는 것을 볼 수 있지만 파일에는 기록되지 않습니다).
몇 가지 다른 실험: (이전의 교차점에 대한 내용이 기억나지만 자세한 내용은 기억나지 않습니다.)
C:\<Runtime_Dir>mklink /D /J Logs E:\TestLog\
Local volumes are required to complete the operation.
C:\<Runtime_Dir>mklink /D /H Logs E:\TestLog\
The system cannot find the path specified.
C:\<Runtime_Dir>mklink /J Logs E:\TestLog\
Local volumes are required to complete the operation.
몇 가지 추가 실험 후 Edit2:
다른 드라이브를 참조할 때는 작동하지 않는 것 같지만, 여기에서 볼 수 있듯이 같은 컴퓨터의 다른 디렉터리를 참조할 때는 작동하는 것 같습니다.
C:\<Runtime_Dir>mklink /D Logs C:\Temp_Folder\TestLog\
symbolic link created for Logs <<===>> C:\Temp_Folder\TestLog\
C:\<Runtime_Dir>mklink /D /J Logs C:\Temp_Folder\TestLog\
Junction created for Logs <<===>> C:\Temp_Folder\TestLog\
두 경우 모두 로그가 생성되고 있음을 확인할 수 있습니다!
즉, 문제는 Windows 심볼릭 링크/접합이 작동하지 않는 것이 아니라 심볼릭 링크/접합이 다른 드라이브를 참조한다는 사실에 있습니다.
Windows에서 드라이브를 만드는 방법에는 두 가지, 심지어 세 가지가 있다는 것을 기억하고 있습니다(드라이브 매핑, 대체(?) 및 또 다른 방법(???), 이 모든 것이 내 머리 속에 매우 흐릿합니다). 심볼릭 링크/접합 스토리가 한 종류의 드라이브에서는 작동하지만 다른 종류의 드라이브에서는 작동하지 않을 수 있는지, 그리고 이 문제를 해결할 수 있는 방법이 있는지 여부.
답변 후 Edit3u1686_중력:
UNC 경로를 사용하고 "올바른" 동작을 구성하더라도 여전히 작동하지 않는 것 같습니다.
fsutil behavior query symlinkEvaluation
Local to local symbolic links are enabled.
Local to remote symbolic links are enabled. => That's the one, isn't it?
Remote to local symbolic links are disabled.
Remote to remote symbolic links are disabled.
C:\<Runtime_Dir>mklink /D Logs \\petrvs01\Log\TestLog\
symbolic link created for Logs <<===>> \\petrvs01\Log\TestLog\
링크가 생성되지만 거기에는 로그 파일이 생성되지 않습니다.
그래서 저는 제가 여기에서 올바른 길을 가고 있다고 생각하여 또 다른 테스트를 수행하기로 결정했습니다. 즉, Windows 탐색기를 사용하여 Logs
디렉터리/symlink/junction에 들어가서 탐색기의 상황에 맞는 메뉴를 사용하여 간단한 텍스트 파일을 생성하는 것입니다. 다음 오류 메시지로 인해 작동하지 않습니다.
나는 지금까지 세 가지를 배웠습니다.
- Windows에서 심볼릭 링크를 생성하려면
mklink
WSL의ln -s
. 이를 위해 관리자 권한으로 명령 프롬프트를 엽니다. - 원격 디렉터리에 대한 심볼릭 링크/접합을 생성하려면 드라이브 문자가 아닌 UNC 경로를 사용해야 합니다.
- 원격 디렉토리에서 심볼릭 링크/접합을 생성하기 위한 권한은 명령을 사용하여 확인
fsutil
됩니다fsutil behavior query symlinkEvaluation
.
다음으로 배워야 할 점: 심볼릭 링크/접합 대상 권한을 어디에서 확인할 수 있습니까? 누구든지 아이디어가 있나요?
답변1
Linux의 Symlink는 Windows와 다르게 구현됩니다.
- Windows에서 심볼릭 링크는 커널 호출에 의해 구현되고 조작되는 파일 테이블 항목입니다.
- Linux에서 심볼릭 링크는 내용이 대상 경로인 특수 플래그가 있는 단순한 텍스트 파일입니다. (경로가 유효할 필요도 없습니다.)
이는 WSL(Linux용 Windows 하위 시스템)을 통해 생성된 기호 링크(또는 기호 링크) 뒤에 Windows가 올 수 없음을 의미합니다.
Windows는 다음을 사용하여 심볼릭 링크를 만듭니다. mklink 명령.
자세한 내용은 기사를 참조하세요
Windows에서 심볼릭 링크(Symlink라고도 함) 생성에 대한 전체 가이드.
"액세스 거부" 문제에 대해서는 게시물에서 인용합니다. 네트워크 드라이브에 심볼릭 링크 생성 의 일부 GambleNerd의 답변:
액세스 거부 수정
mklink /D
관리자로 명령을 실행하고Link
명령의 일부가 UNC 네트워크 경로이고Access Denied
오류 메시지가 표시되면 아래에 따라 이 문제를 잠재적으로 해결하십시오.
- 거기 서버에(및/또는 Windows 클라이언트 PC에서 명령을 실행할 때 액세스 거부 오류 메시지가 표시됨)명령의 일부
Link
가 있는 경우 서버에서 관리자로 이 명령을 실행하십시오.fsutil behavior query SymlinkEvaluation
- 표시되면
Remote to remote symbolic links are disabled.
다음 명령을 실행하십시오.fsutil behavior set SymlinkEvaluation R2R:1
- MKLINK 명령을 실행하고 Windows Server 자체 또는 Windows 클라이언트 PC에서 액세스가 거부된 위치에서 이를 실행할 수 있습니다.
- 이제 명령을 다시 실행해 보세요. 성공적으로 작동하기를 바랍니다.
링크 참조: mklink에서 액세스가 거부되었습니다.
답변2
다른 컴퓨터의 위치를 참조하여 Windows 컴퓨터에서 Linux와 유사한 심볼릭 링크를 사용할 수 있는 방법이 있습니까?
가능하지만 드라이브 문자가 반드시 전역일 필요는 없으므로 UNC 경로를 사용해야 합니다. 물리적 볼륨에는 전역 할당이 있지만 각 로그온 세션은 그 위에 자체 개인 매핑을 가질 수 있습니다(예: 사용자 1은 Y를 가질 수 있음) :\는 한 위치를 나타내고 사용자 2는 다른 위치를 나타내도록 할 수 있습니다). Linux(pam_namespace)에서 각 사용자가 자신만의 "마운트 네임스페이스"를 갖는 것과 비슷하다고 생각하세요.
특히 모든 "매핑된 네트워크 공유" 드라이브 문자는 로그온 세션에만 적용되며 심볼릭 링크를 따를 때 커널 컨텍스트에서 이해되지 않습니다. 따라서 대상이 다른 시스템에 있는 경우 원시 UNC 경로를 사용해야 합니다.
cmd /c mklink /d Logs \\FileServer\Trash\Logs
또한 로컬-원격 심볼릭 링크 평가가 를 통해 비활성화되지 않았는지 확인해야 합니다 fsutil behavior query symlinkEvaluation
.
심볼릭 링크/접합 대상 권한을 어디에서 확인할 수 있나요? 누구든지 아이디어가 있나요?
icacls
대상에서 실행 하거나 탐색기에서 대상을 마우스 오른쪽 버튼으로 클릭하고 "속성 > 보안"으로 이동합니다.
icacls \\FileServer\Trash\Logs
또한 Windows의 심볼릭 링크 및 접합~할 수 있다을 사용하여 확인할 수 있는 자체 권한이 있습니다 icacls Logs /l
. 링크가 처음에는 일반 디렉토리와 동일한 권한을 상속하므로 이것이 문제가 될지는 의심스럽습니다. 하지만 확인해 볼 가치가 있습니다.
먼저 파일/폴더 생성이 작동하는지 확인하세요.없이즉, UNC 경로(또는 매핑된 드라이브, 차이 없음)를 통해 직접적으로 심볼릭 링크가 관련되고 해당 작업이 완료된 후에만 심볼릭 링크를 통해 동일한 작업을 시도하십시오.
애플리케이션이 자체 자격 증명(서비스 계정)을 사용하여 서비스로 실행되는 경우 해당 계정에 권한을 부여해야 한다는 점을 잊지 마십시오. "NetworkService"로 실행 중인 경우에는 권한이 부여되어야 합니다.기계계정(FOOBAR$). (그리고 "LocalService"로 실행 중인 경우에는 네트워크 공유 액세스가 불가능합니다.)