Program (x86) - tryggt radera mappen?

[laban1]

Vill ha lite plats på C-disken och funderar vad nytta jag har av Program(x86) mappen. Den är nu på ca 10GB och om jag förstått rätt så är det 32 bitars program. Vad har jag för nytta av denna mapp då jag kör W10 64 bitar? Många installers för musik kan man inte välja 32 eller 64 bitar utan den installerar båda vare sig man vill eller inte. Hur resonerar ni?

[Sostenuto]

Det skulle jag inte rekommendera. Även om du använder ett 64-bitars Windows har du säkert en hel del 32-bitarsprogram installerade i den mappen. Själv har jag 64-bitars Windows 7 och 64-bitars Windows 10 på mina datorer, men kör exempelvis en 32-bitarsversion av Office 2010. Dessutom är min erfarenhet att många ouppfostrade 64-bitarsprogram fortfarande föreslår att de ska installeras till foldern ”Program (x86)”. Om man då inte själv ändrar sökväg vid installationstillfället är det naturligtvis där de kommer att hamna.

Om du har ont om diskutrymme är det nog bättre att gå via kontrollpanelen och försöka avinstallera de program som du säkert vet att du inte kommer att behöva. Och det är naturligtvis bra att ta en fullständig backup innan om du senare skulle ångra dig.

[laban1]

Tack för svaret! 

En annan fråga om utrymme: kan jag flytta Sampel filer (för ljudbibliotek) till SSD genom länkar/genvägar på något
bra sätt? Ibland finns det inget sätt att göra det i installern. Prövade att göra det via genvägar på C som pekar till F som jag fått tips om, men det verkar som att systemet fortfarande tror att filen ligger kvar på C eftersom använt utrymme inte går ner. Kanske ligger infon kvar i registret eller någon annan stans att filerna finns kvar på C.

Något tips kring detta?

Redigerat 26 augusti 2018 av laban1
tydlighet

[Sostenuto]

Det är lite oklart vad du menar med länkar/genvägar. Om du menar att du har skapat en symbolisk länk/directory junction med kommandot mklink /j så har jag sett uppgifter om att använt diskutrymme som rapporteras på källdisken fortfarande kommer att inkludera de filer som fysiskt flyttats till en annan disk. Men jag har aldrig själv brytt mig om att kolla om så verkligen är fallet, eller (och kanske mer viktigt) om det har någon praktisk betydelse när rapporterat diskutnyttjande eventuellt överskrider källdiskens lagringskapacitet.

Om så skulle vara fallet finns det ju en risk att ett installationsprogram kan hävda att disken är full, trots att den egentligen inte är det.

Det är väl i så fall en sån sak man lär märka den dag det inträffar.

[peterT]

Om du har program som du inte använder kan du gå till lägg till/ta bort program, och ta bort det du inte använder. Istället för att ta bort mappar manuellt.

[laban1]

Tack för feedback! Jo, liknande så här har jag gjort, ofta inte med mappar men med individuella filer:

WINDOWS - MOVING THE STEAM DIRECTORY AFTER INSTALLATION
1. Drag or copy the STEAM folder from your installation drive (C:\ProgramData\Spectrasonics) 
to the hard drive location of your choice.
This can be another drive partition, a secondary internal drive or an external hard drive 
such as a Firewire or USB2 hard drive, etc.
2. Next, right-­click the STEAM folder in the new location to create a “Shortcut To STEAM”.
3. Next, copy the shortcut to C:\ProgramData\Spectrasonics.
4. Finally, make certain to remove the “Shortcut To ” from the name (including removing the spaces), 
leaving the folder shortcut named STEAM

[Sostenuto]

Om du har flyttat filerna fysiskt till en annan disk och sen bara lagt en vanlig genväg dit, har jag ingen förklaring till varför Windows fortfarande skulle räkna med det utrymmet som upptaget på källdisken.

[laban1]

Så verkar det vara, någon förhoppning om att skapa symbolisk link med mklink skulle vara bättre?

[Sostenuto]

Det beror väl i ditt exempel på hur Omnisphere fungerar med en genväg som pekar på en flyttad Steam-folder, något jag själv inte har en aning om. Har du följt Spectrasonics egna anvisningar borde det ju fungera utan att du ska behöva skapa en symbolisk länk. Jag kan bara anta att Omnisphere är skrivet för att internt kunna använda sig av just denna genväg som om det vore en lokal folder.

Som jag skrev tidigare kan det finnas problem med hur fritt utrymme på källdisken rapporteras när symboliska länkar används mot en annan disk. Jag har därför svårt att i det här fallet se hur symboliska länkar skulle lösa ditt problem med rapporterat diskutrymme, när en genväg i exemplet ovan borde göra precis det.

 

[laban1]

Tack för din feedback! Testade att skapa symbolisk länk till Sonivox strings, länken funkade men det uppfattade utrymmet på C var detsamma efter omstart av datorn tyvärr. Precis samma som vad en "vanlig" genväg gav. Vad är det för praktisk skillnad på symbolic link och directory junction?

[Sostenuto]

Symbolic link är ett överordnat begrepp som bland annat kan avse en directory junction. Kommandot mklink har några olika parametrar där alternativet /j skapar just en sån:

https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/mklink

Själv har jag mest använt kommandot för att skapa directory junctions till foldrar på andra platser när jag vill undvika dubbellagring.

Ett exempel:
Jag använder XLN Audio Addictive Drums. AD2 har möjlighet att under menyn BEATS även visa External MIDI, dvs MIDI som inte ingår i AD2:s egna MIDI Packs. All MIDI som placeras i foldern ”C:\Users\[Användare]\Documents\Addictive Drums 2\External MIDI Files” kommer att dyka upp i AD2 under BEATS efter en refresh. Men – jag har trumrelaterad MIDI utspridd på många olika platser över två diskar och vill undvika den redundans som skulle uppstå om jag kopierade alla dessa filer till Documents. För att undvika dubbellagring har jag därför i stället skapat ett antal directory junctions från foldern ovan till de olika platser där min övriga trumrelaterade MIDI lagras. Exempelvis kommer följande directory junction att dyka upp som ”Loop Loft” i drop-down-listan i AD2 under BEATS > Library > All External MIDI.

mklink /j "C:\Users\[Användare]\Documents\Addictive Drums 2\External MIDI Files\Loop Loft" "C:\MIDI Library\Loop Loft\MIDI Drum Loop Bundle"

Namnet på länken i första argumentet kan sättas till vad som helst. I stället för "Loop Loft" hade jag kunnat skriva t.ex. "General MIDI Drum Beats". Eller nåt.

[laban1]

Coolt! Har du använt symbolic link eller liknande som i mitt problem att sampel biblioteket syns på C trots att det ligger på F som hos mig? Eller har du ngt annat tips gällande detta? Har testat att skapa symbolic link och det blev inte bättre för det, i linje med ditt tidigare svar.

[Sostenuto]

Nej, jag har bara använt directory junctions för att smidigt kunna komma åt filer som ligger utspridda lite var som helst från en central folder för att undvika dubbellagring. På ungefär samma sätt som jag igår beskrev hur jag samlar trumrelaterade MIDI-filer gör jag även för att knyta utspridda wave-filer till en central Sample-folder utan att för den skull behöva kopiera filerna dit.

[laban1]

Tack för din feedback, ska hålla din lösning av dubbellagringen i minnet!