정확한 크기의 파일을 만드는 방법
모든 시스템에 이를 위한 명령이 있으며, 세 가지 모두 아래에 있습니다. 정확한 바이트 수의 파일을 만들어 주며, 많은 테스트에서는 그것만으로 충분합니다. 이 페이지의 모든 명령은 게시하기 전에 해당 시스템에서 실행해 보았습니다.
짧은 답
Windows: fsutil file createnew name 10485760. Linux: dd if=/dev/zero of=name
bs=1M count=10. macOS: mkfile 10m name. 크기는 바이트 단위이며, 파일 관리자가 세는 방식의 10MB는
10485760입니다.
Windows
fsutil, 그리고 추가 도구가 필요 없는 PowerShell 방식
fsutil은 Windows에 포함되어 있습니다. 크기를 바이트 단위로 받으므로 먼저 숫자를 계산하세요. 10MB는
10485760, 100MB는 104857600, 1GB는 1073741824입니다.
fsutil file createnew test10mb.bin 10485760
Windows 11에서 측정했습니다. 관리자 권한이 아닌 일반 프롬프트에서도 동작하며, 파일은 정확히 10485760바이트가 됩니다.
PowerShell은 다른 프로그램을 호출하지 않고도 같은 일을 할 수 있으며 단위를 이해합니다.
$file = New-Object System.IO.FileStream "test10mb.bin", Create, ReadWrite
$file.SetLength(10MB)
$file.Close()
PowerShell의 10MB는 탐색기가 쓰는 것과 같은 1024 기준 계산으로 10485760바이트를 뜻하므로, 위의 두 명령은 같은 크기를 만듭니다.
Linux
dd, truncate, fallocate, 그리고 사람들이 걸려 넘어지는 차이
dd는 누구나 아는 명령입니다. 바이트를 실제로 씁니다.
dd if=/dev/zero of=test10mb.bin bs=1M count=10
truncate는 즉시 끝나는데, 그것이 함정입니다. Alpine Linux에서 측정해 보면 파일은 10485760바이트로 보고되지만 차지하는 블록은
0개로, 희소 파일입니다. 읽는 쪽은 0으로 채워진 10메가바이트를 받지만, 디스크는 공간을 내준 적이
없습니다.
truncate -s 10M test10mb.bin
업로드 한도를 테스트하기에는 괜찮지만 디스크 할당량을 테스트할 때는 오해를 부릅니다. 공간이 실제여야 할 때는 fallocate를 쓰세요.
fallocate -l 10M test10mb.bin
그리고 압축 프로그램이 다시 줄일 수 없도록 내용이 압축 불가능해야 할 때는:
head -c 10485760 /dev/urandom > test10mb.bin
macOS
희소 파일이 아닌 mkfile, 그리고 이미 아시는 두 가지
macOS에는 mkfile이 포함되어 있습니다. macOS 26.6.2에서 측정하니 10485760바이트에 20480블록이었으므로, 공간은 약속이 아니라
실제로 할당됩니다.
mkfile 10m test10mb.bin
dd와 truncate도 있으며 Linux와 같게 동작합니다.
dd if=/dev/zero of=test10mb.bin bs=1m count=10
truncate -s 10M test10mb.bin
이 방법이 통하지 않는 곳
크기가 맞는 파일이 종류까지 맞는 파일은 아닙니다
위의 방법은 모두 0으로 된 덩어리를 줍니다. 테스트 대상이 크기만 본다면, 예를 들어 업로드 한도, 할당량, 전송이라면 충분합니다. 하지만 무엇이든 그 파일을 여는 순간 충분하지 않게 됩니다.
직접 측정했으며, 여러분도 해 볼 만합니다. fsutil로 2MB 파일을 만들고 photo.png라고 이름 붙인 다음 이미지
라이브러리에 넘겨 보세요. Pillow는 cannot identify image file이라고 답합니다. 그것은 PNG가 아닙니다. 처음부터
아니었고, 이름만 그렇게 말했을 뿐입니다.
이는 들리는 것보다 중요합니다. 테스트가 그다음에 어느 쪽으로 실패하는지가 걸려 있기 때문입니다. 업로드 엔드포인트가 파일을 거부하고, 테스트가 초록색이 되며, 크기 한도가 동작한다고 결론짓게 됩니다. 하지만 크기 때문에 거부한 것이 아닙니다. 바이트가 이미지가 아니어서 거부한 것이며, 테스트하려던 규칙에는 닿지도 않았습니다.
- 파서가 크기 규칙을 살펴보기도 전에 거부한다
- 썸네일 단계가 실패하고 읽게 되는 오류가 썸네일에 관한 것이다
- 백신이나 콘텐츠 검사가 세 번째 이유로 거부한다
- 뷰어가 아무것도 보여 주지 않고, 그것이 버그인지 아무도 알 수 없다
다른 방법
그 형식의 실제 파일, 요청한 크기 그대로
이것이 Testing Files Generator가 하는 일입니다. 파일은 해당 형식의 진짜 파일로, 해당 소프트웨어에서 열리며, 요청한 바이트 수와 정확히 같습니다.
tfg generate --format png --size 10mb --out ./fixtures
형식이 도달할 수 없는 크기를 요청하면 하한과 그 이유를 알려 주는 오류가 나오며, 크기가 틀린 파일은 나오지 않습니다. 형식 페이지에 각 형식과 만들 수 있는 가장 작은 파일이 나와 있습니다.
그리고 한도는 하나가 아니라 세 개의 테스트 케이스이므로, 도구가 세 개 모두 만듭니다.
tfg generate --format pdf --boundary 10mb --out ./edges
10485759, 10485760, 10485761바이트의 파일과, 시스템이 어느 것을 받고 어느 것을 거부해야 하는지 알려 주는 매니페스트를 얻습니다. 활용 사례 페이지에서 이것과 이 도구가 대상으로 하는 네 가지 다른 작업을 다룹니다.
무료 오픈 소스, GPL-3.0. 가입이 필요 없습니다. Windows와 macOS 다운로드는 서명되어 있어 경고 없이 실행됩니다.
그러면 무엇을 써야 할까요?
-
시스템 명령을 쓰세요
아무것도 파일을 열지 않을 때입니다. 크기를 먼저 확인하는 엔드포인트의 크기 한도 테스트, 전송, 할당량, 디스크 가득 참 상황이 그렇습니다. 한 줄이면 되고 이미 설치되어 있습니다.
-
실제 생성기를 쓰세요
무엇이든 파일을 파싱하거나 렌더링하거나 가져오거나 풀 때, 그리고 내일 다른 컴퓨터에서 같은 픽스처가 바이트 단위로 다시 필요할 때입니다.
둘 다 이 페이지에 있는 이유는 둘 다 때로는 맞기 때문입니다. 피해야 할 실수는 두 번째가 필요한 곳에서 첫 번째를 쓰고 초록색 테스트를 증거로 읽는 것입니다.