'Microsoft Exchange-servers houden mailverkeer tegen door mogelijke datumfout'

Verschillende systeembeheerders op Twitter, Reddit en het forum van Microsoft melden problemen met e-mailverkeer in Exchange 2016 en 2019. Zij krijgen een foutmelding en e-mailverkeer wordt geparkeerd. Het probleem lijkt een datumfout in een recente update.

Verschillende admins, onder meer op de subreddit r/sysadmin, zeggen dat hun nieuwjaarsviering onderbroken is door een probleem met Microsoft Exchange 2019 en 2016 na een recente update. Zij melden een probleem met de 'Microsoft Filtering Management Service', de anti-malwaredienst van Microsoft voor Exchange. Het mailverkeer lijkt te worden tegengehouden en geparkeerd, en beheerders krijgen de melding 'The FIP-FS Scan Engine failed to load. Can't convert "2201010002" to long.'

Verschillende beheerders, onder meer op het forum van Microsoft, suggereren dat een recente update een bug heeft. Zij stellen dat er een probleem is met hoe Exchange de datum verwerkt, waardoor er een foutmelding ontstaat en het anti-malwarefilter alle e-mailverkeer tegenhoudt. Microsoft heeft een uitleg online gezet hoe de bug te fixen is.

Redditgebruiker FST-LANE was de eerste die het probleem meldde op Reddit. Volgens deze gebruiker zijn de problemen volgens de logs ontstaan nadat de MS Filtering Engine Update updateversie 2201010001 kreeg, rond 2.00 uur 's nachts Nederlandse tijd. Voormalig systeembeheerder Joseph Roosen zegt op Twitter dat het probleem ontstaan is vanaf middernacht UTC.

Op het forum van Microsoft voorspelde gebruiker JulianSiebert op 31 december al dat er een probleem zou ontstaan. Het nummer dat Microsoft aan een update geeft, wordt omgezet in een 32-bit long of integer data-type. Dat staat een positieve integerwaarde toe tot 2147483647. Het lijkt erop dat Microsoft de eerste twee getallen van de updateversie gebruikt om het jaar van de update aan te geven. In 2021 leidde dit niet tot problemen, maar nu het 2022 is, wordt de waarde van de updateversie omgezet in een long-type groter dan de maximumwaarde, namelijk 2201010001.

FST-LANE stelt dat de oplossing is dat Microsoft de waarde omzet in 'unsigned long', waardoor de maximumwaarde 4294967295 is, en er geen problemen zullen zijn tot 2043. Microsoft heeft nog niet gereageerd op de problemen. Tot die tijd is de beste oplossing voor systeembeheerders om de anti-malwaredienst uit te zetten via 'Disable-Antimalwarescanning.ps1'.

Update 2 januari - Microsoft heeft een fix voor het probleem online gezet.

Reacties (156)

[MZONDERL]

Microsoft : https://techcommunity.mic...sport-queues/ba-p/3049447

[wildhagen]

Dank je, daar staat inmiddels ook een oplossing, zowel met een automatisch powershell script, als met een handmatige methode.

Ik heb deze net toegepast bij onze enige klant met on-premise Exchange, en de Malware-scanning weer enabled via het "Enable-Antimalwarescanning.ps1"-script (deze kan je vinden in C:\Program Files\Microsoft\Exchange Server\V15\Scripts).

Daarna de MS Exchange Transport-service herstart, en de mailflow getest. Dit werkt inderdaad naar behoren. Ook in de eventlogs zijn EventID's 5300 en 1106 niet meer terug te vinden. Probleem dus opgelost

[daa]

Microsoft heeft een oplossing beschikbaar in de vorm van een engine update: https://techcommunity.mic...sport-queues/ba-p/3049447

[paulhekje]

ik kan bevestigen dat de oplossing werkt.

script ResetScanEngineVersion uitvoeren, download duurde wel vrij lang.

[Reactie gewijzigd door paulhekje op 23 juli 2024 09:25]

[Blokker_1999]

Het resultaat van dat men BITS gebruikt voor de download. Die is standaard beperkt tot 2Mb/s of zelfs maar de helft tijdens kantooruren.

[Rainbow]

