lime

Jeg er ikke egentlig ute etter hvordan det gjøres programmeringsmessig osv men mere på generelt grunnlag. Jeg skal prøve å forklare litt grundigere:

 

1.Prosess A har da som sagt en fil åpen i minnet med data som har blitt endret men ikke enda skrevet til disk.

1.Prosess B ser at Prosess A har en fil åpen i minnet men pga at filen er kritisk for Prosess A kan den ikke stenges.

3.Prosess B må da finne en mekanisme som garanterer at Prosess A skriver uendrede data til disk FØR Prosess B skriver over filen.

 

Med mindre Prosess B og Prosess A er spesfikt programert for å kommunisere med hverandre ser jeg ikke noen praktisk måte å gjøre dette på.

 

Det måtte isåfall finnes en felles funksjon for alle prosesser som kan aktiveres for å garantere at prosesser med åpne filer skriver endret data til disk før filene endres. Dette ser jeg som litt innviklet å gjennføre i praksis.

 

Lurte litt mere på om lime feks kunne forklare dette.

Det er ingen vits å gjøre det vanskeligere enn det er. Det som skjer er at sistemann som skriver til filen, har skrevet til filen.

Skriver prosess a til filen, og så prosess b, og så a igjen. Så er det a sine data som er lagret.

Når dette er sagt, så er det mulig å få til fil låsing i Unix-verdenen også, men det gjøres ikke på samme måte som i Windows. Litt mer info finnes her: http://en.wikipedia.org/wiki/File_locking

Huff, jeg burde holde meg for god for dette, men :/

La oss ta dette innlegget bit for bit.

Jeg vil gjerne komme med litt teknisk informasjon til alle dere som diskuterer om Windows eller Linux er best når det gjelder omstarter.

Som jeg sa tidligere, ingen har diskutert dette så en slik uttalelse minner om forsøk på trolling eller oppvigleri.

Du kan heller ikke lest mange av innleggene siden du tror vi mangler såpass teknisk innsikt?

Se innlegg #12-17 og #23.

La oss først slå fast fakta: Det er et teknisk problem. Plattformen Windows er årsaken.

Jøss, sier du det? Ja for det er vel windows man snakker om i den sammenhengen?

Ja, rett og slett, og det tar innlegget mitt grundig for seg.

Og så får jeg forklare litt.

Og her kommer mer av det opplagte regner jeg med.

Hva forsøker du å si her?

Windows startet den gangen en PC var en enbrukerting.

Hm, sikker på at du tar helt feil her. Kan du dokumentere at ingen PCer kjørte noen form for flerbruker OS på denne tiden? Forøvrig startet Windows mye senere enn PC.

Personal Computer er det visst en forkortelse for.

Jeg som alltid har trodd det stod for Personal Calculator. Hvem er målgruppen din her, for det kan jo ikke være denne tråden. Forøvrig er det ingen knytning mellom navnet PC og hvorvidt OSet som puttes på den er enbruker eller flerbruker.

Jeg tok dette med fordi jeg gikk ut ifra at folk forstod sammenhengen mellom ordet "Personal" og "Enbruker". En datamaskin per bruker. En stor kontrast til flerbrukersystemer med flere terminaler koblet til, som var det store før pcen kom.

Unix fra bunnen av en flerbrukerplattform. Den arven har Linux også.

Du vet tilfeldigvis ikke hva Unix stammer fra. Om du googler det vil du se at det er opplagt at den har et flerbrukerfokus. Noe som ikke er like opplagt om du ser på hva Linux ofte brukes til i dag.

Dette tok jeg med for å illustrere hvorfor det er et problem på Windows, og ikke på Linux. Enbrukerfokuset Windows springer ut fra gir direkte utslag i mange omstarter i dag. Flerbrukerfokuset til Unix, og også Linux gjør at man ikke kunne forvente at f.eks. filer var åpnet eksklusivt, eller at koden til en prosess aldri ble endret etter at prosessen var startet. Dermed sitter man i dag og kan overskrive programmer som er i bruk, og filer som er åpne. Dette har jeg forklart mer utfyllende i et svar til fenererbest.

Windows har blitt utvidet til å ha støtte for flere brukere, men arven som et enbrukersystem er der den dag i dag.

Noe sier meg at du ikke har jobbet mye teknisk med Windows. Du har fått med deg NT? Hva tror du fokuset var med NT?

