Fat32, skrive filer.

[P@rm@nn]

Jeg har et problem, som jeg tror har med mountingen av vfat partisjonen min. Jeg har satt i en 160Gb FAT32 hardisk i linux maskinen og deler den via samba. Brukeren som kobler seg til har gid=100. Slik ser den akutelle delen av fstab ut;

dev/hdd1       /data/delt/     vfat    users,gid=users,umask=0000,code=437 0 0

Problemer arter seg slik;

Jeg skriver til en fil. Så stenger jeg å lagrer, og om jeg da åpner den så er alt der. Men så om jeg umounter disken og remounter disken så er plutselig filene tomme. De er der fortsatt, men tomme.

Noe veldig interesangt er at det IKKE skjer i den øverste mappen. Jeg mountet disken under /data/delt. Om jeg skriver tekstfiler der så forsvinner IKKE innholdet. Om jeg f.eks skriver i en tekstfil under /data/delt/skole SÅ forsvinner innholdet. Det gjelder uavhengig om jeg skriver den fra windows (via samba) eller fra linux logget inn som root. Etter en umount, mount så er innholdet i filen borte.

Er også interesangt at innholdet i filer skrevet FØR jeg flyttet disken til Linux ikke forsvinner, det er bare de tekstfilene jeg oppretter nå som mister sitt innhold, og som sagt bare i undermappene.

På forhånd takk for hjelpen.

 

 

EDIT; Krev først at det bare gjaldt tekstfiler. Merket nå at problemet også gjaldt *.MP3 filer. Var sikker på at det funker, men tydligvis ikke(har vist ikke prøvd å skrive *.mp3 til undermapper før). Det som er merkelig er at om jeg skriver en tekstfil fra linux så forsvinner innholdet. Men om jeg laster ned en film i linux så er den der. Det kan tyde på at det alikavell er noe spesielt med tekstfiler.

Så da blir problemet litt anderledes. Hvorfor forsvinner innholdet i filer jeg skriver i undermapper av mounten?

[GNUfan]

Eneste feilen jeg ser, er at gid= må være numerisk-ID..

Merkelig problem :S

Kjører du stable-kernel?

[P@rm@nn]

Eneste feilen jeg ser, er at gid= må være numerisk-ID..

Merkelig problem :S

Kjører du stable-kernel?

gid var 100 før jeg startet min "quest for anwser". En av de tingene som ble testet ut om hjalp. Er nå tillbake på 100 (som alle vanlige brukerene mine er medlem i).

cat /proc/version gir

Linux version 2.4.22-openmosix (root@localhost) (gcc version 3.2.3 20030422 (Gentoo Linux 1.4 3.2.3-r2, propolice)) #5 Sun Oct 19 00:21:30 CEST 2003

[kattemat]

Har du prøvd med en annen vfat driver?

[P@rm@nn]

Har du prøvd med en annen vfat driver?

Nei, det har jeg ikke. Jeg har bare brukt den som fulgte med kjernen, og ikke gjort noe med den. Nå "make dep && make clean bzImage modules modules_install" jeg "linux-2.4.20-gentoo-r8", er det kansje større sjangse for at den funker?

Du sier prøve med en annen vfat driver. Er måten man gjør det på å patche kjerne kilden med en diff fil så kjøre den kjernen? Om det er en annen måte så hadde det vørt fint med enten en forklaring eller en link til noe som forklarte. Et eksempel på en slik alternativ vfat driver hadde heller ikke vært å forakte

[kattemat]

Har du prøvd med en annen vfat driver?

Nei, det har jeg ikke. Jeg har bare brukt den som fulgte med kjernen, og ikke gjort noe med den. Nå "make dep && make clean bzImage modules modules_install" jeg "linux-2.4.20-gentoo-r8", er det kansje større sjangse for at den funker?

Du sier prøve med en annen vfat driver. Er måten man gjør det på å patche kjerne kilden med en diff fil så kjøre den kjernen? Om det er en annen måte så hadde det vørt fint med enten en forklaring eller en link til noe som forklarte. Et eksempel på en slik alternativ vfat driver hadde heller ikke vært å forakte

