Wiki-filer för Windows?

[Nerre]

Loggfiler och liknande stängs normalt varje gång det skrivs till dem, annars försvinner ju datat vid strömavbrott.


Sen spelar det ju ingen som helst roll var bilderna lagras, om det är på samma server eller en separat server. Kruxet är ju hur de lagras. Ska bilder lagras utan versionshantering eller?

[Spisblinkaren]

Det beror ju på vad man menar med bilder.

Personligen tänker jag, för att försöka förstå, ping-bilder från MS Paint.

Jag ritar alltså en massa scheman i paint och vid ett visst läge anser jag att schemat är hyfsat färdigritat och då sparar jag.

Om jag börjar dag ett och sparar men dag två kanske kommer på att jag vill ändra, och då ibland grovt, så då ger jag filen ett nytt löpnummer och sparar.

Det är så jag arbetar idag.

Med min ide så behöver jag inte ändra löpnummer utan jag kan spara om med samma filnamn.

I det här fallet har då filvektorn två element där det ena är från dag ett och det andra från dag två.

Sen hur man implementerar det här är jag ganska ointresserad av för faktum kvarstår, Wikipedia fungerar på det här sättet!

MVH/Roger
PS
Jag har jobbat lite med inbyggda system och jag är inte helt säker på att du har rätt i det här:

Loggfiler och liknande stängs normalt varje gång det skrivs till dem, annars försvinner ju datat vid strömavbrott.

Loggfiler är dessutom ren text och de upptar inte så mycket minne ty varje bokstav består typ av bara en enda byte

[TomasL]

Roger, du är den enda i hela världen som behöver detta, vi andra har det redan iom att vi använder lite modernare programvara än vad du gör.
Följaktligen finns det inga som helst behov, i det du föreslår (med undantag av att du behöver det, installera då ett versionshanteringssystem, så är det klart)

[Spisblinkaren]

Struntprat, problemet sitter i OS, inte i nån tilläggsmjukvara.

Varför nyttja mjukvara för att fixa till ett OS som inte fungerar?

Det borde väl vara OS som är så att säga bäst?

MVH/Roger

[TomasL]

Du har det inte, eftersom du använder programvara som borde varit borta för 15 år sedan, använder du modern programvara så finns det implementerat.
Och nej, jag vill aldrig ha det implementerat i os, Föredrar att ha det på separat server, så det är tillgängligt var jag än är, och oberoende av att min dator kraschar, eller liknande.

[Spisblinkaren]

Fast min näsa är nog lite längre än din.

Om revisionshanteringen satt i OS så blir ALLA filtyper att vara revisionshanterade.

Detta gör att vuxna icke-nördar kan våga leka med datorerna modell hur barnungar leker med datorerna.

Gissar att alla filtyper på datorn knappast täcks av tilläggsmjukvara.

MVH/Roger
PS
Idag är datorkunnande dedikerat en slags elit och tänket kring hur datorer fungerar har också en jargong som är dedikerat en elit, jag tycker det är dags för svensson att fatta nåt och genom att våga prova sig fram så kan svensson lära sig saker. Datorkunnande skall inte vara dedikerade nån elit, ALLA är mer eller mindre beroende av nån slags dator. Så varför inte göra så att dom flesta har chansen att förstå? Eller ska man behöva logga på på forum för att få svar?

[mrfrenzy]

Revisionshantering finns inbyggt i OS. Installera Windows Server 2019 och aktivera "Tidigare Versioner".
Då kan du ställa klockslag varje dag när snapshots ska tas och på alla filer kan du högerklicka och visa revisioner månader och år bakåt i tiden.

Det fungerar lika bra på bilder som textfiler.

[Spisblinkaren]

Det är mycket man inte vet här i världen

MVH/Roger

[janno]

Tidigare versioner (filhistorik) kan du väl få i vanlig Windows (utan server) också, satt och funderade på om den kom i Windows 7 eller Windows 8. Det räcker väl att man slår på det i inställningar och har en backupdisk vald.

[Nerre]

Varför nyttja mjukvara för att fixa till ett OS som inte fungerar?

Vad är ett OS om inte mjukvara?

De flesta OS består av en massa olika program som samarbetar med varandra. Det är en minoritet av användarna som skulle glädjas av versionshantering, de flesta skulle bli sura på att diskutrymmet tar slut. De användare som verkligen vill ha versionshantering kan ordna det på en massa olika sätt.

Vad säger att den version som eventuellt skulle vara inbyggd i operativsystemet är mest lämpad för alla användare?

Ett bra operativsystem har fördelen att du kan anpassa det utifrån dina behov. (Det är därför jag gillar Android bättre än iOS.)

[Spisblinkaren]

Det är en minoritet av användarna som skulle glädjas av versionshantering, de flesta skulle bli sura på att diskutrymmet tar slut.

Nu var du där igen dvs du tycks ha en förmåga att se omöjligheter istället för möjligheter.

Fast jag tycker det är kul och intressant att du fortsätter argumentera

Du syftar naturligtvis till typ loggfiler som bara växer och växer när dom, enligt dig, sparas flera gånger per minut.

