Korrupt filstorlek, 15,3TB i en mapp

Korrupt filstorlek, 15,3TB i en mapp

Har en mapp på mitt skrivbord som inga filer fungerar i samt Windows verkar ha flippat totalt när det gäller filernas storlek. Enligt Windows 10 så är "size" någon gigantisk hitta på summa medans "size on disk" faktiskt skulle kunna stämma.

Om jag går in i mappen och kollar en specifik fil ser det ungefär likadant ut på allihopa, något i stil med det det nedanför så här verkar inget stämma. Det är bilder vi pratar om, kanske några MB styck.

Har kört CHDISK utan resultat och att kopiera mappen går inte då Windows kräver just 15,3TB för att genomföra det.

Några idéer?

Mapp:
Size: 15,3TB
Size on disk: 12,6 GB

Separata filer:
Size: 8,88GB
Size on disk: 8,88GB

För er som inte orkar räkna så är det alltså 1 768st filer i mappen om det skulle spela någon roll

@MonsterGuden: fixa en live-CD iso av nån Linuxdistro, gör en sticka, och kika på din mapp i en bootad linux. Kan avslöja saker mycket snabbt.

Skrivet av guermantes:

@MonsterGuden: fixa en live-CD iso av nån Linuxdistro, gör en sticka, och kika på din mapp i en bootad linux. Kan avslöja saker mycket snabbt.

Jag testade att starta en gammal elementary sticka och det ser tyvarr inte battre ut har, det som gar att saga ar att jag inte kan mounta med skrivrattigheter da disken innehaller nagon windows cache data.

ls -lh
-rwxrwxrwx 2 root root 8.9G Nov 9 2018 IMG_1.jpg
-rwxrwxrwx 2 root root 8.9G Nov 9 2018 IMG_2.jpg
-rwxrwxrwx 2 root root 8.9G Nov 9 2018 IMG_3.jpg
-rwxrwxrwx 2 root root 8.9G Nov 9 2018 IMG_4.jpg
.....

I unix-världen kan man göra filer med 'hål' i dvs allokera en fil som är 15 TB rent adresseringsmässigt med tex. lseek, men det är bara dom sektorer man skriver något i som sedan skrivs ned på disken. Följaktligen om man försöker fylla filen genom att skriva den hela vägen så kommer disken ta slut innan man når ändan av filen sas.

NTFS har varit POSIX-kompatibel och det kanske är något program som har gjort något liknande och i somliga fall förstår skalet/GUI att redovisa den verkliga platsupptagandet och andra fall bara ser den angivna filstorleken.

Många program ser inte filer med 'hål' i vid tex. kopiering (då sektorer man inte skrivit i levererar '0'-värden vid läsning) och då försöker skriva kopierade filen fullt (med nollvärde på alla sektorer som inte används ännu) på mottagar-mediat och andra program som tex. rsync med rätt flaggor kan överföra filer med 'hål' i utan att försöka skriva hela filen och bara de sektorer som har data i sig vid kopiering.

Senast redigerat 2019-06-13 21:46
Skrivet av MonsterGuden:

Jag testade att starta en gammal elementary sticka och det ser tyvarr inte battre ut har, det som gar att saga ar att jag inte kan mounta med skrivrattigheter da disken innehaller nagon windows cache data.

ls -lh
-rwxrwxrwx 2 root root 8.9G Nov 9 2018 IMG_1.jpg
-rwxrwxrwx 2 root root 8.9G Nov 9 2018 IMG_2.jpg
-rwxrwxrwx 2 root root 8.9G Nov 9 2018 IMG_3.jpg
-rwxrwxrwx 2 root root 8.9G Nov 9 2018 IMG_4.jpg
.....

Du måste stänga av windows på rätt sätt - håll ned shiftknappen när du klickar knappen för att stänga av windows - windows stänger inte filsystemet vid en normal avstängning utan är fortfarande 'mountad' och filsystemet är inte stängd utan mer status att man ryckte ur sladden under drift och filsystemet markerad 'dirty'...

