JavaScript kullanarak 200GB iCloud alanımı temizleme çalışmam

 (andykong.org)
4 puan yazan GN⁺ 2024-01-06 | 1 yorum | WhatsApp'ta paylaş
  • iCloud depolama alanı 200GB sınırına yaklaşmış ve yalnızca fotoğraflar yaklaşık 127GB yer kaplamaya başlayınca, 1TB yükseltmesi yerine büyük videoları bizzat bulup silmeye yönelik dolaylı bir yöntem denendi
  • Apple Photos ve iCloud web arayüzünde dosya boyutuna göre sıralama yoktu; ayrıca ayrı uygulamalar da iCloud’a offload edilmiş fotoğrafları 0B gibi gösterdiğinden temizlik ölçütü olarak kullanmak zordu
  • iCloud Photos web’deki video oynatma süresi rozeti video-text-badge HTML öğesi olduğundan, JavaScript ile uzun videolar bulunup kırmızı çerçeveyle işaretlendi
  • 30 saniyeyi aşan videolar indirilip silindikten sonra, indirilen dosyalar yaklaşık 7GB olsa da iCloud depolama alanında yaklaşık 55GB azalma gibi beklenmedik bir fark ortaya çıktı
  • Yeni 4K videolarda dosya boyutu ile iCloud’da görülen değişim neredeyse birebir uyuşurken, eski videolar iCloud’da gerçek dosyadan daha büyük görünüyordu; bu da eski büyük videoların temizlemede öncelik olabileceğini gösteriyor

iCloud web’de uzun videoları ayıklamak

  • Apple’ın depolama uyarısından sonra, 200GB’tan 1TB’a çıkmanın maliyeti 3 katından fazla arttığı için alternatif aranmaya başlandı
  • Depolama alanının büyük kısmını fotoğraflar oluşturuyordu ve yaklaşık 127GB yer kaplıyorlardı, ancak Apple Photos ve iCloud tarayıcısında fotoğrafları dosya boyutuna göre sıralama özelliği yoktu
  • Yinelenen fotoğrafları ya da video dosya boyutlarını gösteren uygulamalar da iCloud’a offload edilmiş fotoğrafları 0B gibi gösterdiğinden gerçek temizlikte pek yardımcı olmadı
  • iCloud web sitesinde Photos -> Media Types -> Videos bölümüne gidildikten sonra, ekranda mümkün olduğunca çok videonun aynı anda görünmesi için yakınlaştırma en aza indirildi
  • Her videonun oynatma süresi rozetinin bir HTML öğesi olduğu fark edilince, JavaScript ile arama ve filtreleme yapılabileceği düşünülerek uzun videoları vurgulayan kod yazıldı
    • Oynatma süresi rozetinin sınıfı video-text-badge
    • Sayfadaki rozetler bulunup oynatma süresine göre sıralanıyor ve belirli bir eşik değerini aşan öğeler vurgulanıyor
    • iCloud yalnızca ekranda yüklenen öğeleri getirdiği için, sonradan kaydırılarak görünen öğelerin de işlenmesi amacıyla kod zamanlayıcıyla tekrar tekrar çalıştırılıyor
  • Kullanım yöntemi, iCloud sayfasında JavaScript konsolunu açıp tam gist’i yapıştırmak
  • Sonuç olarak 20 saniyeden uzun videolar kırmızı kutularla işaretleniyor; böylece birçok büyük videoyu seçip indirip silmek kolaylaşıyor

