İki yüz dosyadan biri neden kopyalanmıyor

İki yüz dosyalık bir kopyalama tek bir hatayla ve işe yaramaz bir mesajla biter. Sebep neredeyse her zaman içerik değil addır ve bilinmeye değer yalnızca altı kadar sebep vardır.

Windows'un kabul etmediği karakterler

Windows dosya adlarında dokuz karakter yasaktır: \ / : * ? " < > |. macOS ve Linux çoğuna izin verir — Linux'ta yalnızca / yasaktır — yani 3Ç: son?.xlsx adlı bir dosya Mac'te gayet meşrudur ve bir Windows diskine hiç yazılamaz.

İki kural daha insanları yakalar. Windows sondaki boşlukları ve noktaları sessizce siler, yani rapor .pdf ve rapor.. yolculuktan sağ çıkmaz. Bir de tarihsel aygıt dosyaları için ayrılmış adlar vardır: CON, PRN, AUX, NUL, COM1–COM9, LPT1–LPT9 — uzantılı ya da uzantısız. con.txt adlı bir dosya Windows'ta var olamaz; ilk karşılaşıldığında gerçekten şaşırtıcı bir arızadır.

260 karakterlik yol sınırı

Windows tarihsel olarak tam yolu — sürücü, her klasör, dosya adı, uzantı — 260 karakterle sınırlamıştır. Dosya adını değil: yolun tamamını. Gayet çalışan bir klasör ağacının, birinin onu sizden iki seviye daha derine çıkardığı anda bozulmasının ve hatanın bir zip'teki bazı dosyalarda çıkıp diğerlerinde çıkmamasının sebebi budur.

Modern Windows'ta uzun yol desteği vardır ama varsayılan olarak kapalıdır ve her uygulama buna uymaz. Güvenilir çözüm köke daha yakın bir yere çıkarmaktır: arşiviniz daha başlamadan Users, bir ad, Masaüstü ve üç proje klasöründen geçen bir yol yerine C:\tmp\.

Türkçe karakterler ve zip içindeki bozulma

Zip biçimi başlangıçta dosya adları için bir kodlama belirtmedi. Arşivleyiciler adları yerel kod sayfasında yazdı; yani Türkçe bir Windows makinesinde yapılan zip, çalışma-özeti.docx'i Windows-1254 ile saklar — ve UTF-8 varsayan herhangi bir makinede bu, çalışma olarak çıkar. Dosya sağlamdır; okunamayan yalnızca adıdır.

Modern arşivleyiciler bir UTF-8 bayrağı koyar ve çoğunlukla doğru yapar, ama Windows Gezgini'nin yerleşik zip desteği iki yönde de zayıf halkadır. Sistemini bilmediğiniz birine ASCII dışı adlar içeren bir arşiv gönderiyorsanız ya 7-Zip ile yapıp UTF-8'i zorlayın ya da arşivlemeden önce adları ASCII'ye çevirin.

İkinci, daha ince bir Türkçe sorunu var: noktalı ve noktasız i. Büyük/küçük harf duyarsız sistemler I↔i eşler, ama Türkçede I↔ı ve İ↔i vardır. Bir adı Türkçe yerel ayar kurallarıyla büyüten yazılım file.txt'i FİLE.TXT'ye çevirebilir ve FILE.TXT bekleyen bir arama başarısız olur. Nadirdir ve olduğunda tam bir muammadır.

Aynı görünen ama aynı olmayan iki ad

Unicode, aksanlı bir karakteri iki şekilde yazabilir: tek bir kod noktası olarak (ö) ya da düz harf artı birleşen işaret olarak (o + ¨). macOS dosya adlarını geleneksel olarak ayrışmış biçimde saklar; Windows ve Linux birleşik olanı kullanır. İkisi ekranda birebir aynı görünür ve farklı bayt dizileridir.

Sonuç: Mac'ten senkronlanan bir klasör aynı dosyanın iki kopyası gibi görünen şeyler gösterebilir, görsel.png arayan bir betik tam orada duran görsel.png'yi bulamaz ve bir kopya temizleyici hiç kopya görmez. Bir ad doğru görünüyorsa ve hiçbir şey onunla eşleşmiyorsa cevap budur.

Büyük/küçük harf duyarlılığı da eklenir. Linux Foto.jpg ile foto.jpg'yi iki dosya sayar; Windows ve macOS varsayılan olarak saymaz. Böyle bir klasörü Mac'e kopyalamak birini kaybettirir ve kopyalama başarılı der.

Bunların hiçbirine yol açmayacak adlar

1. Bir sistem sınırını geçen her şeyde ASCII'de kalın — harf, rakam, tire, alt çizgi, nokta.
2. Boşluk yerine tire kullanın. Boşluklar dosya yöneticilerinde sorunsuz yaşar ve betiklerde, URL'lerde, komut satırlarında bitmeyen tırnak sorunları çıkarır.
3. Tarihle başlayın, önce ISO: 2026-09-08-ceyrek-raporu.pdf. Yeryüzündeki her sistemde ada göre kronolojik sıralanır.
4. Adları yaklaşık 80 karakterin altında, klasör ağaçlarını sığ tutun ki kimse yol sınırına çarpmasın.
5. İki dosyayı ayırt etmek için asla yalnızca büyük/küçük harfe güvenmeyin. Biri kaybolur.
6. Saat ya da oran yazmak için ada iki nokta koymayın. En yaygın yasak karakterdir ve saati doğal biçimde yazmaktan gelir.

Diğer rehberler