Linux vill normalt inte montera en sådan filsystem skrivbart när den inte är stängd på korrekt sätt.

Om man ser vad du fått fram så verkar det vara en massa filer tillverkade med bara 'luft' i - dvs av någon anledning har man allokerat filer med fixt storlek men sedan inte fyllt något i dem (och skrivit på disken och därmed tar plats) för att någon process förmodligen inte gjort det som det är tänkt, och eftersom disken inte fylls med data så finns det alltid mer plats än tänkta nya storleken för ny fil och den kan skapa nya filer i 8.9GB storlek mycket länge - tills directoryts namnfält tar upp hela diskutrymmet typ, eller slå i en filsystemsbegränsing som antal filer under samma direktory.

Senast redigerat 2019-06-13 22:15

Nu har jag testat lite allt möjligt utan resultat.

Gjort en image med dd som jag sedan kort foremost på.
sudo dd if=/dev/sdb2 of=/mnt/image.img
sudo foremost -b 1 -t jpg -T -i image.img

Även försökt med en ddrescue utan resultat
ddrescue /dev/sdb /dev/sdc ~/log_file --try-again --verbose --force

Körde också e2fsch och smartctl som jag fick tips om.

Fler förslag eller är det kört?
Det är bilder från speciellt två resor jag skulle vilja få tillbaka

Senast redigerat 2019-06-22 14:41

Av resonemanget innan så är det förmodligen bara några få av dina 8.9 GB filer som har något innehåll alls - resten har helt enkelt misslyckas att skrivas ned alls pga. någon process/program i samband med inspelandet har krachat.

Prova program som är specialist på att göra 'data scraping' typ recuva och motsvarande diskräddningsprogram med fokus på foto och film - försök hitta en som känner igen den filformatet som inspelade programmet producerade (dvs. om det är mpeg, jpeg, mjpeg, H264, H265 etc.) då om inspelningsenheten har eget format som tex. RAW-format så kan det missas av dessa program.

I dessa lägen går man på 'magic word' som kan identifiera filkroppen och därmed hitta starten på filen och så läser man på sekventiellt tills det är något annat som inte känns igen för filen och så letar den efter nästa filstart. Har du otur så är inte speciellt mycket skrivet och därmed filerna du hoppas hitta - aldrig skrivits ned på disken...

Kan tilläggas att filerna har fungerat tidigare, så någon gång i historien har dom fungerat i exakt denna mapp. Helt säker nu när jag äntligen fått fram vilka bilder det är jag saknar =/

Ska kolla på något liknande recuva, återkommer

Testade precis att använda recuva som bara verkar kopiera mina 8GB trasiga data vid recover så inget vettigt resultat där.

Testade också Stellar Repair for Photo som mer eller mindre bara konstaterar att bilderna är väldigt trasiga och inte går att återställa.

Kan tilläga att båda är gratisverisionen om det kan påverka resultatet.

Finns det något mer som går att testa eller är det dags att inse att windows/hårddisken/slumpmässig händelse har förstört mina bilder?

Har hittat några ställen där bilderna använts så dom har garanterat fungerat en gång i tiden i den mappen som nu är korrupt.

Inte säkert att betalversioner gör det bättre - ofta vill man visa att man är duktig och hitta filerna i sina demo/prova på-versioner - men får betala för fullversion om man skall få ut mer än några någon GB med filer - dvs. med demoversionen gör att du kan kontrollera resultatet men inte så mycket mer innan man betalar...

Du kan ha hamnat i läget att disken faktisk _är_ sönderskriven av någon orsak och är $MFT sönderskriven (den heliga men ömtåliga metadatafilen som håller reda på allting på NTFS-disken) så är det jobbigt på riktigt och kanske ännu värre om den inte gått sönder fullständigt då diskräddningsprogram fortfarande tror att man kan använda denna för att hitta filer och inte försöka leta efter filerna ändå med bara filernas magic-number att leta med (kan ta många timmar till hela dygn i det läget innan det visar eventuell resultat) - allt som svarar snabbt skall du betrakta med stor misstänksamhet - då att plöja igenom en disk tar tid när man skall granska varenda sektor...