Er is ergens iets lost in translation. Een 64 bits getal kan tot 9,223,372,036,854,775,807 als je plus en minus toestaat. De genoemde is 2,147,4833,547 is van een 32 bits getal. Zie ook: https://en.wikipedia.org/...ommon_integral_data_types

Het woord "long" is sowieso nogal ambigu. Tegenwoordig komt dat in moderne talen (zoals Java) inderdaad overeen met 64 bits, maar dat is lang niet altijd geweest. In C geloof ik was een "integer" zo groot als de bitgrootte van je systeem (bijv. 16 bits) en een "long" tweemaal zo groot (op een 16 bits systeem dus 32 bits). Zie ook: https://en.wikipedia.org/...ter_science)#Long_integer

[GertMenkel]

Een long is meer dan een integer lang (integer is minstens 16 bits) en een short is korter dan een integer en wat dat exact inhoudt mag de compiler kiezen. Bij Microsoft's compiler is een long 32 bits lang, en een long long is 64 bits lang, ongeacht of je x64 compilet of niet.

De lont is ooit toegevoegd omdat op de PDP11 men naar 64-bit schakelde en daar een hack voor gebruikte (namelijk int[2] met allerlei handmatige berekeningen voor getallen). De specificaties zijn expliciet vaag om de compiler meer macht te geven, wat heel handig kan zijn als je programmeert voor microcontrollers. Je hebt zo nog steeds compilers waar de keuzes anders zijn, bijvoorbeeld C-compilers naar AVR (Arduino) waar ints 16-bit zijn en longs 32-bit, ook al zit je op de nieuwste versie. Dit natuurlijk omdat de hardware veel sneller 16-bitberekeningen kan doen en 32-bit-operaties een reeks aan vermenigvuldigingen in de machinecode moeten stoppen.

Ik zie bij moderne systeentalen als Rust en Zig ook steeds vaker de neiging om in plaats van int en long een grootte in het type aan te geven, zoals i32 of u64. Het lost in elk geval de ambiguiteit flink op. Talen als C# en Java die van C afgeleid zijn, hebben in hun primitives vaak helaas nog wel de oude namen en zullen die ook een lange tijd behouden.

[gimbal]

Ja maar het voordeel is dat de definitie nooit zal veranderen. In Java is een int 32 bits signed, een long is 64 bit signed. Dat zal over 20 jaar nog steeds zo zijn. Je hoeft je er nooit over te verwonderen.

[citegrene]

c++ blijft altijd weer verbazen:
https://www.geeksforgeeks...-competitive-programming/

[MSalters]

Prutsers prutsen in alle talen. Dat gezegd hebbende, die "competetive programming" scene heeft wel de neiging om in C++ te prutsen. Als je naar die post van jou kijkt, dan zie je bijvoorbeeld dat de auteur niet beseft dat "1e10" een floating-point getal is in C++.

[Dykam]

In het geval van C# is `int` iig. alleen een alias voor het .NET type Int32, maar idd. wel degene die aangeraden wordt om te gebruiken. Maar het achterliggende type heeft het dus wel duidelijk, gelukkig.

[.oisyn]

Een long is meer dan een integer lang (integer is minstens 16 bits) en een short is korter dan een integer en wat dat exact inhoudt mag de compiler kiezen.

Natuurlijk niet per se "meer dan" en "korter dan", want gelijke grootte mag ook.

De regel is idd sizeof(short) <= sizeof(int) <= sizeof(long), waarbij short minstens 16 bits is, en long minstens 32.

[tisvonkje]

Op een PDP11 naar 64 bit schakelde? Dat lijkt me onwaarschijnlijk. Een pdp11 heeft 16 bit registers dus alle snelle bewerkingen zijn 16 bits, Ben je niet in de war met een VAX?
Verder het gebruiken van een rij van twee integers levert compiler technisch een hoop problemen op wat betreft geheugenbeheer.
Ik zou graag wat bronnen zien die je argumenten onderbouwen.

[GertMenkel]

Je hebt gelijk, het was 32-bits (2*16), niet 64-bits voor de PDP-11. Ik kan helaas mijn comment niet meer aanpassen omdat het te oud is.

[jeroen3]

Als embedded ontwikkelaars gebruiken we altijd de int32_t/uint32_t types die C toevoegt. Om precies dit soort onzin te voorkomen.