Med lite flexibelt tänkande kan man föreställa sig en klickruta i properties hos filen där man för en gångs skull avaktiverar revisionshantering samtidigt, som jag påstått tidigare, som loggfiler är ren text dvs de varken tar, eller behöver ta, speciellt mycket utrymme på hårddisken som du nu antyder.

Observera att default för alla filtyper på datorn ska vara revisionshanterande, tycker jag.

Men visst, om det passar dåligt så stäng av revisionshanteringen då, svårare än så är det inte.

Problem solved

Samtidigt är det väl ändå som så att extremt många läs/skriv-cykler till godtycklig typ av minne "sliter ut" minnet, eller?

Så det är knappast rekommendabelt att göra enligt Nerre's exempel dvs skriva ofta till nåt minne, jag skulle rekommendera att man skiter i om det blir strömavbrott (för det är lite som risken att träffas av blixten) och kör revisonshanterat ändå.

Jag ser fortfarande inga övertygande argument mot att man inte skall köra revisionshanterat rakt av på alla filtyper.

Vad säger att den version som eventuellt skulle vara inbyggd i operativsystemet är mest lämpad för alla användare?

Bara för att alla kan dra nytta av det samtidigt som det knappast är i vägen...

Vad är ett OS om inte mjukvara?

Lite småkorkad kommentar, tycker du inte det själv?

Skillnaden som jag ser det är att ett OS är basen/plattformen för dina övriga program som du installerar och jag tycker att basen ska vara just en bas dvs utomstående företag (alltså sådana som ej tillverkat OS:et) ska inte tjäna pengar på att skapa ett revisionshanteringsprogram när det är av sån fundamental betydelse för folk att det bör finnas redan i OS.

Det är lite som att utomstående företag skall tjäna pengar på hur mycket syre du förbrukar.

Utomstående företag ska (få) tjäna pengar på mer finessrik programvara såsom t.ex CAD-programvara.

Idag kom jag på en annan intressant sak som dock bara lite hänger ihop med tråden.

Jag skriver i exempelform för jag suger på data-jargong och jag tror att dom flesta fattar bättre vad jag menar då:

Jag backar mina viktigaste filer en gång om året till ett 32GB-stick (som blir halvfullt bara).

Jag har två stick som jag växlar mellan för att typ ha backup på backupen

Jag vill gärna backa min musik så jag har försökt att ta ett av sticken där gammal musik redan finns och önskat kopiera DIFFEN till det sticket.

Men se, det går inte

Vad man måste göra är alltså att kopiera mappen med alla musikfiler och kopiera över mappen på sticket med dom gamla musikfilerna där man rätt skälvklart egentligen tycker att bara diffen ska kopieras.

Det är som när man vill stoppa in en bok till i bokhyllan så måste man ta ut alla böcker och stoppa in dom igen, tillsammans med den nya boken, alltså.

Det här är ju FRUKTANSVÄRT primitivt!

Varför har inte OS synkroniseringsmöjlighet likt iTunes/iPod?

Att kunna synkronisera mappar tycker jag är lika självklart som revisionshantering.

MVH/Roger
PS
Att kopiera hela mitt musikbibliotek (~10GB) tar säkert 45 minuter, att kopiera diffen på ett år om max 50 låtar tar nog bara nån minut...

[Nerre]

Nej, jag syftar inte på loggfiler som växer, jag syftar på att folk skulle få disken fylld av gamla versioner av filer som de inte är intresserade av.

Det är inte så många år sen diskutrymme sågs som dyrt. Därför gjorde man backup till band (som var billigare).

[xxargs]

Problemet med versionshantering oavsett om det är i en existerande filsystem eller revision på en backuppdisk/molntjänst är tex.:

Hur många generationer bakåt vill du ha det?, tidsbestämt??, storleksbestämt - hur och med vilka regler skall det rensas - skall alla ändringar sparas (journalförande) på filbasis, skall man komma åt varje version separat och parallellt samtidigt (som BTRFS snapshot som ger en egen subvolym per snapshot), skall det kunna raderas och ändringsskyddas eller skall man bara kunna backa till en restore-punkt/rollback - skall det som är yngre än restorepunkten/rollback förloras när det sker eller skall man fortfarande kunna backa igen till den nyare versionen om den gamle inte dög eller kunna välja annan rollback/återställningspunkt när som helst. Skall man kunna jämföra versioner och kunna se diffar (det vill man förr eller senare och det är inte så smidigt att göra i rollback-system (som ZFS) eller med åteställningspunkter då man bara ser och kan testa en version i taget.)


och versionshantering kostade förr och kostar fortfarande utrymme, särskilt om inget slängs...

De äldre (och fortfarande dagens) versionssystem gör vad de kan för att spara på utrymme med tex diffar för koden mellan versionerna och man sedan kunde bygga tillbaka till aktuell önskade version - men det bygger på att koden är inspekteringsbar (som tex källkoder i textform) och man kan klippa och klistra mellan versionerna - problemet är binärblobbar och tillverkar-egen format som inte baseras på text utan kan vara entropikodat (komprimerat) och/eller krypterat... kör man samma lib som rsync använder sig av (rdiff-lib) så kan man förvisso plocka ut skillnadsbitar även ur binärblobbar, men gör inte innehållet sökbart eller analyserbart på annat sätt.

