Inlägg

Epilog.
Efter en hel del bråk med "rpi-clone" kunde jag clona SD-kortet medan det var monterat och dessutom få ner det från 16G till 8G. Det kunde bara göras om jag före justerade 8G kortet med gParted. Det var tvunget att minska ner stora partitionen ganska rejält och låta rpi-clone justera upp den. Det var lite handpåläggning. Vid tid ska jag krympa ner img-filen och dd:a över den till Target. Känns mer seriöst men att få cloningen att funka oavsett metod var viktigast.

Jag blir galen om detta är sant:

"A better option is the SD card copier (piclone) included in Raspbian itself , since it works with cards both smaller and bigger than the original. You must be running Raspbian on the Pi and need to use an additional USB cardreader (or USB harddisk/pendrive)."

*flin* Jag läste som hastigast "man dd" igår innan jag åkte hem från jobbet. Trodde jag skulle hitta nåt men hade inte mycket tid. Men nu så finns det en öppning med count vill jag påstå. Jag har ändå en obekräftad känsla av att det finns information i det som dd läst av Source hur stor SD-kortet ska vara så även om jag krymper ner img så det får ledigt plats på det nya lite mindre Target så kommer boot ändå att läsa in att "SD ska vara så HÄR stort men Target är inte det" och därmed göra halt. Men men...trägen vinner. Varför det vore lyckat är att vi kan ledigt använda 8Gigs SD-kort för hela OS+applikation är bara 5Gig.
Det blir mycket obetalt arbetstid det här. Tur för företaget att jag har det som hobby också. Ingen projekt har råd att betala för min löpande utbildning i Linux.

Angående din story om tar. Jag har alltid sagt att tvång är bästa läromästaren. Det låter som om du var tvungen att rädda vissa filer ur arkivet?
Som jag (tror) jag skrev så i och med mitt labbande med dd och andra program med min externa hårddisk ansluten till Raspberryn så "råkade" jag radera hela Ext.HD med bland annat en folderhiarerki med 17års data från mitt förra jobb. De jag nu är konsult åt. Jag gjorde i ett svep om Ext.HD till ett RPi SD-kort. Ha ha. Resten av datat var borta.
Jag blev totalt kallsvettig för detta data som försvann är kritiskt då jag använder det när de forna arb.kamraterna (numera beställare) ringer mig och frågar mig om diverse jobb jag gjort där. Min sambo undrade varför jag blev så blek. Lite senare drog jag mig till minnes att hade windows-arkiv på en secondary HD på min stora dator och i ett av dessa arkiv fanns en backup på detta viktiga data. Lärdom: Lokalt sparat data är farligt för dit når inte företagets nattliga backup.

Nu ska jag grepa lite tar-arkiv och sen testa count....tack för hjälpen förresten.

edit:
I gparted finns all information om den nerkrympta source-SD:n. Antalet sektorer och storleken på sektorerna. Det är bara å tuta o köra...

Ja. Det kan ju vara idealiskt men utan att gå in på detaljerna så tror jag att dd är bäst då den tar boot, sys.inställn. o allt annat.
Jag provade att krympa ner partitionen så när dd skapade sin image så skulle den inte vara så stor. Men dd tycks ta hela SD i alla fall så när jag skulle skicka över img till det nya något mindre SD-kortet så vad ändå denna Img för stor. Där brister jag i knowhow hur göra så att dd (eller nåt annat program) läser bara till sista partition o inte mer när den ska skapa img.

edit: Sen använder jag rsync för att göra backuper av det jag gör....det är en annan story.

Target SD-kortet ÄR mindre. Några 100 Meg som jag minns det. Det sade dd till om efter att den dumpat över img. Men jag tog nyaladdade SD-kortet ialla fall och stoppade i o körde. Då bootade den bara till hälften. Sen tvärstopp. Det var då jag läste om att man kan minska ner stora source med nån GIG och sen köra en img av den med dd. Låter det som en plan?

Sen vill jag testa rsync i virtualbox/Linux Mint mellan source o target. Kopiera fil för fil till det tomma (men monteringsbara) SD-kortet.
Det kanske är en annan historia...