Compileert altijd naar 32 bit, ongeacht 8/16/32/64 bit platform.

[Reactie gewijzigd door jeroen3 op 23 juli 2024 09:25]

[SirRosencrantz]

Thanks, ging inderdaad iets fout.

[linuxontherocks]

Set-MalwareFilteringServer -Identity <ServerIdentity> -BypassFiltering $true

Werkt sneller dan het Powershell script wat ook een restart verwacht en met deze commando bypass je de filter. Zorg er ook voor dat je goede mallware scanner er voor zet. Even zomaar uitzetten is te simpel gedacht, hou aub de servers extra in de gaten en je gebruikers!

[Reactie gewijzigd door linuxontherocks op 23 juli 2024 09:25]

[themadone]

Ik mag toch hopen dat er geen mensen zijn die alleen op exchange leunen als spam/mallware filter.

Ik heb er ook een paar onder beheer die er last van hadden, maar gelukkig staan daar allemaal externe spamfilters (zijn de enige die mogen afleveren direct op exchange) voor dus het uitzetten zou geen ramp mogen zijn.

Lekker begin van het jaar weer zo.....

[wildhagen]

Als je het goed is heb je inderdaad minimaal 3 layers of defence, en vertrouw je niet alleen op de filter van Exchange zelf. Zoals in de IT geld: 'één is geen', en dus onvoldoende beveiliging/redundancy.

Vóór de mail bij Exchange komt moet hij al door een scanner gehaald zijn, pas al die een pass geeft moet hij naar Exchange worden doorgezet. Dan heb je dus de scanner in Exchange zelf, die nu tijdelijk als workaround uitgezet wordt. En als laatste heb je nog een virusscanner op de client.

In het meest ideale geval zijn de 3 scanners ook nog eens allemaal van verschillende fabrikanten, om de kans op een false negative zo klein mogelijk te maken.

[themadone]

Mijn setup:

1. mx gaat naar symantec/broadcom cloud spamfilter
2. on prem Barracuda spam firewall
3. exchange filter
4. client anti mallware

En zoals gezegd, symantec is de enige die direct poort 25 mag benaderen van buitenaf. De workarround werkt gelukkig, stonden maar 1400 mails in de queues

[linuxontherocks]

Helemaal eens maar er zijn nog genoeg systeembeheerders die alleen hier op leunen! Helaas!

[Blokker_1999]

Nee hoor, die gaat falen . Het moet $true zijn op het einde, niet true

[linuxontherocks]

Thanks, iets te veel weg gehaald bij de example !

[DDX]

Lijkt erop dat mail alleen 'geparkeerd' stond, als je de Antimalwarescanning disabled komt daarna de mail van afgelopen nacht netjes binnen.

[Blokker_1999]

Maar dus zonder dat er malwarescanning heeft plaatsgevonden. Ook niet acceptabel voor vele systeembeheerders lijkt mij.

[wildhagen]

Niet ideaal nee, maar nog altijd beter dan helemaal géén mail ontvangen. Dan ligt het hele bedrijf meteen stil.

Daarom is dit ook geen fix, maar een workaround. Hopelijk komt er snel een echte fix.

En wat @DDX zegt lijkt te kloppen, de mail ging niet verloren, maar bleef in de queue staan. Na toepassen van de workaround begint Exchange met het alsnog wegwerken van deze queue.

[downtime]

Niet ideaal nee, maar nog altijd beter dan helemaal géén mail ontvangen. Dan ligt het hele bedrijf meteen stil.

Dan ligt de boel morgen weer plat maar nu door een cryptolocker of andere meuk. Ik zou degene niet willen zijn die management adviseert om tijdelijk maar even alle malware door te sturen.

[wildhagen]

[...]

Dan ligt de boel morgen weer plat maar nu door een cryptolocker of andere meuk. Ik zou degene niet willen zijn die management adviseert om tijdelijk maar even alle malware door te sturen.

Je moet er sowieso natuurlijk ook al een scanner vóór Exchange hebben zitten, je moet nóóit alleen op de filtering in Exchange zelf vertrouwen. En als laatste heb je nog een virusscanner op de client.

