Hyperspace: फ़ाइलें हटाए बिना डिस्क स्पेस बचाने वाला Mac ऐप

 (hypercritical.co)
1 पॉइंट द्वारा GN⁺ 2025-02-26 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Mac पर duplicate files की सफाई आमतौर पर हटाने पर आधारित होती है, लेकिन Hyperspace APFS clones के ज़रिए समान content वाली files को share करवाता है और files को बनाए रखते हुए space वापस हासिल करता है
  • APFS के copy-on-write clones Finder के “Duplicate” की तरह वास्तविक data को दोबारा लिखे बिना original के साथ share करते हैं, जिससे बड़े आकार की copy भी लगभग तुरंत पूरी हो जाती है
  • डेवलपर की disk भरने लगी तो उन्होंने समान content वाली लेकिन clone न बनी files खोजने के लिए Perl script बनाई, और बचाया जा सकने वाला space दर्जनों GB निकला, जिसके बाद यह ऐप में विकसित हुआ
  • ऐप मुफ्त में download करके scan किया जा सकता है और बचाया जा सकने वाला space देखा जा सकता है, लेकिन वास्तविक space recovery के लिए paid purchase जरूरी है
  • यह उन files को modify करता है जिन्हें ऐप ने बनाया या own नहीं किया है, इसलिए जोखिम बड़ा है, लेकिन इसी वजह से यह कई Mac users के लिए वास्तविक मददगार हो सकता है

APFS clones से files को बनाए रखते हुए space recovery

  • जब समान content वाली files आपस में clone relationship में नहीं होतीं, तो Hyperspace उन्हें APFS clones में बदल देता है ताकि disk पर data की सिर्फ एक copy share हो
  • मौजूदा Mac duplicate-file apps आम तौर पर duplicate files खोजकर उन्हें delete करके space बचाते हैं, लेकिन Hyperspace files हटाए बिना space recover करता है
  • APFS की core features में point-in-time snapshots और copy-on-write clones शामिल हैं
    • snapshots का इस्तेमाल Time Machine backups को ज्यादा reliable और efficient बनाने में होता है
    • copy-on-write clones directory entries और file contents के बीच flexible structure पर आधारित होते हैं
  • Finder में “Duplicate” command से file copy करने पर वास्तविक file contents copy नहीं होते; original के साथ data share करने वाली clone file बनती है
    • इस structure की वजह से file size चाहे जो हो, Finder में duplication लगभग तुरंत पूरा हो जाता है

रिलीज़ का तरीका और development notes

  • 2024 के अंत में अपने Mac की disk भरने पर डेवलपर ने समान content वाली non-clone files खोजकर उन्हें clones में बदलने वाली Perl script लिखी
    • यह script C में लिखे command-line tool और Swift में लिखे command-line tool को call करती है
    • run करने पर बचाया जा सकने वाला space दर्जनों GB दिखा, और बाद में यह Mac app के रूप में विकसित हुआ
  • Hyperspace Mac App Store पर उपलब्ध है
    • download और scan मुफ्त हैं
    • वास्तविक space recovery के लिए in-app purchase जरूरी है
    • विस्तृत जानकारी Hyperspace documentation में देखी जा सकती है
  • development के लिहाज से Hyperspace डेवलपर का दूसरा SwiftUI Mac app है, और SwiftUI life cycle इस्तेमाल करने वाला पहला app है
    • यह Swift 6 इस्तेमाल करने वाला उनका दूसरा app भी है
    • development की शुरुआत से Swift 6 इस्तेमाल करना, पहले से रिलीज़ app को Swift 6 में migrate करने की तुलना में काफी आसान था
    • Swift 6 में अभी भी कई rough edges हैं, इसलिए आगे सुधार की उम्मीद है
  • Hyperspace HFS+ से APFS में conversion की प्रक्रिया की तरह उन files को modify करता है जिन्हें ऐप ने न बनाया है और न own किया है
    • डेवलपर इसे अपने बनाए apps में सबसे जोखिम भरा app कहते हैं
    • साथ ही वे मानते हैं कि यह सबसे ज्यादा लोगों के लिए उपयोगी app भी हो सकता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-02-26
