lørdag, januar 23, 2021

Hashcode til downloadede filer ændre sig

Daily Rush Debat Programmering Hashcode til downloadede filer ændre sig

  • Forfatter
    Emne
  • #0

    Festival_H
    Bruger
    4.630 indlæg
    Offline

    Møjn.

    Jeg har et GIGA problem.

    Jeg har lavet noget custom install software som downloader de seneste versioner af nogle andre filer og for at være sikker på at overførslen ikke er gået galt har jeg implementeret et hashcode check.

    Det vil sige at jeg, når jeg ligger nye filer på til download, regner de nye filers checksum ud og ligger disse i en fil som install softwaren kan aflæse og derved tjekke at den har downloadet filerne 100% uden fejl.

    Koden blev skrevet for vel 3-4 år siden og har virket upåklageligt indtil for ~4 uger siden.

    Af en eller anden ukendt årsag får mine downloadede filer for det meste en anden hashcode end den jeg aflæser når jeg ligger filerne op.

    Hvis jeg retryer downloaden er det kun en sjælen gang at hashcode ‘rammer’ rigtig, men for det meste er det den forkerte hash.

    Hvis jeg prøver at bruge filen virker der som om den er rigtig downloadet. Hvis jeg tester hashcode fra et andet program så stemmer hashcode overens med den forkerte hashcode.

    Dette bevirker at mit install program looper og looper indtil det lykkedes den at ramme den rigtige hashcode!

    FUCKED UP.

    Nogle der har oplevet lignende?

    Og husk nu: densutterjoikksigselv.dk

Viser 8 kommentarer - 16 til 23 (af 23 i alt)
  • Forfatter
    Kommentarer
  • #16

    Festival_H
    Bruger
    4.630 indlæg
    Offline

    Bruger et SHAManaged object, som ligger i System.Security.Cryptography, til at udregne hash. Den har en ComputeHash funktion der tager en FileStream som argument.

    Det er forresten ikke helt rigtig at Chrome kan downloade min fil. Dog er det knap så tit det fejler i chrome. Derfor må jeg slutte at koden bør virke. Jeg var af den opfattelse at kunne jeg åbne en zip med winrar at så var det ensbetydende med at filen ikke var korrupt. Det vil jeg hermed godt dementere. Det er ikke korrekt.

    Jeg forsøgte gentagne gange at downloade filen med Chrome og selv om Chrome ikke meldte fejl viste det sig at der var fejl på nogle af filerne i zip filen hvis jeg prøvede at extracte dem.

    Vi har prøvet at skifte mellem IIS og Apache som gav nogle andre problemer med Casing som vi løste dog uden at løse det egentlige problem.

    Der har naturligvis været lavet ændringer i setup koden, men ikke selve den del som downloader filerne fra http. Den har stået urørt i et par år nu, hvilket også er med til min beslutning om at det ikke kan være koden den er gal med.

    Og husk nu: densutterjoikksigselv.dk

    #17

    Kolben
    Bruger
    18.939 indlæg
    Offline

    #16
    Bruger du samme version af cryptography modulet i server og klient? (Især interessant hvis du anvender et fortolket sprog, eller hvis det trækker på nogle eksterne dependencies, der ikke er opdateret. Men også selv om det er kompileret, og du bare “har glemt det”).

    P=NP?

    #18

    Burberry
    Bruger
    491 indlæg
    Offline

    lol *hash*code you guys..

    #19

    JakobL
    Bruger
    851 indlæg
    Offline

    #16 Det her er nok lidt out-of-my-league, men nu nævner du at nogle zip filer du henter i Chrome indeholder fejl.

    Er det på den samme maskine som laver hash-fejlene?

    Jeg har nemlig engang for mange år siden haft en stang ram i en maskine som pludselig var defekt. Den var årsag til at data spontant blev korrupte, og data jeg hentede ned på nettet slet ikke virkede.

    #20

    kreal
    Bruger
    249 indlæg
    Offline

    jeg tænker din Ram er gået i stykker. Hvis det er mulig så brug ECC.

    Men igen bare et gæt.

    #21

    Festival_H
    Bruger
    4.630 indlæg
    Offline

    Nope. Det er flere maskiner det sker på.

    Hashen blir beregnet på samme måde og det lykkedes som sagt også en gang imellem at få filen rigtig ned så hashen passer og filen kan bruges uden fejl.

    Det er sgu mystisk. Hælder lidt til at det er vores net. Der er nogle der snakker om a MS lavede nogle performance optimeringer af tcp stacken i forbindelse med vista og at det i nogle tilfælde kan give rod i et af osi modellens lag og af en eller anden årsag kan den ikke selv finde ud af at rette det og derfor når fejlen op i applications laget hvor filen så er ubrugelig.

    Jeg har ikke ingen kilder. Det er hvad min sysadmin fortæller. Jeg spørger ham om hvorfor vi først ser det nu hvis det blev lavet i vista og vi idag kører win7 hvortil han svare at det måske først er nu at vi opnår hastigheder der gør stacken ustabil nok!

    Vi kører gigabit netværk på kontoret. Jeg prøvede så efterfølgende at force mit netkort til at køre 100mb full duplex og så var det som om problemet forsvandt. Det havde så et andet problem der gjorde at min download kørte som på et 56k modem: virkelig langsom, men det gav da lidt stof til eftertanke.

    Imorgen skal jeg så prøve at sætte en 100mb switch mellem min pc og det øvrige netværk og se om det har nogen effekt.

    Prøvede i et vmware miljø at sætte netværket til at køre 100mb men det havde ingen effekt. Der fejlede det stadig.

    Og husk nu: densutterjoikksigselv.dk

    #22

    Fisker
    Bruger
    12.648 indlæg
    Offline

    #21 De lyder altså som lidt af en “Jeg har ingen idé om hvad der foregår”-forklaring

    Men som jeg skrev ville det være en god idé at forsøge at teste det på en anden server, det kan jo være serveren det er galt med.

    #23

    ahymdahl5
    Tilskuer
    9.421 indlæg
    Offline

    #21 Fuck, hvor det giftigt! Hvad sagde jeg i #4? Sådan noget giver altså selvtillid når man studerer.:D

    1)Download hjemmefra for at teste.
    2)Prøv en test server fra den samme lokation, hvor din nuværende server er.
    3)Punkt 1. og 2. kombineret.

    Der skulle gerne være en sandsynlighed for at se, om det er jeres eget firma net der fejler, eller netværket til serveren. Så kan du passende kaste bolden til jeres netværksmand, hvis du finder frem til noget.

    Un dos tres Maria!

Viser 8 kommentarer - 16 til 23 (af 23 i alt)
  • Du skal være logget ind for at kommentere på dette indlæg.