Claude: dosya başka bir programda açık hatası

"Dosya başka bir programda açık" hatası neden çıkar

Claude size dosyanın başka bir programda açık olduğunu söylüyorsa, bu bir Claude arızası değil, Windows'un dosya kilidi kuralıdır. Windows'ta bir dosyayı açan program, o dosyayı başkasının okumasına veya değiştirmesine izin verip vermediğini açılış anında bildirir, çekirdek de bu kararı zorla uygular. Excel bir çalışma kitabını açtığında ya da Claude'un kurulum programı kendi dosyalarını yenisiyle değiştirmeye çalıştığında, dosyayı elinde tutan süreç kapanmadan işlem tamamlanamaz. Çözüm bu yüzden hemen her zaman aynıdır: dosyayı tutan programı tam olarak kapatın, süreç listesinden gerçekten kapandığını doğrulayın, sonra tekrar deneyin.

Mesaj ekranınızda birkaç farklı biçimde görünebilir, çünkü bu metni Claude değil Windows üretir ve cümle Windows sürümüne göre değişir. Anlamı hepsinde aynıdır: istenen dosya şu anda başka bir süreç tarafından kullanılıyor. Windows bu hata sınıfına paylaşım ihlali (sharing violation) adını verir. Ekranınızdaki cümleyi anlamına göre eşleştirin, çünkü aynı kök neden üç ayrı yerde karşınıza çıkar ve her birinin adımları farklıdır.

Windows zorunlu kilit alır, Linux ise tavsiye kilidi

Windows'ta dosya açan her çağrı bir paylaşım modu taşır. Program, "ben bu dosyayı açarken başkası okuyabilir", "yazabilir" ya da "silebilir" seçeneklerinden hangilerine izin verdiğini söyler. İzin verilmeyen bir işlemi deneyen ikinci süreç doğrudan hata alır. Bu karar işletim sisteminin içinde uygulanır, yani ikinci programın kibar davranmayı seçmesi gerekmez, seçeneği yoktur. Buna zorunlu kilit (mandatory locking) denir.

Linux'ta open() çağrısının böyle bir alanı yoktur. Kilit istemek ayrı bir iştir ve flock() ya da fcntl() ile yapılır. Bu kilitler tavsiye niteliğindedir (advisory): yalnızca iki tarafın ikisi de kilidi sorarsa işe yarar. Kilidi sormayan bir süreç aynı dosyayı açar ve yazar, çekirdek araya girmez.

İkinci fark silmede. Linux'ta dosya adı ile dosya içeriği ayrı şeylerdir: rm bir dizin girdisini kaldırır, içeriği tutan inode ise onu açık tutan son süreç kapanana kadar yaşar. Bu yüzden okunmakta olan bir dosyayı silmek ya da rename() ile üstüne yeni sürümünü yazmak hata vermez. Windows'ta açık bir dosyayı silmek veya üstüne yazmak varsayılan olarak yasaktır, çünkü ad ile içerik aynı kilide bağlıdır. Claude tarafında gördüğünüz her üç durum da bu tek farkın sonucudur.

Durum 1: masaüstü uygulaması güncellenirken hata veriyor

Güncelleyici, çalışan uygulamanın dosyalarını yenileriyle değiştirmek ister. Uygulama hâlâ ayaktaysa o dosyalar kilitlidir ve güncelleme yarıda kalır. En sık sebep şu: pencerenin köşesindeki çarpı işaretine basmak uygulamayı kapatmaz. Pencere gizlenir, süreç sistem tepsisinde, yani saatin yanındaki simge alanında çalışmaya devam eder. Güncelleyici açısından uygulama açıktır.

1. Sistem tepsisindeki simgeye sağ tıklayın ve çıkış seçeneğini kullanın. Pencereyi kapatmak yetmez.
2. Görev Yöneticisi'ni açın (Ctrl+Shift+Esc) ve süreçleri ada göre sıralayın. Masaüstü uygulaması birden çok yardımcı süreçle çalıştığı için listede aynı ada sahip birkaç satır görebilirsiniz.
3. Kalan satır varsa görev sonlandır ile kapatın. Hepsi gitmeli.
4. On saniye bekleyin, sonra kurulumu yeniden başlatın. Antivirüs taraması veya arama dizini yeni yazılan bir dosyayı kısa süre elinde tutabilir, bu yüzden hemen ardından denemek aynı hatayı verebilir.

Aynı kontrolü komut satırından da yapabilirsiniz. PowerShell'i açın:

tasklist | findstr /i "claude"
Stop-Process -Id <PID>

İlk komut adında claude geçen süreçleri listeler. Çıktı boşsa uygulama gerçekten kapanmıştır ve hatanın kaynağı başka bir şeydir. Çıktı satır döndürüyorsa, satırdaki PID numarasını ikinci komuta yazarak o süreci kapatın.

