Linux/unix에 WinAPI의 MAX_PATH와 동등한 것이 있는가?

Linux/unix에 WinAPI의 MAX_PATH와 동등한 것이 있는가?

유효한 절대 경로+파일 이름을 저장할 수 있을 정도로 크기가 보장되는 Char 어레이(C)를 할당하려면 얼마나 커야 하는가?

Win32에는 MAX_PATH 정의가 있다.유닉스/리눅스에 해당하는 것은?

라는 것이 있다.PATH_MAX그러나 그것은 약간 문제가 있다.Realpath(3) man 페이지의 버그 섹션에서:

이 기능의 POSIX.1-2001 표준 버전은 출력 버퍼 resolided_path에 적합한 크기를 결정할 수 없기 때문에 설계에 의해 깨진다.POSIX.1-2001에 따르면 PATH_MAX 질량의 버퍼는 정의된 상수일 필요는 없으며, PATH_MAX는 경로conf(3)를 사용하여 얻어야 할 수도 있다.그리고 POSIX는 다른 한편으로는 경로충돌의 결과가 거대하고 만로킹 메모리에 적합하지 않을 수 있다고 경고하고, 다른 한편으로는 경로충돌(3)이 -1을 반환하여 PATH_MAXIS가 경계하지 않았음을 의미할 수 있기 때문에 경로충돌(3)을 묻는 것은 실제로 도움이 되지 않는다.

지금까지 나온 다른 답변들은 모두 *nix 측면에 대해 옳은 것 같지만, 윈도우에 그것에 대한 경고를 추가할 것이다.

서류상으로는 거짓말을 하셨습니다

MAX_PATH실제로 정의되며, FAT 또는 FAT32에 저장된 파일에도 적용될 수 있다.그러나 경로 이름은 다음에 의해 접두사가 될 수 있다.\\?\Windows API에 무시하라고 지시하다MAX_PATH그리고 파일 시스템 드라이버가 스스로 결정하도록 한다.그 후, 정의가 모호해진다.

여기에 경로 이름이 실제로 유니코드(well, UTS-16)라는 사실과 "ANSI" API를 사용할 때 내부 유니코드 이름과의 변환은 현재 코드 페이지를 포함한 여러 요인에 의해 좌우되며 혼동의 비법이 있다는 사실을 더한다.

Windows용 규칙에 대한 좋은 설명은 MSDN에 있다.규칙은 내가 여기서 요약한 것보다 훨씬 더 복잡하다.

편집: 변경됨\\.\로\\?\킷츠네의 코멘트 덕택에.YMG.

윈도우 경로와 네임스페이스는 복잡하다.어떤 사람들은 그들이 너무 복잡하다고 주장할 수도 있다.복잡성의 한 원천은 Win32(현재 Win64) API가 윈도 NT 네이티브 시스템 위에 놓여 있는 서브시스템이라는 점이다.

A path without any prefix is compatible across the widest range of Windows platforms. If it is restricted to 7-bit ASCII characters, then it is compatible with 16-bit DOS since version 2.0 or so (whenever subdirectories were introduced, which might actually have been in DOS 3; but DOS 1.0 only had root directories and the \ character had no special meaning).

The \\?\ prefix causes the balance of the path name to be passed on verbatim to the appropriate file system driver, which is what produces the effect of dropping the restriction to MAX_PATH characters. If the long path name is also on a network share, then you can use an extended UNC name for it with the prefix \\?\UNC\server\share\ instead of the normal UNC name \\server\share\. Using this prefix restricts portability to Win32 and later Windows platforms, but unless you require support for 16-bit Windows on legacy hardware, that isn't a big issue.

The \\.\ prefix is a different animal. It allows access to device objects beyond the set of specially named devices that are automatically mapped by Windows as special file names into every file folder. Those special names include CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, and LPT9. Note that all of those names are special whether or not an extension is used, or in any mix of upper or lower case. But it is possible that you have 10 or more COM ports installed. This happens quickly if you play with USB modems, or USB serial port adapters, since each unique USB-based serial port will be assigned a distinct COMn name. If you need to access the 50th serial port, then you can only do so with the name \\.\COM50 because COM50 is not a special name like COM1 is.

The MSDN page I cited above had the distinction right, I simply typed the incorrect prefix in my original answer.

Well, on Linux at least, there is:

• PATH_MAX (defined in limits.h)

• FILENAME_MAX (defined in stdio.h)

both of these are set to 4096 on my system (x86 Linux).

Update: : Some info from the glibc manual on this

Each of the following macros is defined in limits.h only if the system has a fixed, uniform limit for the parameter in question. If the system allows different file systems or files to have different limits, then the macro is undefined; use pathconf or fpathconf to find out the limit that applies to a particular file

한계.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

미니윈드h

#define MAX_PATH 260

당신은 그것을 사용할 수 있다.realpath특정 경로에 대해 충분히 큰 버퍼를 할당하는 기능.두 번째 인수로 Null 포인터를 전달하면 경로에 충분한 크기의 버퍼가 할당된다.맨 페이지는 아마 내가 할 수 있는 것보다 더 잘 설명해줄 것이다.

realpath()는 모든 심볼 링크를 확장하고 경로에 의해 명명된 null-message 문자열에서 /./, /../ 및 추가 '/' 문자로 참조를 확인하여 표준화된 절대 경로 이름을 생성한다.결과 경로 이름은 null-terminated_path가 가리키는 버퍼에 최대 PATH_MAX 바이트의 null-terminated 문자열로 저장된다.결과 경로에는 /./ 또는 /../ 구성 요소가 없다.

resolided_path가 NULL로 지정된 경우 realpath()는 malloc(3)를 사용하여 확인된 경로 이름을 보유하기 위해 최대 PATH_MAX 바이트의 버퍼를 할당하고 포인터를 이 버퍼에 반환한다.호출자는 무료(3)를 사용하여 이 버퍼의 할당을 해제해야 한다.

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

FILENAME_MAX는 ISO C 표준의 일부로서 UNIX와 Windows에서 작동한다.그러나 GNU C 라이브러리 문서에는 다음과 같은 경고가 포함되어 있다.

"PATH_MAX와 달리 이 매크로는 실제 부과한 한도가 없더라도 정의된다.그러한 경우에 그 가치는 전형적으로 매우 큰 숫자다.GNU 시스템에서는 항상 그러하다.

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

사용할 수 있다pathconf()런타임에 알아낼 수 있지만, PATH_MAX 전처리기 정의도 있다.<limits.h>.

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