Je hebt dus (minimaal) 3 layers of defence, om er dan één tijdelijk tussenuit te halen is niet ideaal, maar ook niet meteen alsof je de hele omgeving openzet voor allerlei malware oid.

[Platpoot]

Yes exact dit. Bij ons haalt de malwarescanner van exchange er meestal alleen false positives uit en extreem weinig andere rotzooi (~2 per week). En dan heb ik het over een stuk of 70000 mailboxen met de daarbij behorende mailflow.

[Mangu429]

Als dat zo is heb je ook geen drie lagen nodig. Toch zijn die er om bepaalde redenen wel. En om exact die redenen zet je niet even een laag uit.

[anboni]

Als het goed is, zit er altijd nog een andere vorm van spam/virus/malware scanning voor (zoniet, dan mag die systeembeheerder zich gaan schamen) dus het risico van deze workaround is dan niet zo heel groot.

[CM0S]

Weet iemand of een third party AV oplossing zoals Trend Scanmail for Exchange op de server zelf onafhankelijk is van deze filter engine of dat deze dan ook bypassed is? Uiteraard moet je mail altijd daarvoor ook scannen, maar ik vroeg mij dit even af?

[DDX]

Op de mails die vastgehouden werden is de malwarescanning wel gedaan.
Ik had een paar testmailtjes vanaf extern gestuurd en 1 mail kwam retour met ;
'<<< 550 5.7.1 Message rejected as spam by Content Filtering.'

Andere mails kwam niet retour en kwamen netjes in de mailbox toen ik de service disabled had.
Uiteraard worden er nu geen malwarescanning meer gedaan, nu wachten tot een update van Microsoft.

[adam76]

Als je je exchange ontvangst connector direct aan het internet heb hangen dan vraag je er ook om. Juiste procedure.. Spam / virus / malware filter er voor. Firewall alleen dat ip of ips doorlaten naar je exchange server ... en het is al een heel stuk veiliger ....

[buzzerd]

Ik vind het eigenlijk schandalig dat dit Microsoft overkomt. Microsoft loopt al zo'n 55 jaar mee in de IT, heeft de 2K problematiek meegemaakt en toch nog steeds problemen met tijd-coderingen. Als je na 2K nog steeds codeert met de eerste 2 cijfers het jaartal moet je heel goed weten waar je mee bezig bent. Dit had niet zo de kwaliteitsafdeling mogen passeren.
Overigens is het Unix-probleem van de overflow van een unsigned integer van een andere orde, wat zeker opgelost moet worden maar niet het gevolg van een "slimme" programmeur die de eerste 2 cijfers voor een jaartal codering gebruikt.

Ik hoop dat Microsoft snel met een patch komt om dit op te lossen.

[edwinjm]

Exchange bestaat als sinds 1996, hé? 😉

Maar ben het zeker met je eens dat een groot IT-bedrijf dit gewoon goed op orde moet hebben.

Waarom heeft Microsoft eigenlijk niet een server in een geëmuleerde omgeving die een jaar vooruit loopt?

Ik denk wel dat ze voor maandag een patch hebben.

[m_snel]

Kan me nog herinneren dat we Ms mail en wp mail hadden in die tijd. Was wel grappig binnen het ministerie kon je allen mensen benaderen die hetzelfde systeem gebruikte.
Toen gingen we over op Exchange op Windows 3.11 en moest ieder systeem worden uitgebreid met 8 mb extra geheugen. De cliënt was iets van 20mb een veel fout van Windows.

[Chris_147]

Helemaal gelijk, maar Microsoft is eigenlijk helemaal niet zo goed met dates, vooral schrikkeljaren:
2012: Azure down door schrikkeljaar: https://www.wired.com/2012/03/azure-leap-year-bug/
2009: Zune player werkt niet door schrikkeljaar: https://techcrunch.com/20...d-in-detail/?guccounter=1
2008: schrikkeljaar probleem in Exchange: https://www.theregister.c...o_exchange_leap_year_bug/
Alle excel versies denken foutief dat 1900 een schrikkeljaar was.

Er zijn nog voorbeelden te vinden.

[Reactie gewijzigd door Chris_147 op 23 juli 2024 09:25]

[Blokker_1999]

