Windows'ta güncelleme başarısız
Bu sayfa, çoğunlukla Windows’ta ocx update veya pano güncellemesinin
#5624 örneğindeki gibi yarıda
kalması içindir:
update command failed (1)exit 1 · code: ENOTDIR · syscall: mkdirArdından paketin yanında, bunx.exe kullanımda olduğu için silinemeyen (EPERM)
bir klasör kalabilir.
Kurulumun durumu
Bölüm başlığı “Kurulumun durumu”Güncelleyici proxy’yi durdurur, yeni sürümü ayrı bir hazırlık klasörüne kurar, kontrol eder ve ancak sonra eski sürümün yerine geçirir. Kurulum adımı başarısızsa değiştirme yapılmaz: önceki sürüm kurulu ve çalıştırılabilir kalır. Güncelleyici çıkmadan önce eski arka plan servisini veya proxy’yi yeniden başlatır. Çalışan proxy’ye dönmek için yeniden kurmanız gerekmez.
Kontrol edin:
ocx --versionocx statusKurulum çıktısı yerel yollar içerebildiği için pano işi yalnızca çıkış durumunu
kaydeder. Terminalde ocx update çalıştırmak başarısız adımı ve sonraki işlemi gösterir.
Güncellemeyi tamamlama
Bölüm başlığı “Güncellemeyi tamamlama”-
OpenCodex dosyalarını çalıştırabilecek uygulamaları kapatın: Codex uygulaması,
ocxveyabunxbaşlatan terminaller ve OpenCodex sistem tepsisi uygulaması. Çalışanbun.exeveyabunx.exe, Windows’ta dosyalarını kilitli tutar. -
Terminalden yeniden
ocx updateçalıştırın. -
Aynı hata sürerse
ocx statusçalıştırıp devam eden kurtarmanın bitmesini bekleyin. Güncelleyici proxy’yi yeniden başlattıysa onu yöneten uygulama veya servis üzerinden (ocx stop, servisi veya masaüstü uygulaması) durdurup durduğunu doğrulayın. Kurulumu yöneten aynı paket yöneticisiyle yeniden kurun. OpenCodex servisinin yönettiği npm kurulumu için:Terminal window ocx stopnpm install -g --allow-scripts=bun @bitkyc08/opencodex@latestocx service restartKurulumdan sonra yöneten servis veya masaüstü uygulamasıyla başlatın; bağımsız çalıştırıyorsanız
ocx startkullanın. Önizleme kanalındaysanızlatestyerinepreviewyazın.
Kalan klasörler
Bölüm başlığı “Kalan klasörler”Bunlar npm’in genel klasöründe paketin yanında bulunur; Windows’ta genellikle
%APPDATA%\npm\node_modules\@bitkyc08\ konumundadır.
| Klasör | Oluşturan | Yapılacak işlem |
|---|---|---|
.opencodex-<random> |
Doğrudan npm install -g sırasında paketi değiştiren npm |
İçinden OpenCodex işlemi çalışmadığında silin. |
.ocx-staging-<timestamp> |
OpenCodex güncelleyicisinin hazırlık kurulumu | İşaretli ve yarım saatten eski klasör bildirilir ama silinmez. İçinden OpenCodex işlemi çalışmadığında elle silin. .ocx-update-owner.json işareti yoksa kökeni doğrulanmamıştır: yarım kalan güncelleme de aynı öneki kullanan başka bir şey de oluşturmuş olabilir. Silmeden önce OpenCodex’e ait olduğunu doğrulayın. |
.ocx-backup-<timestamp> |
Güncelleyicinin önceki sürüm kopyası | Bırakın; yeni sürüm sağlıklı başlayınca otomatik silinir, başlamazsa geri yüklenir. |
Her deneme yeni klasör kullandığı için bu adlar sonraki güncellemeyi doğrudan
engellemez. Ancak artıklar disk tüketir ve birikirse sonraki hazırlık ENOSPC
ile başarısız olabilir. Güncelleyici sonraki güncellemelerde de bunları yerinde
bırakır; sahiplik işaretini kontrol edip yarım saatten eski işaretli klasörleri
bildirir. Yalnızca içinden OpenCodex işlemi çalışmadığını doğruladıktan sonra silin.
Bir klasör silinemiyorsa içinden çalışan işlem kalmış olabilir. Windows oturumunu kapatmak veya yeniden başlatmak kilidi serbest bırakır.
Güncelleme UNSUPERVISED proxy bildiriyorsa
Bölüm başlığı “Güncelleme UNSUPERVISED proxy bildiriyorsa”Güncellemeden sonra arka plan servisi yenilenemediğinde güncelleyici önce mevcut
servisi launchd (macOS) veya systemd kullanıcı yöneticisi (Linux) üzerinden yeniden
başlatmayı ister. Servisin yönettiği proxy dönmezse hizmet kesilmesin diye proxy’yi
doğrudan başlatır, UNSUPERVISED uyarısı verir ve sıfır dışında kodla çıkar.
Proxy çalışır; ancak çökerse yeniden başlatılmaz ve sonraki servis başlangıcıyla
aynı bağlantı noktası için yarışabilir. ocx service repair ile yönetimi servise
devredin, ardından ocx status kontrolü yapın.
Panodan başlayan güncelleme de aynı sırayı izler. Yalnızca doğrudan başlatma başarılıysa yeni sürüm yanıtlıyor olsa bile pano aynı uyarıyla başarısızlık gösterir. Aynı onarım komutu bunu giderir.
Elle kurulumdan sonra proxy 503 döndürüyorsa
Bölüm başlığı “Elle kurulumdan sonra proxy 503 döndürüyorsa”Çalışan proxy’nin üzerine kurulum yapmak, yeniden başlayana kadar
package_tree_changed koduyla 503 döndürmesine yol açar. 2.64.0 sonrasındaki
sürümler, paket ağacı ve Bun çalışma zamanı tamamlanınca birkaç saniye içinde
kendini yeniden başlatabilir. Eksik veya başarısız Bun postinstall adımı bu
kurtarmayı engeller. ocx restart veya ocx service restart bu durumdaki proxy’yi
bulabilir; yine de eksiksiz çalışma zamanı ve paket ağacı gerekir. 2.64.0 ve
öncesinde proxy bu durumda kalır; eski işlem bağlantı noktasını tutarken
ocx restart çalışan proxy yok diyebilir. ocx service restart kullanın veya
/healthz yanıtındaki pid işlemine son verip ocx start çalıştırın.
Yükleyici çıktıysa veya başarısız olduysa hatasını inceleyin ve ocx status
çalıştırın. Kurtarmanın bitmesini bekleyin; çalışan proxy’yi yöneticisi üzerinden
durdurun ve durduğunu doğrulayın. Aynı paket yöneticisiyle yeniden kurup Bun
postinstall adımının tamamlanmasını sağlayın. Sonra yöneten servis/uygulama
üzerinden; bağımsızsa ocx start ile başlatın.
Güncelleme npm önbellek kontrolünde duruyorsa
Bölüm başlığı “Güncelleme npm önbellek kontrolünde duruyorsa”mkdir işleminde ENOTDIR, npm’in bir bileşeni dosya olan veya hedefi kayıp bir
bağlantı olan yolda klasör oluşturmaya çalıştığını gösterir.
#6288 örneğinde,
%LOCALAPPDATA%\npm-cache başka sürücüye işaret eden bir junction idi; hedef
klasör silinmiş veya sürücü kaldırılmıştı.
Güncelleyici proxy’yi durdurmadan önce önbellek klasörünü kontrol eder. npm hazırlık
kurulumu da npm config get cache tarafından bildirilen aynı klasörü kullanır.
Klasör kullanılamıyorsa güncelleme cache_root_dangling_link veya
cache_root_not_directory ile durur ve proxy çalışmaya devam eder:
cache_root_dangling_link: Önbellek bağlantısının/junction’ının hedefi kayıp. Hedefi yeniden oluşturun veya npm normal klasör oluşturabilsin diye bağlantıyı kaldırın.cache_root_not_directory: Önbellek ya da üst klasörlerinden biri dosya veya kullanılamayan sürücüde. Dosyayı başka yere alın ya danpm config set cache <folder>ile başka önbellek seçin.
Sonra ocx update komutunu yeniden çalıştırın. Kontrol geçmesine rağmen ENOTDIR
sürerse tam ocx update terminal çıktısı, npm config get prefix ve
npm config get cache çıktılarıyla sorun kaydı açın.
Masaüstü güncellemesi “Installing update…” aşamasında takılıyorsa
Bölüm başlığı “Masaüstü güncellemesi “Installing update…” aşamasında takılıyorsa”OpenCodex masaüstü uygulamasında Install update, uygulamayı değiştirmeden ve yeniden başlatmadan önce yükleyiciyi GitHub Releases’ten indirir. Bilinen sürümde indirme/kurulum başarısızsa elle indirme ipucu ve o sürümün yayın bağlantısı gösterilir.
“Installing update…” takılır veya zaman aşımına uğrarsa ağınız GitHub yayın indirmelerini yavaşlatıyor veya engelliyor olabilir. Hatadaki bağlantıyı kullanın ya da yayınlar sayfasında aynı sürümü bulup işletim sisteminize ve mimarinize uygun yükleyiciyi indirin. Önizleme sürümlerinin ayrı sayfaları vardır; uygulamanın önerdiği sürümü seçin.
Yükleyiciyi çalıştırmadan önce proxy’yi onu yöneten uygulama veya servis üzerinden durdurun ve durduğunu doğrulayın:
-
Uygulamanın yönettiği proxy için OpenCodex masaüstü uygulamasından tepsi menüsüyle çıkın.
-
Servisin yönettiği proxy’yi servis denetimleriyle durdurun (OpenCodex servisi için
ocx stop). Bağımsız terminal proxy’sini o terminalden durdurun. -
Windows’ta kalan çalışma zamanlarını belirlemeye yardımcı olması için:
Terminal window Get-Process -Name ocx, opencodex-desktop, bun, bunx -ErrorAction SilentlyContinueBu liste işlemi hangi uygulamanın yönettiğini kanıtlamaz. OpenCodex çalışma zamanını belirleyip yöneten uygulama/servisle durdurun;
bunbaşka uygulamaya ait olabilir. Kurulumdan önce uygulamanın ve proxy’nin çıkmasını bekleyin.
İndirdiğiniz yükleyiciyi çalıştırın, ardından masaüstü uygulamasını açın veya yöneten servisi yeniden başlatın.