Jag har minst en klon liggandes från tidigare test, kan det hjälpa programmen om jag tar bort mappen och filerna så dom faktiskt ser ut att vara borttagna? Som sagt dålig koll men dök upp i huvudet när jag läste ert svar

Skickades från m.sweclockers.com

Det finns många skäl att hålla data utanför Windows. Själv har jag en server som kör Gentoo-linux där nästan all data ligger på en 10T-disk. En samba-server och nfs-server ser till att data nås bekvämt från Windows och från en media-server. Detta är en billig lösning och Windows-datorn hålls fri från viktig data.

Skrivet av Irre:

Det finns många skäl att hålla data utanför Windows. Själv har jag en server som kör Gentoo-linux där nästan all data ligger på en 10T-disk. En samba-server och nfs-server ser till att data nås bekvämt från Windows och från en media-server. Detta är en billig lösning och Windows-datorn hålls fri från viktig data.

Har numera en NAS där alla bilder ligger

Skrivet av MonsterGuden:

Har numera en NAS där alla bilder ligger

NAS med extra backup hoppas jag!

Skrivet av cheben:

NAS med extra backup hoppas jag!

Just nu är det ne NAS med speglad hdd, funderar på om den ena disken borde vara backup istället. Men min hdd är 1TB så antar att min backup hdd måste vara ganska stor isf, vet inte riktigt hur man räknar på sådant

En backup är en disk som man kopplar in - gör backuppen - koppla ur och lägger undan rent fysiskt var gång. backupen bör helst också vara av generationstyp - dvs en ny backup förstör inte den föregående versionen utan är kvar så att man kan backa i generationer. filsystem som btrfs kan med snapshot och innan ny backupp och använder rsync när man gör spegelkopian av NAS:en gör att man kan ha gamla versioner kvar paralellt med de nytagna.

Arkiveringsprogram som Borg-Backup kan också hantera backup-generationer och packar mycket väl både med kompression och dedupliciering på chunk-nivå - dvs. alla dubbletter ned till en viss storlek på några kByte sparas bara en endaste en gång i backup-repositoriet - även efter att du möblerat om fullständing på din NAS med att flytta bilder, döpa om namnen eller har multipla kopior på samma bild utspridda i nasens filsystem. samma sak med diskimage som tas med kortare mellanrum - den andra versionen (och versionerna därefter) sparas bara dom bitar som är förändrade gentemot (alla) de föregående versionerna!

---

Allt som är online-kopplat (dvs kan få omedelbar access till filerna när som helst) , delar samma nätaggregat/huvudsäkringar i en fastighet eller styrs av samma CPU är inte att betraktas backup oavsett hur många diskar det är eller vilken avancerad RAID-lösning du använder - för allt kan slås ut på en gång av en enda åsknedslag, av felaktigheter på moderkort (med RAM-minne som felkälla) och bakplan eller att du får en Ransomware-angrepp från någon av dina inkopplade klientdatorer - eller bara ren vanlig mänsklig misstag....

Backup är när du har diskarna urkopplade och undanlagda det mesta av tiden och på helst annan plats än din lägenhet och/eller backup på en molntjänst.

Senast redigerat 2019-11-01 16:57

För att tillägga, rätt smart är att på en NAS köra molntjänst (onedrive tex) och köra envägssynkning därmellan.

Jag har satt upp såhär med Onedrive och Synology.

1. Tar bild med mobil.
2. Synkar automatiskt upp på Onedrive, även via mobildata.
3. Onedrive synkar med min NAS hemma.
4. Onedrive synkar med min PC hemma.

Då har jag helt plötsligt en kopia på 4 medier. Lite jobbigt om man vill ta bort en bild helt men utöver det så funkar allt prima.

Skrivet av Sh4d0wfi3nd:

För att tillägga, rätt smart är att på en NAS köra molntjänst (onedrive tex) och köra envägssynkning därmellan.

Jag har satt upp såhär med Onedrive och Synology.

1. Tar bild med mobil.
2. Synkar automatiskt upp på Onedrive, även via mobildata.
3. Onedrive synkar med min NAS hemma.
4. Onedrive synkar med min PC hemma.

Då har jag helt plötsligt en kopia på 4 medier. Lite jobbigt om man vill ta bort en bild helt men utöver det så funkar allt prima.

5. Sen på en fest blir nån full snubbe svartsjuk för att du snackar med hans tjej och föreslår att han ska ta en bild på er med din telefon för "hans tjej ser så snygg ut i nya frisyren och hans mobil är urladdad" och eftersom du är full och tycker hans tjej är snygg räcker du över telefonen, och vips raderar han alla dina bilder vilket synkas direkt via mobildata och raderar på dina andra enheter också. Hoppas du snapshottar NASen regelbundet.

Skrivet av guermantes:

5. Sen på en fest blir nån full snubbe svartsjuk för att du snackar med hans tjej och föreslår att han ska ta en bild på er med din telefon för "hans tjej ser så snygg ut i nya frisyren och hans mobil är urladdad" och eftersom du är full och tycker hans tjej är snygg räcker du över telefonen, och vips raderar han alla dina bilder vilket synkas direkt via mobildata och raderar på dina andra enheter också. Hoppas du snapshottar NASen regelbundet.

Haha, envägssynkning på NASen och ingen åtkomst via mobilen till den.
Måste dock eventuellt sätta upp snapshot.

Linux har funktion i ext4, BTRFS mfl. där man bara kan göra write once - read many (WORM) och att man bara kan göra append (tillägg/utökning) men aldrig ändra det som redan är skrivet.

directoryt brukar då behövas sättas för append medans filen kan vara av typen när den väl stängs så kan den sedan inte modifieras eller tas bort.

BTRFS kan göra subvolym-snapshot med read-only och går inte att återställa till manipulerbar form med vare sig standard fil-funktioner, chattr, xattr eller setfacl utan man måste använda vissa BTRFS-kommandon för att lösa låset (vad de egentligen gör är att sätta quota till 0 för subvolymen - då finns heller ingen som helst utrymme tillåten för att någon som helst modifikation vare sig på metadatat eller lagrade datat - kort sagt man måste frigöra utrymme för att modifiera och att frigöra utrymme kräver extra utrymme temporärt - med andra ord med quota satt till '0' så är allt totalfruset fullständigt inom subvolymen)

Givetvis om man har kontroll på servern så kan man ta bort sådana saker igen (via chattr,xattr och i fallet BTRFS - med BTRFS-kommando) men är man i luser-rollen (...användare) och envåldshärskaren på servern har satt upp det så - så kan man aldrig ta bort igen något som en gång skrevs...

Gissar att det var ett försök för blidka de kraven som finns inom vissa finans-världar i USA att allt skall loggas och inget kan modifieras i efterhand - men har man fysiska åtkomsten eller root-rättigheter till diskarna så kan det _alltid_ manipuleras.

Det jag sett är kraven att journaler av den typen (och gälla i juridiska sammanhang) måste printas på papper rad för rad medans det sker (med matrisskrivare på löpande pyjamas-papper då det anses svårt att modifiera efteråt på papper utan att det syns spår av det och man kan se av egenheter och nålarnas defekter i skrivaren om texten härrör från skrivare eller kommer från annan källa) eller att man senare tid bränner sektor för sektor i DVD+/-R skivor medans det uppdateras just för att det inte skall vara manipulerbart i efterhand då all text där kan låsas mot skivans unika serienummer och dess sektornummer med hash som garanterar innehållets orördhet (alla tillverkade skrivbara DVD och uppåt har unika serienummer inskrivet med laser på skivan och kan läsas av vissa program) - den typen av loggar kan alltså inte kopieras till annan media utan att dess äkthet ifrågasätts.