Dat alle excel versies dat denken komt natuurlijk omdat MS zo graag vast houdt aan legacy. Om compatibiliteit te blijven garanderen is dat een bug die op de won't fix stapel is beland spijtig genoeg.

[SuperDre]

Nouja, het probleem ansich komt niet zozeer door jaartal in 2 cijfers hier. Maar doordat het niet in een signed 32-bit integer past.

[Verwijderd]

Het bedrijf is over de loop der jaren gewoon lui geworden, en tegenwoordig stem je ook in met hun service agreement in waarin ze niet aansprakelijk zijn of gesteld kunnen worden uit eventueel verlies van data omwille updates.

Bedoel vroeger werd een OS kant en klaar en werkend geleverd. Hoe is dat nu gesteld? Je moet gelijk je troep updaten.

[tweaker2010]

Zolang je die recente update niet hebt gedraaid, is er dus niets aan de hand..
Heb je wel de update gedraaid, even het script draaien en de transport service herstarten.

[justme256]

Yup, zojuist maar even gedaan, want ook bij ons prijs. Gelukkig stonden de reeds ontvangen mails in de queue, dus niks kwijt.

[Blokker_1999]

Je malwarescanner werkt zichzelf continue bij. Die gaat standaard elk half uur controleren of er nieuwe definities zijn. Het is dus niet zo dat vanacht duizenden systeembeheerders handmatig hun Exchange hebben zitten bijwerken om daarna te zien dat het niet meer werkte. Het is vandaag dat vele beheerders melding krijgen dat mail niet meer werkt.

[Crazy-]

Ha! 22 jaar later maar daar is de millennium bug!

[RobertMe]

Er zijn nog wel meer van dit soort bugs. Zo heb je ook de Y2K38 bug, die er in 2038 aan komt. Unix timestamps, in de vorm van aantal seconden sinds 1-1-1970 00:00:00, overflowen dan op signed 32 bit. Waarbij omzetten naar unsigned natuurlijk niet kan omdat ook regelmatig tijden van voor 1970 verwerkt moeten kunnen worden (denk bv aan een geboortedatum).
Op in ieder geval 64 bit Linux speelt dat probleem niet, omdat timestamps dan 64 bit zijn. Maar op 32 bit Linux schijnt het by default wel nog steeds problemen te geven met glibc (de defacto standaard C library).

[The Zep Man]

Op in ieder geval 64 bit Linux speelt dat probleem niet,

Tenzij je systeemklok (die de tijd bijhoudt wanneer het systeem uit staat) 32 bit is. Daar zal men alsnog omheen moeten werken.

[GertMenkel]

Helaas speelt dat op 64-bit Linux wel, tenzij je musl gebruikt in plaats van glibc zoals Alpine. Je moet voor glibc namelijk een flag aanzetten om 64-bit-tijd in te schakelen, en als je die aanzet moeten ook alle libraries die time_t uitwisselen die flag aan hebben staan tijdens hun compilatie. Heel veel belangrijke Linuxapplicaties draaien daarom nog op 32-bit tijd.

Bepaalde BSD's hadden dit probleem ook en hebben dat meer dan een decennium geleden opgelost door gewoon direct naar 64-bit te gaan. Helaas zullen de meeste LTS-systemen niet zomaar omschakelen uit angst voor het breken van applicaties buiten de officiële repos.

[sympa]

Ja maar dit is echt de klassieke milennium-bug, met een 2-cijferig jaartal, die 22 aan het begin.
Plus dat de string gecast wordt naar een getal. Dat verzin je toch niet. Wat wordt de volgende stap/bug"fix"? Omzetten naar een float, en dan verbaasd worden dat het detecteren van de laatste versie niet meet betrouwbaar is door afrondingsfouten?

[Blokker_1999]

string gecast naar een getal? Neen, het gaat hier om een versienummer, wat gewoon een getal is. Waarom een getal? Omdat je getallen zeer eenvoudig kunt vergelijken. Voor getallen heb je in zowat alle programeer- en scriptingtalen gewoon functies als groter dan zitten zodat je snel kunt nagaan of het bijvoorbeeld nieuwer is dan de vorige versie.