Det finns också en sak med metoder som bygger på diffar och man bygger baklänges till den versionen man vill visa - vad händer vid fel eller det fattas en textbit - hur knäcks kedjan, hur städar man efteråt och rädda det som går att rädda - också återställningstiden om man måste tugga igenom en otal versioner innan man får fram den önskade versionen. Den resan har många backupprogram/filosofier smakat på när man upptäcker att man måste köra in 30 olika diffar applicerat i serie efter varandra innan man får önskad version...

Det finns anledning till varför backupsystem numera är chunk/bucket-baserade och baserat på snapshot, somliga använder sig av COW-principer för all modifiering, att man kan komma åt alla versioner 'parallellt' - även 'git' mer eller mindre byggt på samma sätt med ett antal frysta 'stillbilder' på flödet och man kan alltid välja version i efterhand och grena vidare till nya parallella spår och har också verktyg för att slå ihop parallella spår till färre spår igen och tex bara behålla det som är bäst kvalitets/funktionsmässigt.

större lagringssystem som S3 och B2 har man också möjlighet att sätta en 'livstid' på datat och kan styras av många parametrar som om kontot fortfarande existerar, betalningarna görs, inte används på fel sätt - ändras det inte och uppdateras hela tiden så försvinner datat och utrymmet återskapas för annan lagring - stora lagringssystem måste ha sådant då det blir alltid mängder med data som ingen vill kännas vid förr eller senare - lagring kostar, även datalagring...

[guckrum]

Versionshantering, logfiler och snapshots är för mig olika saker. Ungefär såhär ser det ut från där jag står:

- loggfiler är något man "appendar", dvs adderar rader till. Man brukar inte skriva över loggfiler, man skapar nya och adderar rader till dem efter hand. En bra logg har också en tidsstämpel för varje rad. Således föreligger inget behov för versionshantering (se nedan), eftersom informationen i en loggfil inte kan ändras, bara växa.

- versionshantering innebär en mera aktiv handling där man förknippar en viss version av ingående filer med ett meddelande som beskriver vad versionens syfte är. Meddelandet är avsett för människor att tyda, och därför är det sällan effektivt att skapa regelbundna eller automatiska versioner. (Hur skall det navigeras?) Avvikelser förekommer. Vid versionshantering kan man typiskt skapa parallella grenar av sitt projekt som kan utvecklas oberoende av varandra.

- snapshots är något man gör på filsystem och databaser (ett filsystem är en sorts databas). ALLA ingående element i databasen snapshotas exakt samtidigt, och snapshotet kan associeras med om inte ett längre meddelande så åtminstonde en kortare etikett. Detta är typiskt en automatiserad operation, man tar snapshots på sitt filsystem varje halvtimme, dag, vecka eller liknande för att kunna backa om man ställer till det för sig. Syftet kan alltså vara att möjliggöra "rollbacks", dvs återställa till ett tidigare (otrasigt) tillstånd, eller ett sätt att säkerställa att en backup eller kopia fångar hela filsystemets egenskaper vid en viss tidpunkt. (Man backupar alltså snapshotet och inte det "levande" filsystemet som potentiellt ändras medan backupen rullar.) Syftet är då alltså inte versionshantering, och typiskt kan man inte skapa parallella grenar av sin databas. Eller det är i alla fall inte meningen.

[xxargs]

Är medveten att jag klumpade ihop det lite mycket.

Men fortfarande - skall man kunna få fram en äldre version av en fil i ett OS så har man automatiskt också problemet hur det hela skall hanteras, hur mycket skall sparas, var sätter man linjen när det inte längre skall sparas (eller en ransomware mycket noga tar bort alla shadowcopys innan den skrider till verket). och det kan skilja en hel del mellan vad användaren tycker är bra och vad förvaltaren/admininstratörern tycker är lämpligt och det är alltid i företagssammanhang med många användare samtidigt som skalningsproblemen börja visa sig och datoradministratören kan inte ägna lika mycket tid per dator som hemanvändaren kan ägna med sin egen tid på sin burk samt att komplexiteten ökar i kvadrat med antalet användare typ.

En OS-tillverkare (som MS med sin shadow copy) kan sätta upp en regelmatris som kanske passar de flesta (eller inte ens vet om att de finns) - men det är påhäng en bit ovanför själva filsystemet - i skalet, inte _i_ själva filsystemet, det är skalet (exploren mfl. med underhjälpprogrammet) som döljer de äldre kopiorna (tex. en lösning som en förfinad version av papperskorgen i osynlig form stort sett, med typ hashade filnamn för att det inte skall få samma namn som en tidigare version som heter likadant etc. och en liten databas som håller reda på det) - men användaren kanske inte upplever det så och tror att det är en del av filsystemet eller OS:t.

Sådana trolla med knäna kan man göra i alla OS - om man vill, men jag tror knappt någon skulle se vitsen med det om det implementerades i bash i en linuxhink, hade det varit vits med det så hade det skrivits för länge sedan och GIT kanske aldrig har skrivits...