Bibliotheekresten vinden na het verwijderen van Mac-apps

Richt twee scanners voor restbestanden op dezelfde verwijderde app en je krijgt twee lijsten. Dat is geen bug. Elk programma kiest een eigen regel voor eigendom, een eigen weigerlijst, en een eigen grens aan beheerderswerk. Die drie keuzes bepalen alles op het scherm. Zodra je toeschrijven begrijpt, is restbestanden opruimen niet meer "wie vindt meer rommel" maar "wiens fouten minder pijn doen".

Deze gids gaat over de toestand erna: de app is al weg, of hij is net in de prullenmand beland, en je wilt resten gecontroleerd zien met dezelfde zorg die een verwijderprogramma had moeten gebruiken. Voor de volledige volgorde terwijl de app nog draait, zie volledig verwijderen. Voor productkeuzes, zie voorbij AppCleaner.

Een app naar de prullenmand slepen verwijdert alleen de bundle. De gegevens blijven onder ~/Library in Application Support, Caches, Preferences en Containers. Schrijf restbestanden toe op bundle-identiteit, nooit op grootte of naam, en controleer elke kandidaat voordat je verwijdert, of gebruik een verwijderprogramma dat precies dat afdwingt.

Wat "verwijderen" op macOS echt betekent

macOS behandelt een applicatie niet als één object met één verwijderknop. Er zijn minstens drie lagen:

Naar de prullenmand slepen garandeert alleen de eerste laag. De middelste laag is waar algemene tools helpen. De derde laag is waar ze vaak doen alsof en falen: stuurprogramma's, netwerk-extensies, hulpprogramma's met extra rechten, licentiedaemons. Apple zegt nog steeds een Uninstall-app van de leverancier te verkiezen om die reden (Apps verwijderen).

Waar gebruikersresten echt wonen

De meeste resten van derden clusteren onder de thuis-Bibliotheek:

Paden op systeemniveau onder /Library (LaunchDaemons, PrivilegedHelperTools, bonnen onder /private/var/db/receipts) zijn een hoger risiconiveau. Geef de voorkeur aan de verwijderaar van de leverancier. Behandel algemene scanners daar als alleen ter controle.

Een app in de sandbox ziet er vaak netjes uit: primaire container onder ~/Library/Containers/<bundle id>. Hij kan nog App Groups, Application Scripts, gedeelde caches, CloudKit of Sleutelhanger-onderdelen gebruiken. De sandbox vernauwt directe bestandstoegang. Hij garandeert geen voetafdruk van één map. Een app buiten de sandbox kan zich verspreiden over Application Support, Caches, Preferences, Logs, Saved Application State, WebKit en Cookies. Bredere spreiding betekent meer ruimte voor twee tools om het oneens te zijn.

Toeschrijven is de hele vaardigheid

Veilig restbestanden vinden hangt aan identiteit, niet aan marketingnamen.

Bundle-identiteit tegenover weergavenaam

com.example.widget is stabiel over hernoemen en lokalisaties. Weergavenamen niet. Twee producten kunnen een bedrijfsmap delen (…/Application Support/Google) terwijl er maar één is verwijderd. "Google" als tekenreeks matchen is hoe scanners fout-positieven van meerdere gigabytes verzinnen.

Identiteitsmatching is precies en stelt bijna nooit de gegevens van een zusterapp voor. Het mist mappen die de app naar zichzelf heeft genoemd.

Naammatching vindt die mappen, en ook dingen die alleen een woord delen. Het vindt meer en zit vaker fout.

Praktische controles vóór elke verwijdering:

mdfind 'kMDItemCFBundleIdentifier == "com.example.widget"'
ls /Applications ~/Applications 2>/dev/null

Als er nog iets met die id bestaat, behandel gedeelde ondersteuningspaden als levend.

Hulpprogramma's en ingebedde identiteiten

Moderne apps leveren hulpprogramma's met verwante id's: com.example.widget.helper, namen gedeclareerd in SMPrivilegedExecutables, inlogonderdelen onder Contents/Library/LoginItems. Een grondige scanner verzamelt die id's uit de bundle voordat de app verdwijnt. Nadat de bundle weg is, heb je alleen wat is vastgelegd of wat nog op schijf staat onder exacte namen.

Groepscontainers

~/Library/Group Containers/ bevat met opzet gedeelde suitegegevens:

• group.<bundle id>
• namen met team, zoals <TeamID>.<bundle id>
• gedeelde ruimtes group.* die meerdere apps gebruiken

Alleen exacte paden met eigenaar zijn kandidaten voor automatische koppeling. Gedeelde groeps-bomen horen alleen ter controle te blijven, of onaangeroerd als een zuster nog aanwezig is. Dit is de categorie waar tools die "meer vinden" echte schade veroorzaken.

Naamvarianten en kanaalbuilds

Foo Beta kan Foo Beta, FooBeta en soms een stabiele map Foo achterlaten die bij het releasekanaal hoort dat nog geïnstalleerd is. Basisnamen waarvan het kanaal is gestript hebben een hoog risico op fout-positieven: houd ze alleen ter controle tenzij je bewijst dat de stabiele app weg is.

