linux / unix에서 WinAPI의 MAX_PATH에 해당하는 것이 있습니까?

linux / unix에서 WinAPI의 MAX_PATH에 해당하는 것이 있습니까?

---

유효한 절대 경로 + 파일 이름을 보유하기에 충분히 큰 char 배열 (C)을 할당하려면 얼마나 커야합니까?

Win32에는 MAX_PATH 정의가 있습니다. Unix / linux에 해당하는 것은 무엇입니까?

---

이 PATH_MAX있지만 약간 문제가 있습니다. realpath (3) 매뉴얼 페이지 의 버그 섹션에서 :

이 함수의 POSIX.1-2001 표준 버전은 출력 버퍼 resolved_path에 적합한 크기를 결정할 수 없기 때문에 설계 상 손상되었습니다 . POSIX.1-2001에 따르면 PATH_MAX 크기의 버퍼는 충분하지만 PATH_MAX 는 정의 된 상수 일 필요는 없으며 pathconf (3)를 사용하여 얻어야 할 수 있습니다 . 그리고 pathconf (3)를 요청하는 것은 실제로 도움이되지 않습니다. 한편으로는 POSIX는 pathconf (3) 의 결과가 메모리를 mallocing하는 데 적합하지 않고 거대 할 수 있으며 다른 한편으로 pathconf (3) 는 -1을 반환 할 수 있다고 경고합니다. PATH_MAX 가 제한되지 않음을 나타냅니다 .

---

지금까지의 다른 답변은 모두 * nix 측면에 대해 올바른 것처럼 보이지만 Windows에서 이에 대한 경고를 추가 할 것입니다.

문서에 의해 (누락으로) 거짓말을했습니다.

MAX_PATH실제로 정의되어 있으며 FAT 또는 FAT32에 저장된 파일에도 적용됩니다. 그러나 \\?\Windows API가 무시 MAX_PATH하고 파일 시스템 드라이버가 스스로 결정하도록하기 위해 경로 이름을 접두사로 지정할 수 있습니다 . 그 후 정의가 모호해집니다.

경로 이름이 실제로 유니 코드 (UTS-16)라는 사실과 "ANSI"API를 사용할 때 내부 유니 코드 이름과의 변환은 현재 코드 페이지를 포함한 여러 요인에 따라 달라진다는 사실을 혼합에 추가합니다. , 혼란에 대한 레시피가 있습니다.

Windows의 규칙에 대한 좋은 설명은 MSDN에 있습니다. 규칙은 내가 여기에 요약 한 것보다 훨씬 더 복잡합니다.

편집 : KitsuneYMG의 의견 덕분에 위와 같이 변경 \\.\했습니다 \\?\.

Windows 경로와 네임 스페이스는 복잡합니다. 어떤 사람들은 그들이 너무 복잡하다고 주장 할 수도 있습니다. 복잡성의 한 가지 원인은 Win32 (및 현재 Win64) API가 Windows NT 기본 시스템 위에있는 하위 시스템이라는 것입니다.

접두사가없는 경로는 가장 광범위한 Windows 플랫폼에서 호환됩니다. 7 비트 ASCII 문자로 제한되는 경우 버전 2.0 이후부터 16 비트 DOS와 호환됩니다 (실제로 DOS 3에있을 수있는 하위 디렉토리가 도입 될 때마다 DOS 1.0에는 루트 디렉토리와 \문자 특별한 의미가 없음).

\\?\접두사는 경로 이름의 균형에 제한을 떨어 뜨리는 효과가 발생 무엇 해당 파일 시스템 드라이버에 그대로 전달되도록 MAX_PATH문자. 긴 경로 이름이 네트워크 공유에도있는 \\?\UNC\server\share\경우 일반 UNC 이름 대신 접두사가있는 확장 UNC 이름을 사용할 수 있습니다 \\server\share\. 이 접두사를 사용하면 Win32 이상 Windows 플랫폼으로 이식성이 제한되지만 레거시 하드웨어에서 16 비트 Windows에 대한 지원이 필요하지 않으면 큰 문제가 아닙니다.

