Testing Files Generator
Türkçe

Tam boyutta dosya nasıl oluşturulur

Her sistemin bunun için bir komutu var ve üçü de aşağıda. Size tam doğru bayt sayısında bir dosya verirler - ve birçok test için gereken tek şey budur. Bu sayfadaki her komut, yayımlanmadan önce ait olduğu sistemde çalıştırıldı.

Kısa yanıt

Windows: fsutil file createnew name 10485760. Linux: dd if=/dev/zero of=name bs=1M count=10. macOS: mkfile 10m name. Boyutlar bayt cinsindendir ve dosya yöneticinizin saydığı gibi 10 MB, 10485760'tır.

Windows

fsutil ve fazladan hiçbir şey gerektirmeyen bir PowerShell sürümü

fsutil Windows ile gelir. Boyutu bayt cinsinden alır, bu yüzden sayıyı önce hesaplayın - 10 MB 10485760, 100 MB 104857600, 1 GB 1073741824.

fsutil file createnew test10mb.bin 10485760

Windows 11'de ölçüldü: sıradan bir istemden çalışır, yükseltilmiş bir istem gerektirmez ve dosya tam 10485760 bayt çıkar.

PowerShell aynı şeyi başka bir programı çağırmadan yapabilir ve birimleri anlar:

$file = New-Object System.IO.FileStream "test10mb.bin", Create, ReadWrite
$file.SetLength(10MB)
$file.Close()

PowerShell'de 10MB, Gezgin'in kullandığı aynı 1024 tabanlı sayımla 10485760 bayt demektir, yani yukarıdaki iki komut aynı boyutu üretir.

Linux

dd, truncate ve fallocate ve insanları yakalayan fark

dd herkesin bildiğidir. Baytları gerçekten yazar:

dd if=/dev/zero of=test10mb.bin bs=1M count=10

truncate anlıktır ve tuzak da budur. Alpine Linux'ta ölçüldü: dosya 10485760 bayt bildirir ve sıfır blok kaplar - bir seyrek dosyadır. Onu okuyan her şey on megabayt sıfır alır ama disk alanı hiç vermemiştir:

truncate -s 10M test10mb.bin

Bu, yükleme sınırını sınamak için iyidir ve disk kotasını sınamak için yanıltıcıdır. Alan gerçek olmalıysa başvurulacak olan fallocate'tir:

fallocate -l 10M test10mb.bin

Ve içerik, bir arşivleyici onu yeniden sıkıştıramasın diye sıkıştırılamaz olmalıysa:

head -c 10485760 /dev/urandom > test10mb.bin

macOS

seyrek olmayan mkfile ve zaten bildiğiniz iki komut

macOS mkfile ile gelir. macOS 26.6.2'de ölçüldü: 10485760 bayt ve 20480 blok, yani alan söz verilmek yerine gerçekten ayrılır:

mkfile 10m test10mb.bin

dd ve truncate da var ve Linux'taki gibi davranır:

dd if=/dev/zero of=test10mb.bin bs=1m count=10
truncate -s 10M test10mb.bin

Bunun işe yaramadığı yer

Doğru boyutta bir dosya doğru türde bir dosya değildir

Yukarıdakilerin hepsi size bir sıfır bloğu verir. Test edilen şey yalnızca boyuta bakıyorsa - yükleme sınırı, kota, aktarım - bu yeterlidir. Bir şey dosyayı açtığı anda yeterli olmaktan çıkar.

Ölçüldü ve kendiniz yapmaya değer: fsutil ile 2 MB'lık bir dosya yapın, adını photo.png koyun ve bir görüntü kitaplığına verin. Pillow cannot identify image file yanıtını verir. PNG değil. Hiç de olmadı - yalnızca adı öyle diyordu.

Bu, göründüğünden daha önemlidir, çünkü testin bundan sonra hangi yönde başarısız olduğu belirleyicidir. Yükleme endpoint'iniz dosyayı reddeder, testiniz yeşile döner ve boyut sınırının çalıştığı sonucuna varırsınız. Onu boyut yüzünden reddetmedi. Baytlar resim olmadığı için reddetti ve sınamak istediğiniz kurala hiç ulaşılmadı.

Öbür yol

O biçimden gerçek bir dosya, tam istediğiniz boyutta

Testing Files Generator'ın yaptığı budur. Dosya biçiminin gerçek bir örneğidir - ait olduğu programda açılır - ve istediğiniz tam bayt sayısındadır, bayta kadar:

tfg generate --format png --size 10mb --out ./fixtures

Bir biçimin ulaşamayacağı bir boyut isteyin, alt sınırı ve nedenini adlandıran bir hata alırsınız, asla yanlış boyutta bir dosya değil. Biçimler sayfası her biçimi üretebildiği en küçük dosyayla listeler.

Ve bir sınır bir değil üç test durumudur, bu yüzden araç üçünü de kurar:

tfg generate --format pdf --boundary 10mb --out ./edges

Bu size 10485759, 10485760 ve 10485761 bayt ile hangilerini sisteminizin kabul etmesi, hangilerini reddetmesi gerektiğini söyleyen bir manifest verir. Kullanım senaryoları sayfası bunu ve aracın yapıldığı dört işi daha anlatır.

Ücretsiz ve açık kaynak, GPL-3.0. Kayıt gerekmez. Windows ve macOS indirmeleri imzalıdır ve uyarı vermeden başlar.

Peki hangisini kullanmalı?

İkisi de bu sayfada çünkü ikisi de zamanın bir kısmında haklı. Kaçınılması gereken hata, ikincisinin gerektiği yerde birincisini kullanmak ve yeşil testi kanıt saymaktır.