En nee, de milleniumbug was dat we een 4-cijferig getal afbeelden door slechts de twee laatste cijfers omdat men er als mens van uit ging dat de 2 eerste cijfers duidelijk waren voor iedereen die die laatste 2 zag staan. Maar dan komen computers en ga je berekeningen dien met die cijfers of andere bewerkingen. Ineens blijkt het een slechte beslissing te zijn geweest om ook intern het jaar voor te stellen als slechts 2 cijfers. Iets wat in de jaren 60 nog goed was door beperkte opslagcapaciteit, maar in de jaren 90 eigenijk al had uitgefaseerd moeten zijn.

[downtime]

Maar een versienummer is geen getal. Het is een reeks getallen. De bug is juist ontstaan doordat de ontwikkelaar iets wat geen getal is behandelt alsof het wel een getal is. Hij had gewoon iets minder lui moeten zijn.

[jerrycan92]

Hoe weet je of een update voor je van toepassing is als je het versienummer niet mag interpreteren?
Nu past 1 van de reeks getallen niet in gebruikte datatype. De fout is dan dat je het verkeerde datatype gebruikt wordt, niet dat je een getal als getal interpreteert.

[Reactie gewijzigd door jerrycan92 op 23 juli 2024 09:25]

[downtime]

Een versienummer is geen getal. Het is een opsomming: Major version, minor version, etc. En elk onderdeel zou een aparte integer moeten zijn. Als het een getal was dan zou een simpele integer immers volstaan.
Als je het wil interpreteren moet je gewoon wat meer werk doen: Is major version groter, kleiner, of gelijk? Als major version gelijk is, is minor version dan groter, kleiner of gelijk? etc.

[Jaco69]

Het is een getallenreeks net als een telefoonnummer. Die moet naar mijn mening nooit naar een integer worden veranderd maar string blijven.

[downtime]

Met strings kun je zo moeilijk checken of string1 hoger of lager dan string2 is. Versie 4.2 is later in het alfabet dan 4.10 maar toch is 4.10 een latere versie. En die check wil je met versienummers soms wel doen.

[Zer0]

Uh, als je numeriek werkt is 4.10 gelijk aan 4.1 en dus lager dan 4.2.....

[Veneus]

Ja en bij versienummers is v4.10 dus de 4de major, 10de minor release. Je moet dus juist niet als decimalen beschouwen. En dus ook niet afronden of afkappen.

[Jaco69]

Je kan de strings "2147483647" en "2201010001" anders eenvoudig vergelijken en je loopt niet tegen onverwachte grenzen aan.

[jerrycan92]

Mijn punt was dat 1 van de getallen binnen het versienummer niet paste in datatype integer. Juist met de aanname dat een simpele integer zou moeten volstaan krijg je problemen zoals deze.

[downtime]

Je bedoelt de datum? Dan maak je daar een datumtype van. Daar kun je ook prima mee rekenen. En als de datum gelijk is dan kijk je alsnog even naar de volgende waarde die waarschijnlijk wel een integer is.

[jerrycan92]

Ik bedoel het deel van het versienummer dat soort van datum is en ook nog steeds een nummertje is. Had je gekozen om dat nummertje numeriek te verwerken zonder logica die stuk gaat bij getallen groter dan 32-bit was er niets aan de hand.

Toch wordt de aanname gedaan dat de nummertjes binnen een versienummer altijd in een integer passen. Dat hoeft niet zo te zijn en voor de verwerking hoef je alleen een compare van rechts naar links te doen.

Het interpreteren van 1 zo'n nummer als datum maakt het nodeloos ingewikkelder. Het is niet nodig en wanneer een keer een versienummer gebruikt wordt dat daarvan afwijkt moet je ook nog iets van foutafhandeling verzonnen hebben.

[k995]

Nee hoor men gebruite altijd 4 cijfers echter met de opkomst van computers met beperkt geheugen hebben ze dan verminderd naar 2 met de wetenschap dat tegen 2000 toch wel alles opnieuw geschreven zou worden.

[arianvp]

Het is meer code om een string om te zetten naar een getal (loopje met exponenten en modulo) en dan te vergelijken dan een loopje over de characters en pairwise lexograpisch te vergelijken.

[GTACrime]

Bron?

[sympa]

Alleen het versie"nummer" is geconcateneerd als een string. En die "Can't convert" lijkt toch op een string die omgezet gaat worden.