Silme sonrası depolama değişimi ve iki deney

  • Betikle iCloud videoları arasındaki 30 saniyeden uzun tüm öğeler kaldırıldığında, indirilen videolar yaklaşık 7GB olsa da iCloud depolama kullanımı yaklaşık 55GB azaldı
    • İndirilen videoların tamamı diskte 8GB yer kapladı
    • iCloud kullanımı 199GB’den 143GB’ye düştü
  • İlk deneyde, hareketin fazla olduğu bir 4K video yüklenerek iCloud depolama tepkisi gözlemlendi
    • Yüklenen dosyanın boyutu 281MB idi
    • Yükleme sonrası iCloud kullanımı 145.33GB oldu
    • İndirip sildikten sonra dosya hâlâ 281MB idi
    • Silme sonrası iCloud kullanımı 145.6GB olarak göründü; yani gösterilen değer farkı yaklaşık 270MB düzeyindeydi
  • İkinci deneyde, iCloud’un büyük dosya olarak gösterdiği eski videolar arasından kısa bir video seçilip kontrol edildi
    • iCloud bu videoyu 128MB olarak gösteriyordu
    • İndirilen dosya 47MB idi
    • Silme öncesi iCloud kullanımı 145.29GB, silme sonrası ise 145.12GB idi; yani yaklaşık 170MB azaldı
  • Yaklaşık 7GB’lık dosya silinerek bunun 7 katından fazla depolama alanı boşaltıldı ve eski büyük videoların iCloud’da gerçek dosyadan daha fazla depolama alanı kaplıyor gibi göründüğü düşünüldü
  • Nedeni doğrulanamadı, ancak sonuçta 50GB’tan fazla iCloud depolama alanı açıldı ve aynı işlemi yeniden yapmaya yarayacak küçük bir JavaScript betiği kaldı

İlgili okumalar