Hacker News की राय

  • मैंने पहले यही काम करने वाली command-line utility dedup बनाई थी
    इसमें dry-run mode है, यह “समझदारी से” सबसे अच्छा clone source चुनता है, hard links और दूसरे clones को समझता है, metadata को preserve करता है, और HFS compressed files को भी ठीक से handle करता है
    मेरे data को इसने अभी तक कभी खराब नहीं किया, लेकिन file system tools के साथ हमेशा की तरह, इस्तेमाल अपने जोखिम पर करें
    0 - https://github.com/ttkb-oss/dedup

    • सिर्फ scan करके, अभी deduplication न करने की स्थिति में लिखूं तो, disk images, program binaries और intermediate representations से जुड़े 7.6GB workspace के आधार पर फर्क काफी दिखता है
      Hyperspace default रूप से सभी files को scan नहीं करता, सिर्फ allowlist में मौजूद files को देखता है, और इसकी संरचना ऐसी लगती है जैसे इसे file contents को समझना पड़ता हो। end user के नजरिए से मुझे नहीं पता कि यह Text files और Source Code files में फर्क कैसे करता है, और default scan ने केवल 360MB को deduplication target के रूप में पाया, लेकिन सभी files allow करने पर यह 842MB हो गया
      default रूप से यह 100KB से छोटी files भी scan नहीं करता, और size limit बंद करके सभी files allow करने पर यह 1.1GB तक बढ़ गया। सभी files और कोई size limit नहीं वाली condition में Hyperspace ने 68,874 में से 67,309 files scan कीं और dedup ने 67,426 files scan कीं
      Hyperspace ने कहा कि 29,522 files deduplicate की जा सकती हैं, और dedup ने 29,447 files पाईं। पहले से deduplicated files 76 थीं, इसलिए एक का फर्क आता है, लेकिन सही वजह नहीं पता
      scan time Hyperspace का करीब 50 seconds था, और dedup का 14 seconds। Hyperspace शायद file system scan करने के बाद duplicates की गणना करता है और फिर deduplication करता है, लेकिन समझ नहीं आता कि पहले दो steps साथ में क्यों नहीं करता। मैंने scan के दौरान file system metadata को queue में डालकर parallel में duplicate calculation शुरू कराई, और ज्यादातर मामलों में fts_read से directories traverse करते समय “मुफ्त में” मिलने वाली size information से ही mismatches filter किए जा सकते हैं
      Hyperspace ने कहा कि 1.1GB बचाया जा सकता है, और dedup ने 1.04GB के साथ पहले से बचाए गए 882MB पाए। मेरा Hyperspace खरीदने का इरादा नहीं है, इसलिए actual deduplication time, metadata preservation या अजीब files handling तक के बारे में नहीं जानता, लेकिन dedup में scan और deduplication मिलाकर 31 seconds लगे
      dedup से deduplicate करने के बाद भी Hyperscan ने माना कि अभी 2 files deduplicate की जा सकती हैं। Hyperspace भी multiple hard links वाली files, empty files, और dedup जिन कई exceptions को check करता है, उन्हें handle करता दिखता है। ACL या अन्य attributes preservation को payment के बिना test नहीं किया जा सकता, लेकिन strings देखने पर लगता है कि यह handle करता है, और HFS compression एक tricky edge case है, इसलिए Hyperspace scan इसे कैसे handle करता है यह अभी verify नहीं कर पाया
    • Postgres development directory जैसी जगह, जहां बहुत सारी लगभग समान files होती हैं, पर चलाकर देखा तो लगभग 1.7GB बचा
      project में license नहीं है, इसलिए अगर संभव हो तो अपनी पसंद का license जोड़ दें तो अच्छा होगा। installation steps को थोड़ा सुधारने के लिए मैंने pull request भी बनाया है: https://github.com/ttkb-oss/dedup/pull/6
    • अभी-अभी इस्तेमाल किया और यह अच्छी तरह काम करता है। असल में कुछ specific file types, खासकर node_modules के अंदर कितने duplicates हैं, यह देखने के बाद ही मुझे इस technique की potential समझ आई
      सिर्फ किसी specific subdirectory को देखने पर भी किसी JS file की 50 copies को एक में बदलना असामान्य नहीं था। हालांकि यह “pre-release” है और GitHub stars भी कम हैं, इसलिए ऐसे tools में bug हो तो काफी डर लगता है, इसलिए stability को लेकर जिज्ञासा है
    • documentation शानदार है, और make का लगभग तुरंत खत्म हो जाना भी impressive था
    • alternatives की list के लिए https://news.ycombinator.com/item?id=38113396 की comments देखें
      पहले https://github.com/sahib/rmlint इस्तेमाल किया था और कोई खास शिकायत नहीं थी

  • “Hyperspace के पास दूसरे सभी apps या खुद macOS के साथ मिलकर यह coordinate करने का कोई तरीका नहीं है कि फ़ाइल बदलना कब सुरक्षित है, और न ही उस फ़ाइल पर ज़बरदस्ती exclusive control लेने का कोई तरीका है” — यह हिस्सा देखकर सोचने लगा कि file system खुद background में ऐसा ही deduplication process क्यों नहीं चलाता
    उस स्तर की abstraction layer हो तो लगता है कि ऐसी safety समस्याओं को manage किया जा सकता है; सोचता हूँ कि APFS के अंदर यह अपने-आप हो तो क्या कमियां होंगी

    • ZFS में यह काफी RAM इस्तेमाल करता है. शायद इसलिए कि ZFS block level पर काम करता है, इसलिए नया block लिखे जाते समय comparison के लिए बहुत सारे blocks को track करना पड़ता है
      File level पर implement करने से resource usage घट सकता है, लेकिन implementation ज़्यादा सरल होगी या जटिल, यह नहीं पता. और अगर किसी बड़े file में सिर्फ 1 byte बदले, तब भी file system को उस file को फिर से duplicate करना पड़ेगा, जिससे बहुत disk activity हो सकती है—यह बात सहज रूप से स्पष्ट नहीं लग सकती
    • Block storage devices में compression के साथ ऐसा काम अक्सर किया जाता है. बेशक, अगर file system device को भेजे जाने वाले blocks को encrypt कर दे तो यह fail हो जाता है
      इस layer पर deduplication करने का फायदा है कि कई file systems के across deduplication हो सकता है. उदाहरण के लिए, अगर एक ही operating system files वाले एक हज़ार systems हों, तो storage बहुत बच सकती है, और फर्क अक्सर host key या hostname जैसी system-specific settings भर का होता है. एक single file system ऐसी समानता पहचान नहीं सकता
      हालांकि deduplication के कारण अगर बहुत ज़्यादा इस्तेमाल होने वाली file की copies की संख्या घट जाए, तो समस्या होती है. ऊपर वाले उदाहरण में अगर हज़ार machines एक साथ boot हों, तो kernel image पर भारी I/O load पड़ सकता है
    • Linux में यह btrfs और XFS में इस्तेमाल होने वाला standard deduplication API है
      आप specified ranges के set को operating system से विनम्रता से deduplicate करने का अनुरोध करते हैं; OS ranges को lock करता है और सचमुच identical होने की verification के बाद ही deduplication करता है. हर range में कितने bytes deduplicate हुए, यह भी field के रूप में वापस मिलता है, इसलिए user-space program के लिए file खराब करने का कोई तरीका नहीं रहता
    • ZFS सच में ऐसा करता है: https://www.truenas.com/docs/references/zfsdeduplication/
    • Windows Server भी NTFS और ReFS volumes पर यह feature देता है
      Hyper-V VM वाले ReFS पर मैंने इसे काफी इस्तेमाल किया था और असर शानदार था. उस समय ज्यादातर VMs Windows Server 2016/2019 के mix थे, और storage usage करीब 45% घट गया था

  • मुझे यह model पसंद है कि scan free में करके देख लो कि फायदा है या नहीं, और actual results के लिए ही pay करो
    मैं भी files जमा करके रखने वालों में हूँ, इसलिए चलाकर देखा तो 7GB reclaimable दिखा, लेकिन मेरे लिए उतना cost देने लायक नहीं था. फिर भी अच्छा है कि ऐसा tool मौजूद है

    • Podcast में इस model की explanation दी गई थी. बहुत से users इसे खरीदकर एक बार चलाएंगे, कुछ GB बचाएंगे और बस खत्म, इसलिए subscription का ज़्यादा मतलब नहीं बनता
      आखिर एक महीने में आप गलती से पूरी तरह same duplicate files कितनी बना लेंगे?
      जो लोग सच में इसे अक्सर इस्तेमाल करेंगे उनके लिए subscription या perpetual purchase options भी हैं, लेकिन बहुत से लोगों के लिए limited period में इस्तेमाल हो सकने वाला one-time in-app purchase काफी reasonable है. और आप कभी भी free में फिर से चला सकते हैं कि दोबारा pay करने लायक files जमा हुई हैं या नहीं
    • ऐसे deduplication app की value मेरे लिए space बचाने से ज्यादा duplicate files न बचने देना है
      मैं बहुत भारी मात्रा में नहीं बनाता, लेकिन कुछ या सभी को मिलाने पर बड़े duplicate files बन सकते हैं. आम तौर पर यह अजीब situations में होता है, जैसे hard drive recovery के results को किसी दूसरी जगह की files से match करना हो, या गंदे downloads folder को किसी organized target location से match करना हो
      उदाहरण के लिए, एक बार Time Machine backup ने एक file का पुराना version सामने ला दिया जिसके record होने का मुझे पता भी नहीं था और जिसे मैं बहुत पहले खो चुका समझता था, लेकिन उसने directory names खराब कर दिए थे और content को भी कुछ हद तक obfuscate कर दिया था. हज़ारों numeric-name directories थीं, जिनमें ऐसी files हो सकती थीं जिन्हें मैं रखना चाहता था, लेकिन वे मेरे पास पहले से हैं या कहां हैं, यह जानने के लिए कोई structure नहीं था. उल्टा, कई बार उनमें सिर्फ same build system text file होता था, जिसे जाहिर है छोड़ सकते थे
    • क्या मैं इतना बूढ़ा हो गया हूँ कि मुझे याद है 10 साल पहले ज्यादातर software ऐसे ही होते थे
      क्या लोग subscription traps के इतने आदी हो चुके हैं कि यह उन्हें नया model लगता है
    • यह pricing model मुझे सच में पसंद है
      काश दूसरे software में भी ऐसा करना आसान होता, लेकिन आम तौर पर value दिखने से पहले learning curve आड़े आ जाता है
    • cancel करना याद रखने वाली “free trial” से यह कहीं ज्यादा fresh है
      एक tip: ऐसे trials के लिए lock की जा सकने वाली virtual card इस्तेमाल करें, तो cancel भूल भी जाएं तो charge block हो जाता है. लेकिन सोच रहा हूँ कि क्या किसी ने website पर actual license price ढूंढी है

  • जानना चाहूँगा कि app दो files identical हैं या नहीं, यह पता करने के लिए कौन सा algorithm इस्तेमाल करता है
    Hash, bit-by-bit comparison जैसी कई interesting methods हैं, लेकिन हर एक की कमियां भी हैं. जब files बहुत ज्यादा हों तो सबसे अच्छा तरीका क्या होगा

    • Siracusa exactly क्या कर रहा है, यह नहीं पता, लेकिन अंदाज़ा लगाया जा सकता है
      हर candidate file के लिए दूसरे candidate files से समानता जांचने के लिए एक “key” चाहिए. Files लाखों में हो सकती हैं, इसलिए key छोटी और जल्दी generate होने वाली होनी चाहिए, लेकिन साथ ही false positives नहीं होने चाहिए
      आजकल obvious जवाब file contents का SHA256 hash है. यह बहुत fast है, size भी 32 bytes होकर बहुत बड़ा नहीं है, और false positives या collisions की संभावना इतनी कम है कि उससे सामना होने से पहले दुनिया खत्म हो जाए. SHA256 इस use case के लिए de facto standard है, इसलिए अगर कुछ और किया हो तो काफी हैरानी होगी
    • https://en.wikipedia.org/wiki/Venti_(software) याद आता है
      यह deduplication के लिए hash इस्तेमाल करने वाला content-addressable file system था, और hash write time पर calculate होता था, इसलिए performance cost distributed हो जाती थी
    • मैं सभी files के पहले 1024 bytes hash करता, और collision होने पर ही आगे बढ़ता
      इससे बड़े files को पूरा hash करने की जरूरत नहीं पड़ती, और सिर्फ same hash वाली files को आगे देखना पड़ता

  • Apple APFS की clone feature इस्तेमाल करने के लिए -c flag support करने वाला modified cp command साथ में देता है

    • अगर आपका cp इसे support नहीं करता, तो Python से भी call कर सकते हैं
      जैसे import Foundation; Foundation.NSFileManager.defaultManager().copyItemAtPath_toPath_error_(...)

  • अगर फ़ाइल A दो जगहों पर है और इसे चलाने के बाद A_0 को modify किया जाए, तो क्या A_1 भी साथ में बदलता है, या सिर्फ A_0 की नई state materialize होती है और A_1 वैसा ही रहता है—यह जानने की उत्सुकता है

    • इसे copy-on-write कहने की एक वजह है
      A_0 को modify करने पर write के समय उस फ़ाइल की copy बनाई जाती है, और A_1 को छेड़ा नहीं जाता
      https://en.wikipedia.org/wiki/Copy-on-write#In_computer_stor...
    • यह file system की copy-on-write क्षमता का इस्तेमाल करता है
      इसलिए A_1 को वैसा ही छोड़कर, A_0 के modifications के लिए एक नई copy बनाई जाती है। अधिक जानकारी के लिए https://developer.apple.com/documentation/foundation/file_sy... देखें

  • WWDC 2017 में Apple द्वारा APFS announce करने से पहले, iOS 10.x update के हिस्से के रूप में सभी iPhone को चुपचाप APFS में test-convert करके फिर HFS+ पर वापस कर दिया गया था—यह हिस्सा ध्यान खींचता है
    सोचता हूँ कि file system बदलाव गलत हो जाए तो उसे वापस कैसे किया जा सकता है। code को पर्याप्त रूप से verify किया जा सकता है, लेकिन अगर कुछ गड़बड़ हो जाए तो rollback असंभव लगता है

    • अगर मेरी याद सही है, तो HFS+ से APFS में migration data blocks को छुए बिना संभव है, और APFS metadata blocks और superblock को disk पर parallel में लिखा जाता है
      Apple के test migration में APFS superblock बनाने सहित पूरा migration किया गया, लेकिन HFS+ superblock को APFS superblock से permanently replace करने वाले commit से ठीक पहले रोक दिया गया। rollback करते समय बस बनाए गए APFS superblock और metadata blocks को “साफ़” कर देना था
    • presentation का वह हिस्सा देखा [0], लेकिन consistency test के तौर पर किया गया था—इसके अलावा details लगभग नहीं हैं
      production environment में बहुत चीज़ें टूटते देखी हैं, इसलिए इतना बड़ा migration चलाने को कहा जाए तो पता नहीं मैं button दबा पाऊँगा या नहीं
      [0] https://www.youtube.com/watch?v=IcyaadNy9Jk&t=1670s
    • लगता है कल्पना की कमी है। यह कोई ऐसा crown-jewel technology नहीं है जो सिर्फ Apple कर सकता हो
      open source दुनिया में भी ext file system को btrfs में convert करने वाला tool है, और (1) rollback किया जा सकता है तथा (2) btrfs file system इस्तेमाल करते समय original ext file system को भी mount किया जा सकता है

  • कहानी से शुरू करके समस्या को narrow किया, फिर दिखाया कि solution उस समस्या को जादू की तरह हल कर देता है
    यह बेहतरीन marketing का बहुत अच्छा उदाहरण है

  • एक विशाल NodeJS project folder पर चलाकर देखा, लेकिन 8.1GB folder में केवल 1GB बचत possible बताई गई
    user home folder तक include करके फिर चलाया, लेकिन 731K files, 127K folders और 2,755 target files के आधार पर कुल बचत सिर्फ 1.3GB रही। NodeJS folder alone चलाने की तुलना में लगभग 300MB ही ज्यादा
    System और Library भी scan करने की कोशिश की, लेकिन permissions issue की वजह से मना हो गया। package manager के रूप में pnpm इस्तेमाल करता हूँ, इसलिए शायद disk usage पहले से ही लगभग optimal है
    idea बढ़िया है, लेकिन मौजूदा price पर justify करना मुश्किल है; अगर यह महीने में एक बार background process की तरह चले तो अच्छा रहेगा

    • 8.1GB में से 1GB का मतलब है कि इस्तेमाल की गई जगह का 12% waste हो रहा था, है न? समझ नहीं आ रहा कि मैंने सही पढ़ा या नहीं
    • pnpm, npm का drop-in replacement बनने का लक्ष्य रखता है, और automatically deduplication करता है
    • macOS में sealed volume होते हैं, इसलिए System और Library में permission errors दिखते हैं
      https://support.apple.com/guide/security/signed-system-volum...
    • खुद try करने का समय नहीं मिला, लेकिन App Store screenshots में consider करने के लिए minimum file size option साफ़ दिखता है
      लगता है इसे comparison buffer घटाने के लिए लाया गया होगा, और संभव है कि node_modules की files इस size से छोटी होने के कारण consider न की गई हों
    • price कितना है, पता नहीं। लगता है कहीं भी public नहीं किया गया है

  • कभी इसी तरह की, लेकिन अधिक simple script बनाई थी जो same content वाली files को hard links में बदल देती थी
    मुख्य motivation Python virtual environments के packages थे। अक्सर similar packages install रहते हैं, और versions अलग हों तब भी कई files अब भी identical होती हैं। Numpy, PyTorch, TensorFlow जैसे कुछ packages काफी बड़े होते हैं, इसलिए काफी disk space बच सकता था
    https://github.com/albertz/system-tools/blob/master/bin/merg...

    • यह hard links या symbolic links का इस्तेमाल नहीं करता, बल्कि file system की copy-on-write clone बनाने की capability इस्तेमाल करता है [1]
      [1] https://en.wikipedia.org/wiki/Apple_File_System#Clones
    • uv इसे default रूप से करता है
      poetry, hatch, pdm जैसे दूसरे tools भी शायद ऐसा करते हों, लेकिन details ज्यादा इस्तेमाल नहीं की हैं इसलिए ठीक से नहीं जानता