[likewise]

Dus als jij een woord niet kent, moet je daar een reactie over plaatsen? Wordt een drukke bende hier dan, als je een woord als concateneren niet kent, gaan we zo het hele woordenboek langs?

[Speedster]

Ik denk zomaar dat menigeen het woord concateneren niet kent...
Vandaar de reactie.

Daarnaast het kan zo makkelijk veel eenvoudiger, achter elkaar plaatsen, dat begrijpt iedereen.

[jmvdkolk]

Een software ontwikkelaar snapt zeer waarschijnlijk niet wat jij bedoelt met "achter elkaar plaatsen" terwijl concateneren voor een software ontwikkelaar heel duidelijk is.

[downtime]

Concat is een functie die in veel programmeertalen voorkomt en voor een developer is het daarom ook niet raar om af en toe het werkwoord concateneren, of in het kort concatten, te gebruiken. Voor een mede-IT’er is dat klare taal.

[OxWax]

IT is meer dan developers alleen

[GertMenkel]

Ik vind het een lelijk woord, maar de Engelse tegenhanger is een veelgebruikt woord omdat het samenvoegen van tekenreeksen vaak met een "concat"-functie wordt gedaan daar waar de +-operator niet gebruikt kan worden.

[Clubbtraxx]

Maar... Hottentottententententoonstellingterrein is langer

[TheVivaldi]

Maar niet langer dan hottentottententententoonstellingsterreinen.

[Drumar]

onderschat de hottentottententententoostellingsterreinknecht niet.

[aikebah]

Onderstaande doet het ook goed in scrabble:
Hottentottententententoonstellingtent

In mijn spellingregels hoort daar nog een tussen-s bij, maar wellicht dat de pannekoeken van de spellingshervorming die wel geschrapt hebben toen ze die nutteloze tussen-n toegevoegd hebben en tot pannenkoeken van de spellingshervorming gepromoveerd werden.

[aadje93]

excel =concat functie die veel gebruikt word.

[SirRosencrantz]

Ho verkeerde draadje. Excuses.

[Boogie]

Grappig, de Y28K38 bug waarvan ik wist dat die bestond, kwam ik gisteren tegen bij converteren vage datumnotatie progress in php date() iemand had een registratiefout gemaakt en 2171 ingevoerd en die timestamp kon ik niet omzetten.

[scsirob]

Klopt! Dit is ook in MS-DOS het geval. Ergens in mijn oude source code had ik altijd een check daarvoor:

if(byBadDate)
{
vWriteStat("*** WARNING - The date on your system appears to be out of range");
vWriteStat("*** This program stops functioning correctly if the date is set");
vWriteStat("*** earlier than Jan. 1, 1970 or later than Jan. 18, 2038");
vWriteStat(" ");
}

Dit is dan in software die ik in 1994 geschreven heb.

[MSalters]

Er moesten destijds ook regelmatig tijden van voor 1902 verwerkt worden, en dat underflowt ook signed int. Nee, geboortedata zijn een slecht argument. De simpele reden dat tijden signed zijn, is dat in C de default signed is. 0 is een signed int, 1 is een signed.int, etcetera.

De meest simpele fix voor Y2K38 is dan ook om dat te veranderen naar unsigned. Er zijn weinig embedded systemen in 2022 die om gaan vallen omdat ze 1903 en 2039 verwarren.

[vliegendekat]

Dit is een klassieker...

[Hee_Martijn]

Precies wat ik dacht!

[dasiro]

Y2K was in weze veroorzaakt door programmeurs die ervan uit gingen dat enkel de laatste 2 karakters van het jaar belangrijk waren, net zoals je toen op veel papieren de 2 eerste karakters (19) voorgedrukt zag staan. Het was dus geen memory overflow, maar een ongewilde reset

[aikebah]

Wel een memory-overflow, maar een decimale ipv een binaire overflow

[dasiro]

een overflow gebeurt wanneer er data naar andere adressen wordt weggeschreven. Decimale waarden worden altijd geconverteerd naar binaire waarden en de decimale 00 was nooit een decimale 100 waarvan de 1 in een ander register terecht kwam.

[Hoopje]