Det jeg mente var egentlig - har du prøvd med en annen kompilert versjon av vfat driveren... Litt dårlig formulert ;-)

Kompiler opp driveren selv - evt. en ny kernel. Om det fremdeles ikke funker har du iallfall eleminert muligheten for at det skal være et driverproblem.

[P@rm@nn]

Har du prøvd med en annen vfat driver?

Nei, det har jeg ikke. Jeg har bare brukt den som fulgte med kjernen, og ikke gjort noe med den. Nå "make dep && make clean bzImage modules modules_install" jeg "linux-2.4.20-gentoo-r8", er det kansje større sjangse for at den funker?

Du sier prøve med en annen vfat driver. Er måten man gjør det på å patche kjerne kilden med en diff fil så kjøre den kjernen? Om det er en annen måte så hadde det vørt fint med enten en forklaring eller en link til noe som forklarte. Et eksempel på en slik alternativ vfat driver hadde heller ikke vært å forakte

Det jeg mente var egentlig - har du prøvd med en annen kompilert versjon av vfat driveren... Litt dårlig formulert ;-)

Kompiler opp driveren selv - evt. en ny kernel. Om det fremdeles ikke funker har du iallfall eleminert muligheten for at det skal være et driverproblem.

Nå Kompilerer jeg som sagt en kernel versjon 2.4.20, den forgie var 2.4.22. Om de inneholder forskjellige vfat drivere vet jeg ikke. Men er vel uansett greit å (eventuelt) få utelukket at det at jeg kjører en modifisert kjerne (openmosix) har noe med det å gjøre.

[kattemat]

Bare for å komme med en liten avsporing mens du kompilerer

 

Bruker du openmosix? Synes du det funker bra? Jeg har bare så vidt testet det i jobbammenheng, men synes det virket interesant. Har tenkt på å sette det opp på noen bokser her hjemme...

[P@rm@nn]

Bare for å komme med en liten avsporing mens du kompilerer

 

Bruker du openmosix? Synes du det funker bra? Jeg har bare så vidt testet det i jobbammenheng, men synes det virket interesant. Har tenkt på å sette det opp på noen bokser her hjemme...

No clue om det funker :nice: . Foreløbig er det eneste linux maskin her i huset, så den får ikke sammarbeidet med så mange. Men har 2 maskiner til jeg skal sette opp her, så tenker på å teste da.

Lest en del om OpenMosix, og virker kjempe interesangt. Hadde vært kutl å lage en OpenMosix live cd så kjørt det på skolens 90 maskiner og sett hvor raskt en kjerne kompilering tar. Bare en tanke mens jeg sitter her å venter(nei, der ble den vist ferdig).

[P@rm@nn]

Jaja, da var Linux version 2.4.20-gentoo-r8 testet og samme feil fortsatt.

[P@rm@nn]

2 ting;

1)Jeg har også en ext3 partisjon på den disken, den har ikke de samme problemene. Altså nesten 100% sikkert at det har noe med mountingen av vfat.

2) Når jeg leser /etc/mtab så sier den dette

dev/hdd1 /data/delt vfat rw,noexec,nosuid,nodev,gid=100,umask=0000,code=437 0 0

Jeg vet ikke om det kan si noe eller om det er det logiske resultatet av min /etc/fstab

[kattemat]

2 ting;

1)Jeg har også en ext3 partisjon på den disken, den har ikke de samme problemene. Altså nesten 100% sikkert at det har noe med mountingen av vfat.

2) Når jeg leser /etc/mtab så sier den dette

dev/hdd1 /data/delt vfat rw,noexec,nosuid,nodev,gid=100,umask=0000,code=437 0 0

Jeg vet ikke om det kan si noe eller om det er det logiske resultatet av min /etc/fstab

Hva om du mounter den opp uten noen opsjoner?

Kommenter ut entryen fra fstab og gjør en 'mount /dev/hdd1 /data/delt'

[P@rm@nn]

Hva om du mounter den opp uten noen opsjoner?

Kommenter ut entryen fra fstab og gjør en 'mount /dev/hdd1 /data/delt'

Prøve dette, skrev til /data/delt/Skole/Tysk/test umount , mount /dev/hdd1 /data/delt og da var filen tom igjenn.