Drie veilige instappunten

1. Eerst verwijderprogramma's van de leverancier

Beveiligingsagenten, VPN-clients, audiostuurprogramma's en endpoint-tools kennen hun eigen bonnen en de afbouwvolgorde van extensies. Draai die vóór een wandeling door de Bibliotheek. Bestanden wissen is geen betrouwbare deactivatie voor systeem- of netwerkextensies. macOS registreert ze.

2. Controleren nadat de app al weg is

Als de .app weg is, scan op paden die nog die bundle-id of exacte naam-varianten dragen. Conservatieve standaarden:

• Vaak in orde als het in eigendom is: caches, logbestanden, opgeslagen status, crashrapporten
• Zorgvuldig controleren: Application Support, Containers, Preferences (licenties, offline mail, projectdatabases)
• Meestal laten staan: Group Containers zonder exact eigendom, Documenten buiten de Bibliotheek, alles wat een andere id nog nodig heeft

Meet kandidaten:

du -sh ~/Library/Application\ Support/<Name> \
  ~/Library/Caches/<bundle.id> \
  ~/Library/Containers/<bundle.id> 2>/dev/null

Toestemmingsfouten betekenen meestal dat Terminal Volledige schijftoegang mist, niet dat de map leeg is.

3. Het moment dat de app in de prullenmand belandt

Veel mensen gooien eerst weg en denken later. Een wachter die een nieuwe .app in ~/.Trash ziet, de identiteit uit Info.plist leest, gerelateerde ondersteuningsbestanden scant, en een controlepaneel opent, vangt resten zonder een zoektocht. Ontwerpbeperkingen die nuttig van schadelijk scheiden:

• Wis de weggegooide app-bundle nooit automatisch (Zet terug moet werken)
• Pop nooit voor beschermde / AV- / MDM-klassen
• Verbruik een eenmalige onderdrukking als de opschoonapp zelf de app tijdens het verwijderen naar de prullenmand heeft gestuurd, anders racet het paneel met het verwijderverloop
• Poort op Volledige schijftoegang. Faal stil zonder die toegang in plaats van vanuit de achtergrond te vragen

De controle van restbestanden in de prullenmand van Mole gebruikt de identiteit van de weggegooide app om gerelateerde bestanden voor te stellen, houdt de app-bundle zelf terugzetbaar, en onderdrukt de prompt voor beschermde softwareklassen. De controle is alleen nuttig als die eigendomscontroles smaller blijven dan een zoekopdracht op naam.

Wezen zijn niet "alles wat groot is in de Bibliotheek"