1 yorum

 
GN⁺ 2024-01-06
Hacker News yorumları

  • Photos.app’te dosya boyutu gösterilmediği için, büyük dosyaları bulan bir Photos.app uzantısı ya da ayrı bir uygulama yapmayı düşünmüştüm.
    Ama API “dosya boyutu”nu açığa çıkarmıyor gibiydi; en azından basit bir yol bulamadım.
    “Fotoğraf” ya da “video”nun, alttaki “photo or video object”i gösteren bir görünüme daha yakın olduğunu düşünüyorum. Bir videoyu kırpsanız bile orijinal videonun tamamı kalıyor; kırpılmış daha küçük dosya boyutu ancak dışa aktardığınızda gerçekten oluşuyor gibi.
    Bu yüzden dosya boyutu farklı görünüyor olabilir. Ayrıca birinin dosya boyutunu sorgulayan bir AppleScript yazdığı söyleniyor: https://discussions.apple.com/docs/DOC-250000422

    • Doğru; Photos uygulaması değiştirilmemiş özgün dosyayı saklıyor, düzenleme/kırpma bilgilerini ise ayrı tutuyor. İstediğiniz zaman özgüne dönebildiğiniz ve yeniden düzenleyebildiğiniz için, aynı görüntünün düzenleme öncesi/sonrası birden fazla kopyasını saklıyor olabilirsiniz.
      “Dosya boyutu”nu hangi API’de aradığınızı merak ettim.
      PhotoKit API ile Photos.app’ten boyut verisini alabilmiştim: https://alexwlchan.net/2023/finding-big-photos/
      Yalnızca yaklaşık 26 bin öğe bulunan kendi arşivimde test ettim ama en büyük öğeleri bulmak için kullanışlı bir ölçüttü. Ancak 1 GB’lık bir videoyu dışa aktarınca iCloud kullanımının 1 GB azalıp azalmadığını doğrulamadım.
    • Buna ek olarak, henüz ayrıntılı bakmadım ama RAW+JPG fotoğrafları içe aktardığınızda “özgün”ü ikisinden biri olarak ayarlayabiliyorsunuz. Menüyü kontrol etmezseniz hangisinin kullanıldığını bilmeden içe aktarıp düzenleyebilirsiniz.
      Bu yüzden arşivde tek bir küçük resim olarak görünen, yeni içe aktarılmış bir fotoğraf aslında 5 MB da olabilir, 50 MB da.
    • Kod yazmaya niyetliyseniz iç veritabanına bakıp bakmadığınızı merak ediyorum. En son baktığımda sadece sqlite’tı ve kabaca göz gezdirince bile bir ölçüde anlaşılabiliyordu.
    • Dosya boyutunun değişmesinin nedeni olarak en makul açıklama bu görünüyor. Ben de beklemediğim medya geri yüklemeleri görmüştüm. Bir videoyu kırptığımı ya da düzenlediğimi sanıyordum ama tam uzunluğu ve çözünürlüğüyle aynen duruyordu.
      iPhone depolama alanının bu kadar takıntılı biçimde yönetilse bile neden hep sınıra yakın olduğunu da açıklıyor.
    • https://github.com/RhetTbull/osxphotos ile mümkün:
      osxphotos query --min-size 100MB --add-to-album "Big Files"
      100 MB’tan büyük tüm fotoğraf ve videoları bulup “Big files” albümüne ekler.
      Ayrıntılar için osxphotos query --helpe bakabilir, belgeleri tarayıcıda açmak için osxphotos docs komutunu kullanabilirsiniz. Bu arada aracı ben yaptım.

  • Bir hata olabilir ama bazı durumlarda iCloud’un aynı dosyanın birden fazla sürümünü gizlice saklıyor olma ihtimali de var. Apple başka medya dosyalarında da benzer şeyler yapıyor.
    Son örnek ilginç:
    “iCloud videonun 128 MB olduğunu söylüyor, ama indirince gerçek video 48 MB çıktı; silince de boş alan yaklaşık 170 MB arttı.”
    Bu, iCloud’un yalnızca örnek dosya boyutunu yanlış göstermediğini düşündürüyor. 128 MB’lık bir dosyayı silince iCloud alanında da yaklaşık 128 MB boşalması gerekirken, gerçekte gösterilen 128 MB ile indirilen sürümün 48 MB’ının toplamı olan 176 MB’a yakın bir alan boşalmış. iCloud boş alanı 10 MB’lık birimlere yuvarlayarak gösteriyorsa bu oldukça tutarlı görünüyor.

    • Diferansiyel yedekleme ya da bir tür sürüm yönetimi en bariz nedenlerden biri gibi görünüyordu. Dosyayı korumak için tam kopya saklamak da mümkün. Sorun, tüm bunların tamamen opak olması.
      Sonuçta depolama alanınız giderek daha fazla bir hizmete bağlanıyor; toplam depolama miktarı üzerinden düzenli ödeme yapıyorsunuz ama bu alanı nasıl optimize edeceğinize dair neredeyse hiç bilgi yok. Sabit maliyet aralığında kalmak ya da depolama/maliyet oranını düşürmek isteyen tüketici açısından bakınca, sanki eli kolu bağlı şekilde daha fazla para ödemeye devam etmek zorunda kalıyorsunuz.
      Teknoloji sektörünün modern iş stratejisi, karmaşıklığın arkasına saklanmak. Maliyetler anlaşılması çok zor olacak kadar karmaşık, iç bilgileri rakiplere fazla açığa çıkarır vb. deniyor. Ama şirketin maliyetinin üzerinde çalışıp çalışmadığını kontrol ederken bu metrikleri bir şekilde çıkarıyorlar. Tüketici anlamaya çalışınca birden her şey aşırı karmaşık oluyor.
      Sorun şu ki teknoloji çoğu zaman gerçekten de aşırı karmaşık ölçeklere büyüyor ve yöneticiler de bunu bildiği için bu oldukça geçerli bir mazerete dönüşüyor. Uygun şekilde, yatırımı tam da o noktaya yoğunlaştırıp üzerine marj koyuyorlar.
    • iPhone’da fotoğraf ve video düzenlemeleri yalnızca meta veri; özgün dosya korunuyor. Az önce bir video kaydedip yarıya kırptım, sonra iCloud’dan dosyayı indirerek test ettim.
      Kırpılmış dosya, iCloud’un gösterdiği boyuttan küçüktü; ancak değiştirilmemiş özgünü indirmeyi seçince boyut iCloud’un gösterdiği boyutla eşleşti.
    • Kafa karışıklığının temelinde, Photos arşivindeki fotoğraf ve videoların yalnızca depolama alanına kopyalanmış dosyalar olmaması da var. Photos; düzenlemeler, render edilmiş sürümler, küçük resimler ve uygulama özellikleri için gereken çeşitli veriler için meta veri de saklıyor.
      Dolayısıyla bir fotoğrafı iCloud’a eşitlediğinizde yalnızca tek tek dosyalar eşitlenmiyor; Photos uygulamasının yönettiği “Photos Library” kapsayıcısı eşitleniyor.
      Finder ya da Files uygulamasında tek tek dosyaları doğrudan eklerseniz, iCloud ile yerel dosya sistemindeki boyutlar tam olarak eşleşir.
    • Muhtemelen gerçekten böyle durumlar olabilir, ama bu yine de onları aklamaz.
      Bir sabit disk ya da USB bellek aldığınızda belirli bir GB’ı istediğiniz gibi kullanabilirsiniz. 1 GB’lık dosya koyarsanız boş alan 1 GB azalır. Dosya sistemine bağlı olarak birkaç KB meta veri kaybedebilirsiniz ama dosya sistemi seçimi kullanıcıya aittir; depolama aygıtı bunu dayatmaz.
      NAND denetleyicisi blok eşleme tablosunu saklamak için fazla ayrılmış alandan birkaç MB kullanmış ya da kolaylık için veriyi kopyalı saklamış olsa bile kullanıcıdan o fazla ayrılmış alanın ücreti alınmaz.
      Burada ise HTTP üzerinden erişilen bir depolama aygıtı satılıyor; 1 GB’lık dosya yazınca kendi kolaylıkları için kopyalama/dönüştürme vb. yapıyorlar ve kullanıcının istemediği o kopyaların depolama maliyetini de kullanıcıya yansıtıyorlar. Bu yeni ve beklenmedik bir şey.

  • Bu fikri/çözümü bir TamperMonkey/Greasemonkey betiğine dönüştürdüm
    Ölçütlere uymayan tüm öğeleri “gizleme” özelliğini de ekledim
    https://github.com/seffignoz/icloudcleanup

  • Kendi sunucumda barındırma yapmamın nedenlerinden biri de bu. Bulut sağlayıcılarının netliğine ve şeffaflığına güvenmiyorum. Kendi barındırdığım çözüm çok daha az kararlı, daha az güvenli ve daha düşük performanslı olsa bile muhtemelen değiştirmem
    Kişisel olarak immich kullanıyorum. iOS/Android uygulamaları, sunucu bileşeni ve senkronizasyon/yedekleme seçenekleri olan epey olgun bir çözüm
    https://immich.app/

    • Apple, kota yönetimi arayüzünün ne kadar harika bir satış fırsatı olduğunu hâlâ fark etmemiş gibi. Daha fazla depolama alanı satmak için bundan iyi konum yok
      Google bunu yapıyor. https://one.google.com/storage ve https://photos.google.com/quotamanagement sayfalarına bakarsanız, silinecek öğeleri bulmayı kolaylaştıran ve sonunda silmekten yorulup daha fazla depolama alanı satın almanızı sağlamaya yönelik bir yapı görürsünüz
    • İlginç görünüyor ama üstteki uyarıya bakınca daha kararlı hâle gelene kadar beklemek gerekecek gibi

  • Bildiğim kadarıyla iCloud tam kaliteli orijinalleri saklıyor, telefona ise daha düşük kaliteli optimize edilmiş sürümleri indiriyor
    iPhone ayarlarında Apple ID > iCloud > Photos bölümüne giderseniz varsayılan olarak açık olan “Optimise iPhone Storage” seçeneği var
    Bu seçeneğin açıklamasında, telefonun alanı azaldığında tam çözünürlüklü fotoğraf ve videoların otomatik olarak daha küçük cihaz sürümleriyle değiştirildiği, tam çözünürlüklü sürümlerin ise her zaman iCloud’dan indirilebileceği yazıyor
    Bu oldukça makul görünüyor

    • Yine de indirme işlemi orijinal dosyayı döndürmeli; bu yüzden depolama alanı boyutu farkını açıklamak için kullanılamaz
    • Yazarın yeni bir dosya yükleyip sonra indirdiğinde dosya boyutu farkının büyük olmamasını açıklamıyor. Dosya boyutu farkı yalnızca eski video dosyalarında ortaya çıkıyor gibi
    • Bunun konuyla ilgisi yok
      Bu, Settings > Manage storage altında görülebilen telefon depolama alanıyla ilgili; bulut depolama alanıyla ilgisi yok

  • İlginç bir yazı. Ben de benzer bir sorun yüzünden iCloud planımı yükseltmek zorunda kaldım; bu yüzden Apple açısından bunu düzeltmek çok yüksek öncelikli olmayabilir
    RAW+JPEG çekim yaptığınızda Apple Photos iki görüntüyü bir araya getiriyor. Fotoğraf meraklıları için çok da nadir bir yöntem değil; kütüphanede yinelenmişe benzeyen fotoğraflar birikmeden RAW ile JPEG arasında kolayca geçiş yapabilmek açısından kullanışlı
    Ancak bu birleştirme yöntemi ve yazıda açıklanan dosya sistemi tasarımı nedeniyle, ikisini kolayca ayırıp yalnızca RAW’ları silmek mümkün görünmüyor. Yıllar geçtikten sonra artık asla dokunmayacağım devasa RAW dosyaları duruyor; çok daha küçük JPEG’leri ise tutmak istediğim için silemiyorum
    En kolayı orijinalleri dışa aktarıp kütüphaneden silmek, ardından yalnızca JPEG’leri yeniden içe aktarmak gibi görünüyor; ama bunu yapınca kütüphanede yıllar içinde biriken meta verileri kaybetmiş oluyorsunuz
    Bu yüzden planı yükseltmekten başka çare kalmıyor

    • Aptalca bir soru olabilir ama meta verileri dışa aktarıp yeniden içe aktarmak mümkün değil mi? EXIF verisi dışında başka meta veri mi var, yoksa Apple bunların tamamını dışa aktarmıyor mu, merak ediyorum
      Yüz tanıma gibi ek özelliklerden söz ediyorsanız, JPEG’i yeniden içe aktardıktan sonra uygulama bunları yeniden işlemez mi?
    • Açık kaynak araç osxphotos(https://github.com/RhetTbull/osxphotos) yardımcı olabilir. Üçüncü taraf exiftool yardımcı aracıyla meta verileri koruyarak JPEG görüntülerini dışa aktarabiliyor:
      osxphotos export /path/to/export --has-raw --skip-raw --exiftool
      RAW çifti olan tüm görüntüleri dışa aktarır ama RAW bileşenini atlar; exiftool(https://exiftool.org/) kullanarak anahtar kelimeler gibi meta verileri dışa aktarılan JPEG dosyalarına yazar. Daha sonra bunları Photos’a sürükleyerek ya da osxphotos import /path/to/export/* çalıştırarak yeniden içe aktarabilirsiniz
      export ve import komutlarında dışa aktarma dizinini vb. denetlemek için başka birçok seçenek de var. osxphotos help export kullanabilir ya da belgeleri tarayıcıda açmak için osxphotos docs çalıştırabilirsiniz. Not: osxphotos’un yazarı benim
    • Şu anda aynı durumda değilim ama fotoğraf delisi olduğum için sonunda benim de başıma geleceğini düşünüp araştırdım
      File/Export Unmodified Originals çalıştırılınca RAW+HEIC ve meta verileri içeren ayrı bir sidecar dosyası dışa aktarılıyor gibi. Sonra RAW dosyasını ayrı bir yere kaldırıp HEIC dosyasını içe aktarırsanız sidecar meta veri dosyasının da otomatik olarak içe aktarıldığı söyleniyor
      Ancak düzenlemeleri kaybediyorsunuz. Yine de bir şekilde “copy edits” mümkün gibi görünüyor. Teknik biri bunu AppleScript ile otomatikleştirebilir gibi
      Ama gereksiz yere zahmetli ve Photos.app içinde yerleşik bir özellik olarak bulunmalı. Daha yüksek iCloud planına yönlendirmeye yardımcı olduğu için önceliğinin düşük olduğu açık görünüyor
    • Ben de şu anda aynı durumdayım ve bu zahmetli işe henüz başlayamadım. Kesinlikle bir çözüm arıyorum

  • Şaşırtıcı şekilde, tatilden önce Apple’dan benzer bir depolama alanı bildirimi aldım ve tüm fotoğraf/videolarımı iCloud’a koymak yerine kendi medya sunucuma indirmeye karar verdim.
    iCloud’dan arşiv indirmek için kolay ve sezgisel bir yol yok. Birden fazla makine ve cihaz kullanarak yavaş yavaş ilerliyorum.
    Apple’daki son değişikliklerle ilgili sorun, görünürde pek bir neden yokken fiyatları artırmaları. Fotoğraf ve video çekmeye devam edeceğiz; en yeni teknolojiler ve özellikler yüzünden dosya boyutları da kaçınılmaz olarak büyümeye devam edecek.

    • Verileri almanın kolay bir yolu var. Sadece biraz gizlenmiş durumda.
      Google Takeout’a benzer şekilde çalışıyor. Mac, iPhone, iPad veya PC’den appleid.apple.com’daki Apple ID hesap sayfasına giriş yapıp “Data & Privacy” bölümüne gidin ve “Manage Your Data and Privacy”yi seçin.
      Sonraki sayfada “Get a copy of your data” bölümüne gidip “Get started”ı seçmeniz yeterli.
    • Hayat değiştirecek araç:
      https://github.com/icloud-photos-downloader/icloud_photos_downloader
    • Ben iPhone fotoğraflarını NAS’a kopyalamak için PhotoSync(https://www.photosync-app.com/home) kullanıyorum. Harika bir program.
      Gerekirse iCloud’dan fotoğraf da indirebiliyor ve format dönüştürebiliyor. Birkaç günde bir yeni fotoğrafları NAS’a gönderip yerel bir kopyayı her zaman tutuyorum; bu kopyalar da her gece Backblaze B2’ye yedekleniyor.
      Format dönüştürme sayesinde fotoğrafları HEIC+JPG çifti olarak tutabiliyorum; böylece hem orijinale hem de daha kolay kullanılabilir bir sürüme sahip oluyorum.
      Asıl istediğim, iCloud Drive için de aynı işi yapan bir araç. Oraya çeşitli şeyler koyuyorum ama makul biçimde yedeklemenin bir yolu olmaması beni endişelendiriyor. Apple’ın önerdiği yöntem(https://support.apple.com/en-us/HT204055) epey yetersiz.
    • MacOS’unuz varsa Photos uygulaması nasıl? Ben iCloud Photo Library’nin yerel bir kopyasını tutuyor ve MacOS Photos uygulamasıyla senkronize ediyorum.

  • En nefret ettiğim şey, 200GB’tan 2TB’a sıçrayan tuhaf tarife kademesi. Birçok aile için tam uygun olacak 500GB veya 1TB gibi artışlarla ödeme yapmanın yolu yok.
    Depolamanın emtia hâline geldiği bir çağda, kullanılan GB başına ücretlendirme olmalı.

    • Ücretsiz kademeyi ancak böyle sübvanse edebilirler.
    • Gerekirse 200GB’ın üstüne istediğiniz kadar 50GB’lık birim eklenebilmeli.

  • Benim iCloud depolama alanımı en çok yiyen şey, fotoğrafların “live” video sürümü. Çok kısa bir hareket parçası içeren fotoğraflar, dosya boyutu olarak daha büyük.
    Şimdiye kadar bulduğum çözüm, dosyaları yerel olarak indirmek, iCloud’dan silmek, ardından yerel videoları silip yalnızca kalan durağan görüntüleri yüklemek.
    Uzun sürüyor ve hantal; ayrıca süreçte bir şeyleri silmekten veya önemli bir şeyi kaybetmekten endişe ediyorum.
    Gerçekten saklamak istediğim az sayıdaki “live” görüntüyü belirleyip bırakmaya yetecek ölçüde düzenleme kontrolü sunarken bu süreci otomatikleştiren bir araç olup olmadığını merak ediyorum.

  • Doğru mu okudum?
    Bu yaygın bir durumsa, Apple’ın yükseltmeye zorlamak için rakamları şişirdiği düşünülebilir ve bu dava konusu bile olabilir, değil mi?
    Hukuk uzmanı değilim.

    • Orijinal yazı, Photos’a medya eklemenin basitçe “dosyayı kopyala ve kaydet” olmadığını hesaba katmıyor. Photos uygulamasının da diğer uygulamalar gibi kendi Photos Library dosya biçimi var.
      Bir fotoğraf veya video eklediğinizde Photos uygulaması bunu analiz eder ve düzenleme geçmişi dâhil uygulamanın çalışması için gereken çeşitli metaverileri saklar. Sonunda bunlar iCloud’a senkronize edilir.
    • Fotoğraf/videoları yeni bir dosya olarak kaydetmeden yerinde düzenlerseniz iOS, geri alma veya eski hâline döndürme için orijinal dosyayı tutar. Photos’ta ya da iCloud galerisinde hiçbir yerde orijinali göstermez. Nedeni bu olabilir.
    • Ben de yazıyı böyle okudum. Bir bulut depolamadan belirli miktarda dosya indirip başka bir buluta yükleyerek belirgin bir fark olup olmadığı kontrol edilebilir gibi.
      Apple’ın iCloud’da hâlâ eski bir dosya sistemi biçimi kullanıyor olması da mümkün. Epey zaman oldu ve depolama biçimini değiştirmeye uğraşmamış olabilirler. Eski hesaplardaki görüntü/videoların “eski” sürücülerde bulunma ihtimali de var.