Resten følger litt i samme stil selv om det forsøker seg med en teknisk vinkling. Fenderbest svarer også godt på akkurat det.

Jeg har jobbet ganske mye med Windows, Unix og Linux de siste 10 årene. Jeg er godt kjent med problematikken med åpne filer både fra Unix-siden og Windows-siden. Fokuset med NT var å lage et flerbrukersystem som var binærkompatibelt med Microsofts tidligere operativsystemer. Inkludert alle tidligere "snarveier" og problemer.

I tillegg mistenker jeg, men det får stå for min egen kappe, så var fokuset å gjøre det ukompatibelt med andre operativsystemer, slik at ISVer som utviklet programvare til Windows ville få det veldig vanskelig å porte applikasjonene til andre plattformer. Men det er en helt annen diskusjon.

En åpen fil i minnet er knyttet i Windows gjennom et Handle. Så lenge prosessen har en åpen handle til filen kan den ikke skrives til. Om du stenger handelen til filen - feks via Process Explorer kan filen overskrives. (Så lenge det ikke eksisterer data i minnet som ikke er blitt skrevet til disk.)

 

Der er dermed ikke nødvendig å starte hverken prosessen eller Windows på nytt for å gjøre dette.

 

Grunnen til at Windows startes på nytt er rett og slett at det fører til mindre problemer. Som regel er det ingenting teknisk sett som forhindrer dette men bare at det generelt sett fungerer bedre.

Jeg ser at mange forsøker å debunke innlegget mitt, men alle motinnleggene har akkurat dette argumentet til Fendererbest som aksiom, så jeg skal forsøke å tilbakevise dette.

Jeg forsøkte å forklare ting med et forståelig og lett språk, men det er jo litt mer teknisk enn den lettere populistiske forklaringen jeg kom med.

Fendererbest har helt rett når han sier at det bare er å lukke filehandelen ved hjelp av en tredjepartsapplikasjon som kan kontrollere kjernen, slik som Sysinternals Process Explorer, og på den måten kunne overskrive en prosess' åpne filer.

Jeg har heller aldri påstått at det ikke går. Påstanden min var: "at man alltid kan stole på at når en prosess har åpnet en fil, så er det eksklusivt. Ingen andre kan endre på denne filen. Prosessen har full kontroll.". Dette er et grunnleggende premiss i Windows-verdenen. Det betyr at tusenvis, om ikke millioner av programmer er avhengige av at operativsystemet fungerer slik. Alltid. Tukler du med det, så brekker du potensielt alle programmer som forventer at det skal være sånn.

Fendererbest: Prøv å dra vekk filhandler fra prosesser som f.eks. System, svchost.exe, smss.exe og lignende og se hvor stabilt systemet ditt er etterpå.

Men jeg kan til dels ta til meg litt av kritikken siden det var en ting jeg ikke tok opp i det hele tatt i det forrige innlegget mitt. Nemlig hvordan Windows takler at man skriver over en executable fil som er mappet til minne. Forsøk: Prøv å overskrive explorer.exe. Windows vil ikke la deg gjøre det. Du kan hacke litt for å få det til, men det vil garantert få explorer.exe til å krasje.

Microsoft har flere workarounds til dette. Du kan avslutte prosessen, overskrive, og starte den igjen. Du kan også bruke noen va microsofts verktøy, for eksempel http://support.microsoft.com/default.aspx?...kb;en-us;228930 som lar deg markere filer for overskriving ved neste omstart (ja her har vi omstartsproblematikken), eller APIet Restart Manager: http://msdn.microsoft.com/en-us/library/aa...28VS.85%29.aspx som Microsoft Installer har støtte for.

Så igjen, problemet er designet til Windows:

1) Programmer forventer at åpne filhandler ikke endres, noe som leder til:

a) Operativsystemet beskytter åpne filhandler, ved å ikke la deg overskrive åpne filer

b) Programmer som forventer at filhandelen er åpnet eksklusivt av det får problemer om a) ignoreres (f.eks. ved at man leter opp filhandelen og stenger den manuelt).

2) Eksekverbare filer som er mappet til userspace minne, kan ikke overskrives.

Jeg vil gjerne komme med litt teknisk informasjon til alle dere som diskuterer om Windows eller Linux er best når det gjelder omstarter.