Det som hände när jag använde dd för att "återställa" och det funkade faktiskt o boota target till och börja med MEN booten stannade mitt i . "KERNEL PANIC STOP" eller nåt sånt. Kollade med gparted o den meddelande att partitionen inte kan vara större än vad som var tillgängligt. target är ngt mindre än source.

Jag ska shirinka source med gparted tror jag på ett av de större korten (annat märke) men använda en test-SD först. Sen köra dd till ext. hårddisk. Sen göra en dd tillbaka till target (som är av ngt mindre storlek) och se om de funkar. Att bränna en hel image känns mkt bra för då följer allt med...kan zippa den och ha den i versionshanteringssystemet. Tror det är bra att använda bs=1M när dd används...

Ska också testa rsync från source till target i min windowsdator/linux. Har bra minnes-korts-läsare i den datorn.
Måste kolla längre upp i denna tråd hur rsync skulle konfiggas så systemet med filattribut kan följa med över obehindrat.

Testade med Raspibackup och lade över partitionsbackupperna på en Extern hårddisk. Skulle göra en restore till ett mindre SD-kort sen. Det var några meg för litet så det funkade inte. Sen gjorde jag en dd och lade den på samma externa HD. Gjorde en dd tillbaks till ett samma "lilla" SD-kort. dd larmade att det var för litet. Tröttnade ur lite då.
Nästa idé jag fick är att montera source och target i var sitt SD-kortläsare och stoppa de två i var sin kortläsare (som jag har på min stora windowsdator). På den datorn har jag Linux Mint i en virtualbox. Tänkte köra rsync och kopiera över alla filer till target....vad tror du/ni om det?

Kul att vi är i samma kommun. flush->sync->close...

edit: Detta bör väl bara gälla vid skrivningar till fil. Läsa fil bör räcka med fclose()

Om man använder fopen() så ska det ingå en fclose(), men vad göra om fopen() returnerar NULL? I min värld så behövs inte fclose om inte fopen lyckats.
I en annan tråd här så pratar vi om fsync(). Var ska den placerar i koden?

Så här har jag det:

FILE *f;

f=fopen(blabla);

if(f != NULL)
{
jobba jobba...

fsync(fileno(f));  //På remiss
fclose(f);
}
else
{
Error....
}

Om värdet av f == NULL har alltså inte fopen lyckats och därmed krävs ingen fclose()?
fsync kan kanske ersättas av fflush(). Det kanske är så att fflush() ska vara före fsync?

Tacksam för input i detta. Jag misstänker jag förenklar för mycket.
(PS/Jag jobbar i en Raspberry Pi o anv. gcc)

Då måste jag fråga; Kan det vara vettigt att skriva fflush(stream) före fclose() (fflush(NULL) flushar alla öppna filer) ? Som i PHP kan man ju skriva flush() för att tömma bufferten....

Edit:
"Note that fclose() flushes only the user-space buffers provided by the
C library. To ensure that the data is physically stored on disk the
kernel buffers must be flushed too, for example, with sync(2) or
fsync(2)."

Jag tror jag ska använda mig av ramdisk till de filer som används intensivt. Endast en del av dessa filer ska sammanställas och sparas för eftervärlden.
Ska testa detta under veckan. Senare får jag fundera på SSD för den "operativa delen" och ha enbart SD för boot.

Ska testa att byta SD-kort. Det är ju tråkigt att "Klass 10" kort också ger problem. Det är lite svajjigt.
Jag undrar om jag inte blir i förlängningen tvungen att ersätta SD-kortet med nåt annat....

Exakt. Jag hade velat ha mer kontroll på själva skrivningen också. Inte nöja mig med fclose() bara.

Aragon. Det är SD-kortet till Raspberry:n. Sorry. Lade tråden under enkortsdator men missade detaljen med RPi.

Frågan kanske skulle ha varit "Måste man handskas annorlunda med skriv/läs av filer på ett SD-kort relativt vanlig hårddisk?". Jag tänker då inte på antalet skrivningar/läsningar utan mer på om det måste till extra delayer efter stängning av filer eller annan form av "specialbehandling".