\\.\접두사는 다른 동물이다. Windows에서 모든 파일 폴더에 특수 파일 이름으로 자동 매핑되는 특수하게 명명 된 장치 세트를 넘어서 장치 개체에 액세스 할 수 있습니다. 이러한 특수 이름에는 CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, ​​COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8 및 LPT9가 포함됩니다. 이러한 모든 이름은 확장자가 사용되는지 여부 또는 대문자 또는 소문자가 혼합되어 있는지 여부에 관계없이 특별합니다. 그러나 10 개 이상의 COM 포트가 설치되어있을 수 있습니다. USB 모뎀 또는 USB 직렬 포트 어댑터를 사용하면 각 고유 한 USB 기반 직렬 포트에 고유 한 COMn 이름이 할당되므로 이러한 문제가 빠르게 발생합니다. 50 번째 직렬 포트에 액세스해야하는 경우 \\.\COM50COM50이 아닌 이름으로 만 액세스 할 수 있습니다. COM1과 같은 특별한 이름이 있습니다.

위에서 인용 한 MSDN 페이지에는 구별 권한이 있었으며 원래 답변에 잘못된 접두사를 입력했습니다.

---

글쎄, 적어도 Linux에는 다음이 있습니다.

• PATH_MAX(에서 정의 됨 limits.h)

• FILENAME_MAX(에서 정의 됨 stdio.h)

둘 다 4096내 시스템 (x86 Linux)에서 로 설정되어 있습니다.

업데이트 : : 이에 대한 glibc 매뉴얼의 일부 정보

다음 각 매크로는 시스템에 해당 매개 변수에 대해 고정 된 균일 한 제한이있는 경우에만 limits.h에 정의됩니다. 시스템이 다른 파일 시스템이나 파일이 다른 제한을 갖도록 허용하면 매크로가 정의되지 않습니다. 특정 파일에 적용되는 제한을 찾으려면 pathconf 또는 fpathconf를 사용하십시오.

---

FILENAME_MAX는 ISO C 표준의 일부이며 UNIX 및 Windows에서 작동합니다. 그러나 GNU C 라이브러리 문서에는 다음 경고가 포함되어 있습니다.

"PATH_MAX와 달리이 매크로는 실제 제한이 적용되지 않더라도 정의됩니다. 이러한 경우 일반적으로 그 값은 매우 큰 수입니다. 이것은 항상 GNU 시스템의 경우입니다.

사용법 참고 : 파일 이름을 저장할 배열의 크기로 FILENAME_MAX를 사용하지 마십시오! 배열을 그렇게 크게 만들 수는 없습니다! 동적 할당을 사용하세요. "

---

pathconf()런타임에 알아내는 데 사용할 수 있지만 .NET에 정의 된 PATH_MAX 전처리기도 있습니다 <limits.h>.

---

이 realpath함수를 사용하여 특정 경로에 대해 충분히 큰 버퍼를 할당 할 수 있습니다 . 두 번째 인수로 널 포인터를 전달하면 경로에 충분한 크기의 버퍼가 할당됩니다. man 페이지는 아마도 내가 할 수있는 것보다 더 잘 설명 할 것입니다 :

realpath() expands all symbolic links and resolves references to /./, /../ and extra '/' characters in the null-terminated string named by path to produce a canonicalized absolute pathname. The resulting pathname is stored as a null-terminated string, up to a maximum of PATH_MAX bytes, in the buffer pointed to by resolved_path. The resulting path will have no symbolic link, /./ or /../ components.

If resolved_path is specified as NULL, then realpath() uses malloc(3) to allocate a buffer of up to PATH_MAX bytes to hold the resolved pathname, and returns a pointer to this buffer. The caller should deallocate this buffer using free(3).

http://linux.die.net/man/3/realpath

---

limits.h

/*
 * File system limits
 *
 * NOTE: Apparently the actual size of PATH_MAX is 260, but a space is
 *       required for the NUL. TODO: Test?
 * NOTE: PATH_MAX is the POSIX equivalent for Microsoft's MAX_PATH; the two
 *       are semantically identical, with a limit of 259 characters for the
 *       path name, plus one for a terminating NUL, for a total of 260.
 */
#define PATH_MAX    260

minwindef.h

#define MAX_PATH 260

참고URL : https://stackoverflow.com/questions/833291/is-there-an-equivalent-to-winapis-max-path-under-linux-unix