La oss først slå fast fakta: Det er et teknisk problem. Plattformen Windows er årsaken.

Og så får jeg forklare litt.

Windows startet den gangen en PC var en enbrukerting. Personal Computer er det visst en forkortelse for. Unix fra bunnen av en flerbrukerplattform. Den arven har Linux også.

Windows har blitt utvidet til å ha støtte for flere brukere, men arven som et enbrukersystem er der den dag i dag. Der du først og fremst merker det er når det gjelder låsing av åpne filer.

Dette beror først og fremst på et designvalg gjort for lenge siden av utviklerne av Windows. Nemlig at man alltid kan stole på at når en prosess har åpnet en fil, så er det eksklusivt. Ingen andre kan endre på denne filen. Prosessen har full kontroll. Dette er ikke noe problem i enbrukerscenarier, trodde man.

Du har kanskje merket akkurat dette når du forsøker å slette et dokument du har åpent i windows. Eller endre navn på det. Av og til får du feilmeldinger om at det ikke er nok plass eller lignende, og av og til får du litt mer beskrivende feilmeldinger. Men problemet er det samme: Du får ikke overskrevet/endret filer som er i bruk.

Unix har en annen tilnerming. Åpner du en fil, og leser dataene, så er det nettopp det du gjør. Dataene lastes til minnet, og kilden til dataene er "glemt". (Populistisk sagt) Du kan slette kildefilen, overskive den, gjøre alt mulig med den. Operativsystemet bryr seg ikke, og det bør heller ikke prosessen gjøre.

"Hvor er poenget ditt?" Spør du kanskje? Vel, det kommer her: Når du oppdaterer en fil i windows (installerer oppdateringer), så er jo ofte denne filen i bruk, den er jo en del av operativsystemet tross alt. Ergo får man ikke oppdatert den. Hva gjør man da?

Istedenfor å fikse det grunnleggende problemet (filer i bruk kan ikke overskrives (og dermed potensielt ødelegge alle programmer som tar det for gitt at slik fungerer det)), så har Microsoft fikset dette på flere finurlige måter. En måte er å markere filene som "skal overskrives av disse nye filene ved neste omstart". Og vips, så kommer ballongen opp: "Windows er oppdatert, du må starte om maskinen". Og gjør du ikke det, så er du ikke oppdatert, for de gamle filene er fremdeles i bruk.

På Linux, så er det ikke fullt så farlig. Fordi filene blir skrevet over, og du trenger strengt tatt bare å starte om prosessen på nytt for at programmet skal lese de nye filene. Det er ikke så lett å starte kjernen på nytt, så det er derfor man må starte om maskinen om kjernen oppdateres. Men med med tekniske finurlige løsninger, som ksplice, så kan man til og med unngå det.

Tihi, kunne ikke dy meg:

Tusen takk for fin og interessant artikkel. Jeg skjønner selvfølgelig at man ikke kan få med alt når en lager en så generell artikkel som dette, selv om den er lang.

Men jeg vil bare legge til at når det gjelder Linux og virus, så er man mer motstandstyktig av flere årsaker enn bare en bedre generell sikkerhetsmodell. Mange Linuxdistroer inkluderer SELinux, og/eller pax-kjerner, som kverker programmer som ikke oppfører seg ordentlig eller utviser symptomer på at gjør ting som tyder på at her utnyttes buffer overflows o.l.

Og så vil jeg bare si at det er ikke nødvendig å bruke GNU biblioteker/verktøy for å bruke Linux, mange embedded Linux utgaver bruker f.eks. miniatyrverktøyene busybox som erstatning for gnu-tools (inkludert FSF sin egen distro (Debian) sin installer) og uclibc som erstatning for gnu libc. Så Linux er ikke alltid ensbetydende med GNU/Linux. Et eksempel på dette er dd-wrt, som er en Linux-distro for trådløse accesspunkter.

(edit: skrivefeil)

Dette er helt feil, er varene bestilt via internett _er_ det postordrekjøp/varen er kjøpt utenfor fast utsalgssted (hjemme hos deg, ved din datamaskin). Og loven gjelder i dette tilfellet. Det de snakker om her er kjøp over disk, og det er dette definitivt ikke.

I serien med perfirerte opplysninger: Windows XP sin ip-stack er ren klipp og lim fra BSD.