Als je in een register of geheugenadres een waarde probeert te schrijven die er niet in past, wordt dat ook een overflow genoemd (een integer overflow). Bij een integer overflow worden er weliswaar geen andere geheugenadressen beschreven, maar er wordt wel een foute waarde in het geheugen gezet (een negatieve, bijvoorbeeld) en dat is ook een bron van bugs. In dit geval is er overigens geen sprake van een integer overflow: de functie die een string (die waarschijnlijk uit een JSON- of XML-bestand stamde, of een ander tekstgebaseerd bestand) naar een integer moest converteren heeft gemerkt dat de waarde te groot was, en heeft, in plaats van een foute of onverwachte waarde terug te geven, een foutmelding (exception) gegenereerd. Precies zoals dat hoort.

En trouwens, in de jaren 60 waren computers zo langzaam dat zelfs het converteren tussen decimaal en binair te veel tijd kostte. Daarom werden waardes juist wel decimaal in het geheugen geschreven. Intel-processoren hebben zelfs nog instructies die daarmee kunnen omgaan (BCD). Kortom: Y2K werd veroorzaakt door een soort decimale integer overflow (maar een memory overflow was dat inderdaad niet).

[Alex3]

BCD wordt ook gebruikt om afrondingsfouten te voorkomen. Zo kan b.v. 0,1 in BCD exact worden gerepresenteerd, maar binair niet.

[Hoopje]

[OT]
Het kan zijn dat BCD soms voor dat doel gebruikt wordt, maar nodig is dat in ieder geval niet. Java's BigDecimal gebruikt bijvoorbeeld een binaire BigInteger als mantisse en een binaire 32-bit integer als exponent, maar neemt wel 10 als grondtal. Ook IEEE-gestandaardiseerde decimale floating point formaten gebruiken geen BCD, maar ofwel binair ofwel 'densely packed decimals'.

[m_snel]

Ik was net van hardware naar software over gestapt, maar het was goud geld verdienen in die twee tijd, zelf met de overgang naar de euro viel er veel te verdienen.
Je snapt niet dat men nu nog niet wakker is, svb had problemen dat mensen opeens waren overleden of opnieuw geboren.
Raketten die na 24 uur niet meer functioneren omdat er probleem met afronding tussen decimale en binaire code was.

[MazDaMan1970]

Ik mag hopen dat dit probleem niet speelt bij Exchange Online? Ik heb iig afscheid genomen van on premise Exchange servers, aangezien ik mijn tijd wel beter kan besteden! De laatste jaren is het beheer van mailservers niet leuk meer, gezien de tijd die je eraan verspilt.

[_Dune_]

Exchange Online kent het issue inderdaad niet, vanochtend in de eigen omgeving getest. Heb je echter een Hybrid omgeving waar on-prem nog mailboxen staan, dan zullen de on-prem mailboxen hier wel hinder van ondervinden, zoals FreeDoM-CGV hier ookal aangeeft FreedoM-CGV in 'nieuws: 'Microsoft Exchange-servers houden mailverkeer tegen ...

[justme256]

Niet alleen de on-prem mailboxen. Ook je mailboxen in Exchange Online krijgen niks als je MX naar je on-prem wijst, aangezien de transport service niet werkt door de bug. Je on-prem transport regelt de routing naar Exchange Online bij een hybride omgeving. Hadden wij last van totdat ik het script gedraaid had.

[jeffrey-nl]

Ik vind dit een prachtig programmeer voorbeeld van de juiste data types gebruiken en hoe goed je tests zijn. Het is lastig om te ontdekken als de code er eenmaal in staat en ik durf te zeggen dat mij dit ook wel zou kunnen overkomen.

Tuurlijk, achteraf kun je zeggen. Gebruik voor dit soort zaken een ander data type (string) of split het jaartal van het andere versie nummer in een int en long. Of maak je unit test data altijd X jaar vooruit.

[GertMenkel]

Ik denk een beetje dat de programmeur hier verwachtte dat de long langer was dan de 32 bits van een int (maar dat is hij niet bij de MS compiler). Met 64 bits kun je meer dan genoeg jaartallen uitdrukken om hier mee om te gaan.

Hier hadden inderdaad wel meer tests voor mogen komen, maar ik zie ook wel hoe "testen of het versienummer niet overflowt" kan worden vergeten.