Det er et forholdsvist kompliceret spørgsmål. Lige præcis med png, afhænger hver pixel af de foregående, så hvis man opdaterer en af de første pixels, vil man blive nødt til at genskrive alt. Læs mere her: https://medium.com[...] I praksis ville jeg antage, at hele filen bliver skrevet igen i alle tilfælde. Men det er op til hvert enkelt program at beslutte.
--
ASUS Z270 TUF Mk1 | 7700K | GTX 1080TI | 32GB 3000MHz | Fractal Define R5 | Samsung 960 EVO 1TB | PG279Q | 2xU2715H

Jeg forestiller mig det er sådan her... Når man åbner en fil for at redigere i den, bliver der lavet en midlertidig fil. Når man er færdig med at redigere, bliver den originale fil erstattet med den midlertidige fil såfremt der er ændringer i filen. Jeg tror det vil sløve systemet ned, hvis systemet skal fjerne et 1 her og tilføje et 0 der i en lang række af 0'er og 1'ere. Så er det hurtigere bare at erstatte hele lortet.
--
- Indsæt signatur -

#2: Der er flere ting i den. Hvis vi skal helt ned og snakke 0 og 1, så ved harddisken intet om filer. Det er filsystemet - harddisken opererer i sectors og blocks. Uden at være hardware mand, vil jeg gætte på at disken ikke læser om det er nødvendigt at opdatere, da det kun ville sløve skrivningen. Det, der tager tiden ved en skrivning er søgetid og rotation. Hvis vi ser bort fra søgetiden, vil en læsning blot gøre, at disken skal bruge længere tid samme sted. Hvor imod en overskrivning med samme værdi ikke har nævneværdige ulemper.
--
ASUS Z270 TUF Mk1 | 7700K | GTX 1080TI | 32GB 3000MHz | Fractal Define R5 | Samsung 960 EVO 1TB | PG279Q | 2xU2715H

Mange tak for de svar der er kommet indtil videre I kan derfor begge med stor sikkerhed sige, at hele filen bliver erstattet når man gemmer sine ændringer? Jeg læste artikelen fra linket, men synes ikke jeg kom frem til en nærmere afklaring - dog meget interessant læsning!
--

Sidst redigeret 07-07-2018 12:57

En disk er inddelt i sektorer, og disse er normalt 512 bytes, hvilket dermed er det absolutte minimum, der kan overføres til/fra platters. De fleste nyere filsystemer inddeler endvidere sektorer i blokke på hver 4KiB, og dette er så det absolutte minimum, der kan overføres. Mange programmer benytter (via filsystemet) særlige midlertidige filer, hvor der ved hjælp af en journal holdes styr på hvilke sektorer, der rent faktisk ændres, og dette gør det så muligt, kun at skrive sektorer, der rent faktisk skal skrives. SSD'er fungerer væsentligt anderledes end HDD'er, og derfor gælder ovenstående ikke for SSD'er.
--
http://xlinx.dk[...] i7 2600K, 16GB PC3-12800, GA-X68XP-UD4 R1, GTX 560Ti HAWK, 250GB 840 EVO

Endvidere, når man åbner en fil, den buffer der bliver lavet som man ser på, hvis man trykker "gem", UDEN at ændre noget, bliver den originale fil så overskrevet og erstattet? Eller sker det kun, hvis man faktisk ændrer noget? Mange tak på forhånd
--

Sidst redigeret 07-07-2018 13:33

#5 Hej Nitroblast Vil du venligst uddybe, således jeg forstår hvad det har af relation til mine stilede spørgsmål? mange tak
--

#7 En HDD er fysisk ude af stand til at skrive enheder mindre end sektorstørrelsen. Derfor er det ikke muligt at skrive 1 byte, springe to andre bytes over, for så at skrive en byte igen. Derfor vil alle bytes i dit eksempel skulle genskrives. Ved små filer genskrives normalt hele indholdet, ved store filer (eks. databaser) genskriver man normalt kun blokke, der er ændrede, og man holder styr på ændringer ved hjælp af en journal. Prøv at søge lidt på "journaling file system", eller kig her: https://en.wikipedia.org[...]
--
http://xlinx.dk[...] i7 2600K, 16GB PC3-12800, GA-X68XP-UD4 R1, GTX 560Ti HAWK, 250GB 840 EVO
--

Sidst redigeret 07-07-2018 13:44

Moderne filsystemer er COW ... Kort fortalt skriver den en helt ny fil og retter i MFT til sidst. Aka: hele filen skrives påny.
--
Indholdet af dette indlæg er blevet redigeret af NSA.

Endnu en stor tak til alle besvarelser Er der nogen med en afklaring til #6 ? Bliver filen skrevet eller overskrevet igen, hver gang man trykker gem, uanset om der faktisk er lavet ændringer?
--

#10: Det er er ingen, der kan svare på, da hvert program kan gøre det på hvor sin måde. Jeg ved ikke hvilken buffer, du taler om. Et program kan læse fra en fil og behandle den præcis som det vil. Det kan læse dele af filen eller det hele. På samme måde kan det skrive som det vil. Typisk vil programmet læse hele filen ind i RAM, medmindre det er en meget stor fil. I dette tilfælde læses den i klumper og bearbejdes. Hvis det er en .png fil, vil man nok typisk gemme pixels som bitmap - dvs. uden den komprimering som .png tilbyder. Det letteste er at trunkere og overskrive, da det kræver mindst kodning. Det er dog ret enkelt at checke om noget er ændret. Men TL;DR er: Det er helt op til programmet at bestemme hvad 'Gem' knappen gør.
--
ASUS Z270 TUF Mk1 | 7700K | GTX 1080TI | 32GB 3000MHz | Fractal Define R5 | Samsung 960 EVO 1TB | PG279Q | 2xU2715H

