vad händer med bilden....

[Gutta]

epep skrev:
FAT är i väl ett filsystem som namngetts av FAT - file allocation table. Den datastruktur som bygger upp hela systemet. I början hade fat inga kataloger utan endast en "root" som kunde innehålla ett visst antal filer. Så är det fortfarande, även om jag inte kommer ihåg antalet filer, men jag tror det är 1024. Varje fil innehåller 2 olika uppsättningar information. Dels filnamnet och dels en pekare in i Filallokeringstabellen. Varje enhet (12, 16 eller 32 bitar) i tabellen motsvarar 1 bestämt kluster på hårddisken. Efter att filen i roten pekat ut den första "enheten" i FAT så följer en kedja där varje enhet i FAT pekar på nästa FAT-enhet som ingår i filen. Denna kedja motsvarar sedan som angivits direkt de kluster som filen hittas under. Underkataloger, dvs alla kataloger andra än roten, är egentligen vanliga filer men som har en katalog flagga. Operativsystemet tolkar sedan innehållet i dessa filer på samma sätt som det tolkar innehållet i rootkatalogen, dvs som filnamn med pekare in i fat osv. Så kom inte och snacka om att jag inte kan FAT. Och, på vilket sätt menar du att FAT inte är ett filsystem?

Jag orkar inte "kriga" om själklarheter men som du själv säger
file allocation table = FAT. Men FAT finns i många olika filsystem som inte nödvändigtfis heter FAT. Och FAT som i dagligt tal menas filsystem är eg FAT12, FAT16 eller FAT32. I övrigt är du rätt på det förutom att du påstår att det endast skulle klara av 1024 filer....

För övrigt är inte min intention att säga att du inte kan FAT men du hade ju ett antal felaktiga påståenden i dina föregående inlägg som du valt att inte kommentera nu....

 

[epep]

Hmm, i FAT32 verkar även root-katalogen ligga i datadelen. Undrar hur de implementerat det?

 

[epep]

Gutta skrev:
Jag orkar inte "kriga" om själklarheter men som du själv säger
file allocation table = FAT. Men FAT finns i många olika filsystem som inte nödvändigtfis heter FAT. Och FAT som i dagligt tal menas filsystem är eg FAT12, FAT16 eller FAT32. I övrigt är du rätt på det förutom att du påstår att det endast skulle klara av 1024 filer....

För övrigt är inte min intention att säga att du inte kan FAT men du hade ju ett antal felaktiga påståenden i dina föregående inlägg som du valt att inte kommentera nu....

Den enda möjliga felaktigheten var den största klusterstoleken i FAT16. Klusterstorlekar kan dock ändras. I tidigare implementationer av FAT16 var klusterstorleken sådan att det blev 2GB. Leta själv på nätet så får du se. Rootdirectoriet i åtm FAT12 o FAT16 har en bestämd storlek och kan inte rymma mer än ett begränsat antal filer. Kolla vilken spec av FAT du vill. Det är just pga att FAT är ett filsystem. Katalogstorleken även i FAT32 är begränsad, men inte i samma utsträcknig.
Se tex:
http://www.microsoft.com/technet/pr...Ref/50cd4ffc-1389-423d-9d02-1a898b2eb39f.mspx
Där 512 anges som det största antalet filer i rootabellen. Jag har dock för mig att MS halverade det för det och att det hade något med långa filnamn att göra. Är dock osäker och det är ointressant. Det inressanta är att det finns en begränsing av antalet och hur denna begränsning uppkommer, vilket jag förklarade. Jag skrev dessutom att jag _trodde_ att det var 1024.

Om du med FAT menar enbart en filallokeringstabell vilken som helst, kan det naturligtvis finnas i vilket filsystem som helst. Normalt när man talar om filsystem och FAT brukar man dock mena det filsystem som härör från DOS (eg QDOS). FAT är i allt språkbruk rörande datorer liktydigt med filsystemet FAT eller den filallokeringstabell som FAT använder. Vill man referera till någon obestämbar fillallokeringtabell brukar man säga just "filallokeringstabell" och inte FAT. Så är i varje fall den normala terminologin när filsystem diskuteras. Så FAT är ett filsystem eller den filallokeringstabell som används av FAT, och filsystemet FAT är samlingsbenämningen på filsystemen FAT12, FAT16, FAT32 etc.