[xeon]

Hmm.. Jeg hadde samme problemet med en pendrive en gang hvis jeg ikke husker helt feil, problemet er at jeg ikke husker hva jeg gjorde, men skriv i hvertfall 'sync' i kommandolinja før du umounter, hvis det ikke virker kan du prøve msdos i stedet for vfat (eller noen andre passende, sjekk hva du har i /proc/filesystems)

[P@rm@nn]

Hmm.. Jeg hadde samme problemet med en pendrive en gang hvis jeg ikke husker helt feil, problemet er at jeg ikke husker hva jeg gjorde, men skriv i hvertfall 'sync' i kommandolinja før du umounter, hvis det ikke virker kan du prøve msdos i stedet for vfat (eller noen andre passende, sjekk hva du har i /proc/filesystems)

Desverre, ingen av de gjorde det bedre.

En ting, i windows ville jeg nå kjørt full diskscanning på partisjonen, finnes det et slikt verktøy for fat32 for Linux? Og når jeg først spør så finnes det et som defragmenterer den også (vet at linux ikke skal trenge det, men det er vell for ext 2/3 , reiserfs o.l?)

Flere tips tas gjerne imot.

[P@rm@nn]

Nå skjedde det noe her.

Jeg kjørte "dosfsck /dev/hdd1" og dette var resultate;

localhost root # dosfsck /dev/hdd1
dosfsck 2.8, 28 Feb 2001, FAT32, LFN
Warning: FAT32 support is still ALPHA.
There are differences between boot sector and its backup.
Differences: (offset:original/backup)
 71:20/00, 72:20/00, 73:20/00, 74:20/00, 75:20/00, 76:20/00, 77:20/00
 , 78:20/00, 79:20/00, 80:20/00, 81:20/00
1) Copy original to backup
2) Copy backup to original
3) No action
? 1
Reclaimed 9 unused clusters (294912 bytes).
Free cluster summary wrong (586206 vs. really 586215)
1) Correct
2) Don't correct
? 1
Leaving file system unchanged.
/dev/hdd1: 5821 files, 3808393/4394608 clusters

Dette er egentlig ikke det interesange. Det som er interesangt er at det etter at jeg gjør dete ligger en haug med nye filer i øverste mappe i filsystemet. De heter "fsck[0000-9999].rec", altså f.eks fsck0001.rec så oppover. De er ALDRI mindre enn 32 Kb. Når jeg åpner en av de i en teksteditor så finner jeg ting eg har skrevet (F.eks "dette er en test"). Pluss en del skrabbel på slutten.

En av de var akkurat like stor som en mp3 jeg har skrevet til disken før, jeg renamet den og den funket kjempe å spille.

 

Så er spørsmålet, sier dette dere noe?

[xeon]

Ehm .. forsåvidt.. Har du prøvd å lage filsystemet på nytt? det kan hende det hjelper, samtidig så kan du få den til å sjekke etter dårlige blokker på disken

[P@rm@nn]

Ehm .. forsåvidt.. Har du prøvd å lage filsystemet på nytt? det kan hende det hjelper, samtidig så kan du få den til å sjekke etter dårlige blokker på disken

Du mener å formatere den partisjonen så opprette filsystemet på nytt? Jo, det har vært en tanke. Ulempen er at jeg da mister de 116Gb med data jeg har liggende der, og jeg har ingen mulighet for å ta backup av slike mengder.

Så vil helst ha en annen løsning.

[Smidt]

ja det hadde i grunn vært greit.

 

ingen som kan hjelpe P@rm@nn her?

[P@rm@nn]

ja det hadde i grunn vært greit.

 

ingen som kan hjelpe P@rm@nn her?

Hehe takk for støtten Smidt.

Men fant en løsning; Dra på lan, kapre 3 Pc'er klokken 4 om natten. Last dine 106Gb over på de, formater og last tilbake. Kjører nå reiserFS, helt uten problemer. Synd at jeg ikke fikk det fikset på en annen måte, men var vel bare et slikt problem som ikke var verdt å finne den "ekte" løsningen på, ville ta for mye tid å resurser. (vedder på at noen nå forteller meg en 1-2-3 løsning)