Denna delen av 99 uppdateras inte längre utan har arkiverats inför framtiden som ett museum.
Här kan du läsa mer om varför.
Mac-nyheter hittar du på Macradion.com och forumet hittar du via Applebubblan.

iPhoto försvunnen i Yosemite?

Tråden skapades och har fått 35 svar. Det senaste inlägget skrevs .
  • Medlem
  • International user
  • 2015-05-05 09:34
Ursprungligen av bjorsi:

De är som folk skrivit tidigare, hardlinks.
Kör daisydisk eller något liknande program där man ser hur mycket plats olika filer tar. Jag har ett iphotobibliotek på 88 gb och ett photos bibliotek på 88 gb (enligt finder dvs). I själva verket har jag 88gb bilder på hårddisken.

Kan någon förklara varför hardlinks rapporteras som de gör?

  • Medlem
  • Karlskoga
  • 2015-05-05 10:57

Vad ska den annars rapportera, 0 B? Då blir det helt fel om du skulle ta bort en annan hard link, då skulle den sista helt plötsligt få allt utrymme, fast den hade 0 innan.
När du använder hard links finns det ingen som är "master", som det gör vid soft links (alias). Alltså inget som är "ansvarigt" för utrymmet filen tar. Flera hard links kan peka på samma fil utan någon inbördes rangordning.

Ursprungligen av kenjon:

Vad ska den annars rapportera, 0 B? Då blir det helt fel om du skulle ta bort en annan hard link, då skulle den sista helt plötsligt få allt utrymme, fast den hade 0 innan.
När du använder hard links finns det ingen som är "master", som det gör vid soft links (alias). Alltså inget som är "ansvarigt" för utrymmet filen tar. Flera hard links kan peka på samma fil utan någon inbördes rangordning.

Det var det där som jag försökte mig på att beskriva men gav upp:)

Det är väl också så att om du kopierar en katalog som har hårda länkar till en annan disk så flyttas innehållet i filen till den nya disken och tar upp utrymme på den. Då måste du kunna se hur mycket utrymme som behöver allokeras.

Men det är ganska kul att 1+1=1

  • Medlem
  • International user
  • 2015-05-05 12:19
Ursprungligen av BlackSmp:

Det var det där som jag försökte mig på att beskriva men gav upp:)

Det är väl också så att om du kopierar en katalog som har hårda länkar till en annan disk så flyttas innehållet i filen till den nya disken och tar upp utrymme på den. Då måste du kunna se hur mycket utrymme som behöver allokeras.

Men det är ganska kul att 1+1=1

Det här stör mig, jag skulle vilja att de kom på ett system för softlinks som tog bort behovet av hardlinks helt.

Är spotlight indexerings filen full av hardlinks? För det skulle förklara varför en här på forumet hade filens storlek raporterad i flera TB även om personens hårdskiva var långt mindre.

Ursprungligen av juanito:

Det här stör mig, jag skulle vilja att de kom på ett system för softlinks som tog bort behovet av hardlinks helt.

Är spotlight indexerings filen full av hardlinks? För det skulle förklara varför en här på forumet hade filens storlek raporterad i flera TB även om personens hårdskiva var långt mindre.

Men det är ingenting som du behöver bekymra dig om eller störa dig över. Det är olika systemnära tjänster som använder sig av hardlinks, det är ingenting som du som användare behöver "bry" dig om.

Jag har svårt att tro att storleken på indexeringsfilen skulle få en rapporterad storlek som är större än hårddisken pga hardlinks. Jag kan inte se någon uppenbar anledning till varför indexeringsfilen skulle innehålla hårda länkar

  • Medlem
  • International user
  • 2015-05-05 13:55
Ursprungligen av BlackSmp:

Men det är ingenting som du behöver bekymra dig om eller störa dig över. Det är olika systemnära tjänster som använder sig av hardlinks, det är ingenting som du som användare behöver "bry" dig om.

Behöver och behöver, jag bryr mig :). Gamla macos hade väldigt bra alias system, tyvärr fungerande de inte om man flyttade en fil till en annan hårdskiva. Men annars så var aliasen länkad till en unik handle för filen som inte var synlig för användaren. På såvis behövdes inte sökvägar användas.
Om man bara kunde få liknande system som är oberoende av var det är lagrat, vore det kanon.

Bevaka tråden