Resten vinden van apps die je vergeten bent vereist claims aftrekken: som kandidaat-ondersteuningsmappen op, en trek daarna alles af wat geïnstalleerde software nog claimt (bundle-id's, draaiende apps, registratie bij Launch Services, leverancierswortels). Als de claim-scan gedeeltelijk is (time-out, onleesbare mappen), is het veilige resultaat nul wezen, geen goklijst. Tools die op een schone Mac altijd tientallen "rommel"-apps vinden optimaliseren voor een verkoopgetal.

Poorten op een rustige periode tellen ook: een configuratie die vorige week is herschreven kan bij een CLI-tool horen die de claimwandeling niet ziet. Recente mtimes horen kandidaten te onderdrukken.

Uitgewerkt voorbeeld: twee tools, één leverancierssuite

Je verwijdert Product A van een bedrijf dat ook Product B levert, nog geïnstalleerd.

• Tool 1 (zwaar op identiteit): kleine lijst, vooral paden com.vendor.productA.*.
• Tool 2 (zwaar op naam): voegt ~/Library/Application Support/Vendor (4 GB) toe en een groeps-container die beide producten gebruiken.

Tool 2 lijkt grondiger. Hij stelt de verwijdering voor die Product B kan breken. Het totaal onderaan het scherm is geen kwaliteitsscore. De categorieën erboven wel.

De verweesde bon van Homebrew

Als de app uit Homebrew Cask kwam, kan alleen de .app verwijderen een Caskroom-record achterlaten dat herinstallatie blokkeert. Na bestandsresten:

brew list --cask

Als het token blijft, wist brew uninstall --cask <token> de koppeling (accepteer --zap alleen als je de bredere opschoning van brew zelf wilt). "Cask is not installed" nadat de app al weg is, is een reden om het token te controleren en welke Homebrew-installatie je gebruikt, geen bewijs van een verouderde koppeling en geen reden om willekeurige Caskroom-paden met rm -rf te wissen.

Wat je weigert, ook als de naam matcht

• Nog geïnstalleerde zusters en kanaal-tweelingen
• Gedeelde groepscontainers en bovenliggende mappen van de leverancier
• Bonnen en hulpprogramma's met extra rechten zonder een gevalideerde verwijderaar
• Gebruikersdocumenten buiten de Bibliotheek
• AI-chatopslag en modelmappen die naast cachepaden zitten (AI-opschoning)

Veelgemaakte fouten

De gevonden lijst maximaliseren. Meer kandidaten betekent vaak slechtere toeschrijving.

Group Containers standaard wissen. Met opzet gedeeld.

Het verwijderprogramma van de leverancier overslaan voor VPN, antivirus, audio, virtualisatie.

Meten zonder Volledige schijftoegang, en dan concluderen "er is niets over".

De prullenmand meteen legen na een bulkverwijdering van resten. Houd een dag normaal gebruik als iets belangrijks verkeerd kan zijn toegeschreven.

Controleren

1. Meet verwijderde paden opnieuw.
2. Bevestig dat er geen inlogonderdeel of launch agent voor die id overblijft (opstartonderdelen).
3. Start zusterapps van dezelfde leverancier.
4. Leeg de prullenmand pas als je de verwijderingen accepteert.

Volgorde van bewerkingen

1. Zoek een verwijderprogramma van de leverancier als de app stuurprogramma's, extensies of hulpprogramma's had.
2. Exporteer of trek de autorisatie in terwijl de app nog draait, als dat ertoe doet.
3. Stop de app en zichtbare hulpprogramma's.
4. Verwijder de bundle (of bevestig dat hij al in de prullenmand staat).
5. Controleer resten op identiteit. Laat gedeelde containers met rust.
6. Handel Homebrew-caskbonnen af als dat van toepassing is.
7. Houd onderdelen in de prullenmand terwijl je de Mac normaal gebruikt, en leeg hem daarna.

De eerste dag na een verwijdering

De meeste mensen legen de prullenmand op het moment dat de app weg is. Een trager schema kost niets en houdt een weg terug:

1. Gooi op de eerste dag de app-bundle weg en alleen de caches waarvan je hebt bevestigd dat ze opnieuw op te bouwen zijn.
2. Laat Application Support en Containers met rust, en gebruik de Mac een dag normaal.
3. Als zusterapps en de andere producten van de leverancier nog schoon starten, verwijder de tweede batch.
4. Noteer voor paden waar je nog onzeker over bent de grootte met du -sh en beslis een week later.

De prullenmand staat op hetzelfde volume, dus er komt niets vrij tot je hem leegt. Wat het wachten koopt is een herstelvenster. Als de schijf echt vol is, leeg dan eerst de opnieuw op te bouwen caches voor marge en bewaar de betwiste paden voor later.

Toestemmingen en zichtbaarheid

Zonder Volledige schijftoegang kunnen Terminal en de meeste scanners niet in Containers en delen van de Bibliotheek kijken. du drukt toestemmingsfouten en eindigt toch met een totaal, en dat totaal mist alles wat het niet kon openen. De lezing is niet "er is niets over". Het is "je mag niet kijken".

• Geef Volledige schijftoegang aan Terminal, of aan de tool die de scan draait, en meet opnieuw.
• Vergelijk de getallen ervoor en erna. Beslissen vanuit de halfblinde ronde is hoe een container van meerdere gigabytes leeg wordt genoemd.
• Neem Volledige schijftoegang terug van tools die je niet meer gebruikt. Het is de breedste lees-toestemming op de Mac, en een toekenning overleeft de reden waarvoor hij is gegeven.

Hoe dit samenhangt met de gids voor volledig verwijderen

Volledig verwijderen is de volgorde om te volgen terwijl de app nog geïnstalleerd is: eerst het verwijderprogramma van de leverancier, exporteren of autorisatie intrekken, stoppen, de bundle verwijderen, daarna controleren wat over is. Deze gids gaat ervan uit dat de bundle al weg is, en dat haalt het makkelijke bewijs weg, en besteedt de lengte aan de helft die overblijft: beslissen welke bestanden de app bezat en welke hij alleen deelde.

Verder lezen

• Apple: Apps verwijderen op de Mac
• Gerelateerd: volledig verwijderen, alternatieven voor AppCleaner, wat opschoonapps nooit mogen verwijderen

Restbestanden opruimen is identiteitsonderhoud. De vaardigheid is niet gigabytes maximaliseren. Het is eigendom bewijzen, gedeelde status beschermen, en verwijderingen terugzetbaar houden.

Veelgestelde vragen

Is het veilig om restbestanden onder ~/Library zelf te verwijderen?

Alleen met toeschrijving: koppel de map aan de bundle-identiteit van de app, niet aan de grootte of een naam die erop lijkt, en controleer elk onderdeel voordat het weggaat. Eén verkeerde gok kan de gegevens van een andere app of je eigen documenten meenemen.

Waarom laten apps überhaupt bestanden achter?

macOS heeft geen verwijdercontract: de bundle naar de prullenmand slepen is het hele mechanisme, en alles wat de app tijdens het draaien schreef blijft waar het is geschreven.

Maakt een herinstallatie opnieuw aan wat ik heb verwijderd?

Opnieuw op te bouwen status wel: caches, bonnen en standaardvoorkeuren komen terug bij de eerste start. Documenten, chatgeschiedenis en licenties niet, en daarom selecteert een zorgvuldige tool vooraf alleen wat een herinstallatie opnieuw zou aanmaken.