Kurulum dosyasını yönetici olarak çalıştırmak bu hatayı çözmez, çünkü sorun bir izin sorunu değil. Yönetici hakkı size kilitli bir dosyayı değiştirme yetkisi vermez. İşe yarayan kaba yöntem yeniden başlatmaktır: makine açılırken hiçbir tutucu kalmaz, kurulum da ilk denemede geçer.

Durum 2: Excel veya Word dosyası eklerken hata veriyor

Excel ve Word, açık bir belgeyi başka süreçlerin yazmasına kapatır. Excel ayrıca aynı klasörde ~$ ile başlayan gizli bir kilit dosyası oluşturur. Belgeyi sohbete eklediğinizde okuma isteği bu kilide çarpar ve dosya yüklenmez.

• Belgeyi kapatın, sadece pencereyi küçültmeyin. Küçültülmüş bir Excel penceresi kilidi hâlâ tutar.
• Excel veya Word'ü tümüyle kapatın. Bazı eklentiler belge kapandıktan sonra bile süreci ayakta bırakır, bu yüzden Görev Yöneticisi'nde kontrol edin.
• Klasörde kalmış bir kilit dosyası olup olmadığına bakın. Komut isteminde klasöre gidip dir /a "~$*" yazın. Program çökmüşse bu dosya geride kalabilir ve kapattığınız halde hata sürebilir. Böyle bir artık dosyayı silmek güvenlidir.
• OneDrive, Dropbox ya da başka bir eşitleme istemcisi dosyayı yüklerken kısa süre elinde tutar. Eşitlemeyi duraklatıp yeniden deneyin.
• Dosya OneDrive'da yalnızca bulutta duruyorsa, önce yerel kopyasını indirin. Eklenecek dosyanın diskte gerçekten bulunması gerekir.

En hızlı geçici çözüm kopyalamaktır. Dosyanın bir kopyasını masaüstüne alın ve kopyayı ekleyin. Kopyayı hiçbir program açmadığı için kilit yoktur. Bu, bir toplantının ortasındayken kaybedilecek zamanı sıfıra indirir.

Dosyayı hangi programın tuttuğunu göremiyorsanız, Windows'un Kaynak İzleyicisi bunu söyler. Başlat menüsüne resmon yazıp açın, CPU sekmesine geçin ve tanıtıcı arama alanına (İngilizce arayüzde Associated Handles) dosya adını yazın. Sonuç listesi dosyayı açık tutan süreçlerin adını verir. Beklemediğiniz bir ad görmek normaldir: yedekleme araçları ve virüs tarayıcıları da dosya açar.

Durum 3: Claude Code veya MCP dosya sunucusu yazarken hata veriyor

Claude Code ve MCP (model context protocol) dosya sunucuları bir dosyayı güncellerken genellikle önce geçici bir dosya yazar, sonra onu asıl dosyanın üstüne taşır. Bu yöntem Linux'ta atomiktir ve dosya okunurken bile çalışır. Windows'ta hedef dosyayı başka bir süreç açık tutuyorsa taşıma başarısız olur, araç da dosyayı yazamadığını bildirir. Düzenlemeyi yeniden denemek işe yaramaz, çünkü kilit hâlâ oradadır.

Metin düzenleyicilerin çoğu dosyayı sürekli açık tutmaz: okur, tutucuyu bırakır. Bu yüzden asıl suçlu genellikle düzenleyici değil, çalışmaya devam eden bir süreçtir. Derleme aracı ya da dosya izleyici çıktı dosyasını açık tutar, geliştirme sunucusu kendi log dosyasını tutar. Terminalde arka planda bıraktığınız işleri durdurup düzenlemeyi tekrar deneyin. Git de aynı duvara çarpar: kilitli bir dosya varken git checkout veya git pull dosyayı silemediğini söyleyen bir hata verir, ve çözüm yine dosyayı tutan süreci kapatmaktır.

WSL kullanıyorsanız dosyanın nerede durduğu sonucu değiştirir. /mnt/c altındaki yollar Windows dosya sistemine gider ve aynı paylaşım kurallarına tabidir, yani Excel'de açık bir dosyayı WSL içinden de değiştiremezsiniz. Projeyi WSL'in kendi dosya sisteminde, örneğin /home altında tutarsanız kilitler Linux kurallarına göre işler ve bu sınıf hata ortadan kalkar. Hangi aracın hangi dosyaya dokunduğunu bilmek de yardımcı olur, çünkü Cowork ile Claude Code dosyalarınıza farklı yerlerden erişir ve ikisinin çalışma dizini aynı olmak zorunda değildir.

Aynı iş bir Linux sunucusunda neden hata vermez

Bir Linux VPS'te dosya değiştirmek bu hatayı üretmez. Paket yöneticisi, çalışan bir servisin ikili dosyasını sorunsuz değiştirir. Eski sürüm silinmiş bir inode olarak bellekte yaşamaya devam eder, servis kapanana kadar da çalışır. Bu yüzden yükseltmeden sonra sistem size servisi yeniden başlatmanızı söyler: yeni dosya diskte, çalışan süreç ise hâlâ eski içeriği tutuyor. Aynı mantık log dosyalarında da geçerlidir, log döndürme dosyayı taşır ve servise bir sinyal gönderir.

