कुछ JavaScript के साथ अपना 200GB iCloud साफ़ करना

मूल लेख ↗ Hacker News चर्चा ↗

Apple की iCloud Photo Library पर inflated storage usage रिपोर्ट करने का आरोप है, और कुछ उपयोगकर्ताओं को ऐसे वीडियो मिलते हैं जो iCloud में उनकी वास्तविक डाउनलोड होने वाली फ़ाइलों से कहीं बड़े गिने जाते हैं। टिप्पणीकार तकनीकी व्याख्याएँ देते हैं—जैसे hidden originals, edit histories, multiple encodings, और अपारदर्शी Photos library metadata—लेकिन तर्क देते हैं कि Apple के टूल्स यह देखना या साफ़ करना कठिन बनाते हैं कि वास्तव में जगह क्या ले रहा है, जिससे लोग ऊँचे कीमत वाले storage tiers की ओर धकेले जाते हैं। अन्य लोग वर्कअराउंड, third-party tools, और self-hosting विकल्प साझा करते हैं, जबकि lock-in, कमजोर data export, और subscription-driven product choices पर व्यापक चिंताओं की ओर इशारा करते हैं.

iCloud स्टोरेज में विसंगतियाँ

  • कई टिप्पणीकार रिपोर्ट किए गए और वास्तविक फ़ाइल आकारों के बीच के मेल न खाने को संभावित रूप से गंभीर, और अगर यह व्यापक हो तो मुकदमे योग्य तक मानते हैं।
  • अन्य लोग तर्क देते हैं कि यह ज़्यादातर Photos और iCloud के काम करने के तरीके के कारण है: मूल फ़ाइलें हमेशा सुरक्षित रहती हैं, संपादन मेटाडेटा होते हैं, और अतिरिक्त ऐप-विशिष्ट डेटा (थंबनेल, फेस डेटा, वर्ज़न) संग्रहीत और सिंक किया जाता है।
  • कुछ तकनीकी अटकलें: हर वीडियो के लिए कई एन्कोडिंग या रेज़ोल्यूशन, HEIC मल्टी-फ़्रेम कंटेनर, बैकअप/वर्ज़निंग, और आंतरिक ऑब्जेक्ट स्टोरेज ओवरहेड।
  • लेख से एक उदाहरण (128 MB रिपोर्टेड बनाम 48 MB फ़ाइल, हटाने पर लगभग 170 MB मुक्त) लोगों को छिपी हुई अतिरिक्त प्रतियों या फ़ॉर्मैट्स का संदेह करने पर मजबूर करता है।
  • सहमति: व्यवहार तकनीकी रूप से समझाया जा सकता है, लेकिन यह अपारदर्शी है और जब यह भुगतान की गई कोटा के खिलाफ गिना जाता है, तो उपयोगकर्ता-विरोधी लगता है।

अपारदर्शिता और खराब टूलिंग

  • कई लोग शिकायत करते हैं कि Apple के UI वास्तविक प्रति-आइटम आकार नहीं दिखाते या सफ़ाई को आसान नहीं बनाते, खासकर Photos, iMessage, और iCloud backups के लिए।
  • iCloud में iMessage को खास तौर पर निशाना बनाया गया है: कोई web view नहीं, broken search, गलत size reporting, धीमी/buggy deletion, और संभावित DB corruption।
  • कुछ लोग इसे dark-pattern डिज़ाइन मानते हैं, ताकि उपयोगकर्ताओं को ऊँचे, आवर्ती storage tiers में धकेला जा सके।

मूल्य निर्धारण और tiers

  • बार-बार निराशा इन बातों को लेकर है:
    • 5 GB free आधुनिक devices के लिए व्यावहारिक रूप से बेकार है।
    • 50/200 GB और 2 TB के बीच बड़े jumps हैं, लेकिन 400–500 GB का कोई “मध्य” tier नहीं है।
  • दूसरे लोग जवाब देते हैं कि cloud storage सस्ता है और multi-device backups को खुद संभालने की तुलना में इसके लिए भुगतान करना उचित है।

वर्कअराउंड और टूल्स

  • उपयोगकर्ता इनका उल्लेख करते हैं:
    • Windows iCloud app, “optimize” off के साथ Mac Photos, या Apple के data export portal के जरिए सभी media डाउनलोड करना।
    • third-party tools: iCloud photo downloaders, osxphotos (metadata सुरक्षित रखते हुए RAW+JPEG cleanup सहित), PhotoSync, dedupe apps, और PhotoKit या AppleScript का उपयोग करने वाले scripts।
    • article के JS snippet से निकला एक Tampermonkey/Greasemonkey script, जो iCloud Photos web UI में बड़ी फ़ाइलों को highlight करता है।

Self-hosting और विकल्प

  • कुछ लोग transparency और control के लिए self-hosted photo solutions (जैसे NAS + Immich जैसे apps) पसंद करते हैं, हालांकि वे complexity और अलग backups की ज़रूरत को स्वीकार करते हैं।
  • अन्य लोग स्पष्ट रूप से सुविधा के लिए बड़े cloud providers (Apple, Google, Microsoft) चुनते हैं, इन समस्याओं के बावजूद।

खुले प्रश्न

  • यह स्पष्ट नहीं है कि discrepancy का कितना हिस्सा bugs के कारण है बनाम intentional design के कारण।
  • यह भी स्पष्ट नहीं है कि साझा albums, live photos, और internal derivatives के मामले में सभी स्थितियों में iCloud quotas में ठीक-ठीक क्या गिना जाता है।