Som sagt läs microsoftlänken ovan och wikipedialänken i den förra postningen.

 

[epep]

epep skrev:
Hmm, i FAT32 verkar även root-katalogen ligga i datadelen. Undrar hur de implementerat det?

Ahh, de lägger in informationen om var root-katalogen ligger i parameterblocket i bootsektorn.

 

[Estethia]

nu vet ni det säkert redan, men nu vet jag det oxå.
en D100 kör FAT32.

 

[ture]

epep skrev:
Du kan nog lägga vilket filsystem du vill på ett CF-kort tex. Varför inte köra med ext3. Inte för att att kommer att gå att läsa i kameran, men det går att formatera kortet det för det filsystemet. NTFS också för den delen.

Lätt offtopic, men...: Jag gjorde just det (ext3) en gång, bara för att testa. Funkade fint med kortet i läsaren på Linux-datorn. Sedan satte jag det i min EOS10D och tryckte av. Till min stora förvåning protesterade den inte, utan tog glatt bilder, fast sedan gick det inte alls att mount:a kortet på linuxburken, varken som FAT eller som ext3, och fsck fick spatt.

 

[Damme]

Säkert mänger av ettor och nollor som försvinner, men datorn sitter hela tiden med checksummor och görom om det inte stämmer.. om jag inte minns fel så sitter processorn och rättar för 40% av tiden den är igång..



Men, man ska alltid ha backup, bränan ut skivor, 2st en som man använder, och en som man inte använder.

jag har filerna på min dator, samt på min serverdator, sen bränner jag ut en gång i månaden och lägger i ett brandsäkert skåp. jag har fått en krachad hårddisken engång .. alla bilder från 2003 försvann.. efter det så backupar jag gärna en gång för mycket än för lite

 

[Estethia]

ja fett med backup bör man ha.
jag bränner alltid tre skivor. två som sitter i en cd-pärm och en som jag låser in i bankfack.
nitiskt kan tyckas, men hellre många kopior än förlorade bilder.

 

[Thunderbird]

anders_j skrev:

Det känns som bilden/filen borde bli sliten typ

Nej.

/ E

 

[epep]

Damme skrev:
Säkert mänger av ettor och nollor som försvinner, men datorn sitter hela tiden med checksummor och görom om det inte stämmer.. om jag inte minns fel så sitter processorn och rättar för 40% av tiden den är igång..

På en hårddisk ligger MTBF otroligt högt. Inte allt minne har heller "checksummor". Jag skulle gissa att det är _väldigt_ _väldigt_ _väldigt_ sällan som det blir något fel i dataöverföringen internt (mellan cpu och minne etc) i datorn eller mellan datorn och hårddiskarna. På hårddiskar tror jag inte ens att det finns felkontroll av typen checksummor eller liknande för lagrad data (om man inte kör RAID).
Hårddiskar krachar dock lite då och då, men det är nog inte beroende på fel i dataöverföringen utan har mer att göra med att hårddiskhuvudet dunkar ner i skivan, att motorerna går sönder etc. Och även detta händer sällan - dock tillröckligt ofta för att man ska göra backup.

Lagring av brända CD-skivor är dock en helt annan femma. Här är det helt befogat att ta det lite varligt. Ffa skulle jag tro att det är bra att bränna om dem med jämna mellanrum tex vart 5:e år för viktig information. Detta säger dock utan något empiriskt stöd. Man ska dessutom skydda CD-skivorna mot värme och direkt solljus.

 

[epep]

ture skrev:
Lätt offtopic, men...: Jag gjorde just det (ext3) en gång, bara för att testa. Funkade fint med kortet i läsaren på Linux-datorn. Sedan satte jag det i min EOS10D och tryckte av. Till min stora förvåning protesterade den inte, utan tog glatt bilder, fast sedan gick det inte alls att mount:a kortet på linuxburken, varken som FAT eller som ext3, och fsck fick spatt.

Hoho. Kul ide.

 

[digitalzero]

Har oxå testat annat filsystem en gång, formaterade ett xD-kort till HFS+, fast det gick inte alls å köra i kameran, fick 'card error'.