Bir dosyayı kimin açık tuttuğunu görmek için iki araç yeter:

lsof /var/log/nginx/access.log
fuser -v /var/log/nginx/access.log

İkisi de dosyayı açan süreçlerin PID ve kullanıcı bilgisini yazar. lsof çıktısı boş dönerse dosyayı hiçbir süreç tutmuyordur. Linux'ta bu bilgi tanı içindir, engel değildir: dosyayı yine de silebilir ve üstüne yazabilirsiniz.

Bu esnekliğin bedeli var. Linux sizi durdurmadığı için, aynı dosyaya yazan iki kopya birbirinin verisini bozabilir. Kilidi kendiniz istemeniz gerekir:

flock -n /tmp/yedek.lock -c '/usr/local/bin/yedek.sh'

-n bayrağı, kilit başkasındaysa beklemeden çıkmayı söyler. Böylece zamanlanmış bir görev üst üste binmez. Windows bu korumayı size sormadan verir ve karşılığında güncellemeyi durdurur. Linux hiç sormaz ve korumayı yazmayı size bırakır. Hangi tarafta çalıştığınızı bilmek, hatanın neden orada çıkıp burada çıkmadığını açıklar.

Masaüstündeki kilit sorunlarından tümüyle kurtulmak isterseniz, işi bir Linux makineye taşımak gerçek bir seçenek. Claude'un Linux masaüstü ve komut satırı kurulumu aynı hesapla çalışır, ve sunucu tarafındaki günlük işler için sistem yöneticilerinin Claude'u kullanma biçimi bu akışı nasıl kurduklarını gösterir.

Tekrar yaşamamak için

1. Uygulamaları pencereden değil çıkış menüsünden kapatın. Sistem tepsisi simgesi duruyorsa uygulama açıktır.
2. Bir belgeyi eklemeden önce onu kapatın, ya da kopyasını ekleyin.
3. Üzerinde Claude'a düzenleme yaptırdığınız dosyaları Excel veya Word gibi dosyayı kilitleyen programlarda açık tutmayın.
4. Kurulum hatası ısrar ederse makineyi yeniden başlatın ve ilk iş olarak kurulumu çalıştırın.
5. Aktif geliştirme yaptığınız kod ağacını WSL içinde /mnt/c altında değil, WSL'in kendi dosya sisteminde tutun.

FAQ

Claude'u yönetici olarak çalıştırmak bu hatayı çözer mi?

Çözmez. Paylaşım ihlali bir yetki sorunu değil. Dosyayı açan süreç, başkasının yazmasına izin vermediğini bildirmiştir ve bu karar yönetici hakkıyla aşılmaz. Yönetici olarak çalıştırmak yalnızca izin hatalarında, örneğin korumalı bir klasöre yazma denemesinde işe yarar. Bu hatada yapılacak şey dosyayı tutan süreci kapatmak, kapanmıyorsa makineyi yeniden başlatmaktır.

Dosyayı hangi programın tuttuğunu nasıl bulurum?

Başlat menüsüne resmon yazıp Kaynak İzleyicisi'ni açın, CPU sekmesine geçin ve tanıtıcı arama alanına dosya adını yazın. Liste, dosyayı açık tutan süreçlerin adını ve PID değerini verir. Görev Yöneticisi bu bilgiyi vermez, yalnızca çalışan süreçleri gösterir. Linux tarafında aynı sorunun yanıtı lsof <dosya> ya da fuser -v <dosya> komutudur.

Excel dosyasını kapattım, hata neden sürüyor?

İki yaygın sebep var. Birincisi, Excel süreci hâlâ çalışıyor olabilir. Belge kapanır ama bazı eklentiler programı ayakta bırakır, Görev Yöneticisi'nde kontrol edin. İkincisi, klasörde ~$ ile başlayan gizli kilit dosyası kalmış olabilir. Program düzgün kapanmadığında bu dosya geride kalır. Komut isteminde dir /a "~$*" ile görebilirsiniz ve artık kalan böyle bir dosyayı silmek güvenlidir. Bir eşitleme istemcisi yükleme yapıyorsa da dosya kısa süre kilitli kalır, eşitlemeyi duraklatıp deneyin.

Aynı hatayı Linux'ta da görebilir miyim?

Bu biçimiyle göremezsiniz, çünkü Linux kilitleri tavsiye niteliğindedir ve yalnızca iki taraf da kilidi sorarsa etkilidir. Okunmakta olan bir dosyayı silmek veya üstüne yazmak Linux'ta hata vermez. Karşılaşacağınız şey farklıdır: dosya izniyle ilgili Permission denied, ya da bir uygulamanın kendi kilit dosyasının tuttuğu "zaten çalışıyor" mesajı. WSL bir istisnadır. /mnt/c altındaki dosyalar Windows kurallarıyla yönetilir, bu yüzden Excel'de açık bir dosyaya WSL içinden yazmak da başarısız olur.