Jeg havde altid troet, at filens "ændret" dato, kun blev opdateret hvis man åbnede filen, lavede en ændring og gemte Jeg prøvede lige, åbnede filen, lavede IKKE nogen ændring, men trykkede kun "gem" Filens "ændret" blev opdateret 1. Har det altid været sådan? 2. Vil I sige filen bliver overskrevet eller skrevet igen? Igen, stor tak til alle jeres besvarelser!
--

#8 Hvilken størrelse filer skal man op i, før der ikke længere er tale om en overskrivning af filen?
--

#8 117539756 bytes. Ej, jeg har ingen anelse - det afhænger af det program, der håndterer filerne. En tekstfil på 16KiB kan genskrives helt hver gang, uden at det går ud over performance. Skulle man genskrive en hel database på 16GiB hver gang den skal gemmes, så bliver systemet sløvet betydeligt, og så giver det mening kun at genskrive ændrede blokke.
--
http://xlinx.dk[...] i7 2600K, 16GB PC3-12800, GA-X68XP-UD4 R1, GTX 560Ti HAWK, 250GB 840 EVO

Der findes programmer, som kan fortælle dig det, f.eks. WinHex. Du får en liste af clustere, som du kan sammenligne før og efter. En cluster (består af x antal sektorer) er den mindst adresserbare enhed i NTFS.
--
Gæstebruger, opret dit eget login og få din egen signatur.

Det var nemlig i den størrelsesorden jeg tænkte på, om der er tale 10 KiB, 50 KiB, 1 MB, osv. Jeg forventede ikke et helt præcist tal :) Men jeg kan på ovenstående besvarelser konkludere, at png. filer på ca. 50 KiB bliver overskrevet, når trykker gem Ret mig endelig, hvis jeg tager fejl Mange tak
--

#0 Det kommer an paa dit software. men regn med at hele filen overskrivers igen. #1 En png fil er ikke noedvendigvis afhaange af tidliger pixels du behoever ikke delta endkodning eller deflate komperinig i en png file anyway er dette ogsaa irrelevant da selv en .BMP fil bliver skrevet alt efter hvordan software handtere det og ikke filen format #2 Der er ingen grund til at lave en midliertidgt fil paa hdd'en medm dinre du loebe tor for ram. processen ville vaer en unodevndig sloevnings af arbejdet. GRoft set: Data bliver hente fra diske til ram. arbejdes med i ram Skriver tilbage til disken alt med undertagelser naturligvis #3 +1 #4 Du skal regne med det som udgangs punkt ja Det er ogsaa "sundt" for diskens data #5 filsystemmer arbejder ikke med sectore Filsystemmer arbejder med cluster som typisk adresse til en eller flere sectore filsystemr har brugt 4kbyts mht til NTFS i langt og selv helt btiblage til FAT tiden. En cluster kaa vaere i forskellige laenger og afgoeres ved formatering. Feks kan du formater og valge mellme 4kb elelr endog op til 64kbytees cluster i et ntfs filsystem Sectore storrelse er rimelig fast og afgoeres ved lowlever formatering hvilket vi ikke kan laver paa en hdd siden 80'erne/ start 90'erne #6 ja du har bedt om at skrive data til disken. Saa data til disken bliver skrevet. Det er endog ikke sikker at din nye fil ligger fysisk det samme sted. Saa du kan fysisk set have 2 kopier er filen hvor den ene blot er maerkeret som slettet/fri. #8 Helt enig #9 Enig som udgangs punkt #12 Harddisken ved ikke at din fil ikker er aendret det er ikke saadden den lige laver en sammenligning hver gang du gemmer en fil Du har: a: bedt om at laese en fil B: bed om at skrive en file. ergo ny data for hvornar der er skrevet til filen Derudover har du udover en skrive data og ogsaa en access dato i NTFS systemmer #13 Kommer an paa dit software #16 taenk gigabyte vis
--
Sven Bent - Dr. Diagnostic www.TechCenter.[...] - Home of Project Mercury
--

Sidst redigeret 11-07-2018 05:26

#17 Hej Sven Bent Mange tak for dine mange besvarelser #0 - MS Paint #2 - Jeg troede altid at det var en buffer-fil man arbejdede i, når man både arbejdede i MS Paint og Microsoft Word? #5 - Synes det lyder avanceret. Men der er stadig tale om en overskrivning/genskrivning i mit tilfælde? Når vi snakker en PNG fil på 10-100 KiB #6 - Er der ikke kun tale om en ny fil, hvis man trykker gem som? Hvis der bare er tale om en overskrivning af tidligere fil, så er placering den samme? Hvis der er tale om genskrivning af filen, er placering så den samme eller ny? #13 - Hvis der er tale om MS Paint?
--

#18: Jeg vil æde min gamle hat på at Paint altid overskriver. Det er ikke beregnet til at arbejde med store filer. Mht. om det altid er samme sted den vil skrive, så er det filsystemet, der afgør det. De fleste Windows brugere kører NTFS i dag. Men nok FAT32 på flash drev. Forestil dig at en fil er en lille smule større når du gemmer end da du loadede. Hvis der er data både før og efter, vil det slet ikke være muligt at skrive denne på præcist samme sted.
--
ASUS Z270 TUF Mk1 | 7700K | GTX 1080TI | 32GB 3000MHz | Fractal Define R5 | Samsung 960 EVO 1TB | PG279Q | 2xU2715H