Det är svårt att förklara och "informera" mest på grund av problemet uppträder i funktioner som fungerar felfritt men vid intensiv användning av dessa funktioner så börjar filer på SD-kortet att vägra skriva om sig. När jag startar om programmet så fungerar det igen - EN gång. Sen inte mer (vid intensiv användning av funktionen som skriver på SD-kortet). Jag fick då en aning om att stängningen av filen inte fungerade så att NÄSTA användning av filen inte blev riktig. Lade in error-utskrifter och kollade retur-värden men det gav ingenting från vare sig fopen eller fclose.
Det var då jag började misstänka SD-kortet (som är av känt märke).
Så det är en "känsla" jag har. En "känsla" av att det kan vara nåt utanför koden som spökar. Därför ställer jag en fråga här om andra har upplevt att kortet inte alltid uppför sig korrekt. Speciellt vid intensiv skrivning.

Har nån här upplevt att SD-kortets funktion tillsammans med fopen/fclose och de vanliga fprintf/fscanf kan vara sämre?
Jag har en del oförklarliga fenomen när jag skriver till SD-kortet och jag har granskat koden och kan inte se några fel.
Har gjort logg på returvärdet på samtliga ingående funktioner och ser inga fel.
Jag begriper inte.
Nu lägger jag över de filerna till RAM-disk och testar där. Filerna är flyktiga ialla fall så det spelar ingen roll.
Men vill gärna höra era erfarenheter av filhantering (av många filer) på ett SD-kort.

Jo. Vi har en möjlig samarbetspartner i närheten. Det kan vara en (del) lösning. Vi har haft en här som "älskar" nätverk men han förde med sig en könssjukdom tror jag. Det är amputation som gäller nu.

Många bra synpunkter att ta till sig. Ni pratar om sånt jag aldrig behövt peta på. Fördelen med Forum är att kommentarerna är opartiska till skillnad mot säljare.

Med tanke på det ni säger så verkar det behövas en server. Jag antar att det beror på att den hanterar gemensamma files o folders effektivt. Dessutom logins och det affärssystem jag nämnde.

Jobbar på ett litet konsult-företag med 5 personer. Det finns en kass server driven av Windows Server eller nåt. Den servern driver ett mindre affärssystem(?) (Prodtime). Jag själv undviker o lägga filer (eller arbeta mot LAN) pga "skakigheten". Jag jobbar lokalt och sen gör jag backuper mot gemensam filplats. Nu muttras det som ett mantra "måste byta server". Orsak? När den ena personen slår på sin dator så däckar trafiken till administratören. 10 min väntetid på nåt dokument. Han är less på servern. Innan vi rusar på o installerar ny server vill jag tänkte ett steg längre. Vill lägga ett förslag på ett måndagsmöte. Därav detta inlägg.
Vad behöver vi? Plats att lagra gemensamma filer som vi kan komma åt utifrån, folders som kunder kan komma åt, affärssystemet med bla stämpla in o ut jobb, daglig backup.

Så min fråga är:
Måste vi ha en server? Finns affärssystem att lägga på en egen vanlig jäkla dator med utdelad katalog så folk kan stämpla? Vi behöver stämpling, löner, lager o budget liggande på det systemet.
Finns det nyare "moln" som man kan ha internt och vissa folders är utdelade till kunder?
Vad ska vi ha för gemensam plats, typ Projekt-foldern?

Vi använder inga tunga grafiska program mot nån gemensam dator. Det är lite dokument hit o dit och lite enklare CAD-filer.

Kom gärna med idéer. Tack.

cat test.h | perl -nE '/^#define ([^ ]+) "?([^\r\n"]+)"?/mg && say "define(\"$1\", \"$2\");"'

Bra! Jag gillar detta! Alla #defines är enkla utan specialtecken å sånt. Du nyttjar alltså Perl? Jag har de delar jag behöver för att åstadkomma detta.
Jag ska analysera parametrarna. Jag anar vad 'say' står för...