New Year's Bug



  • [img]http://i17.tinypic.com/7x8opzd.jpg[/img]

     

    I'm guessing most of you can figure out what happened here ;)

    (Not mine, taken from a bug report on Doom9)
     



  • Running on a veeeeery slow PC, I guess.



  • @tray said:

    Running on a veeeeery slow PC, I guess.
    With random graphic glitches obscuring the footage's total running time.



  • @Lingerance said:

    @tray said:
    Running on a veeeeery slow PC, I guess.
    With random graphic glitches obscuring the footage's total running time.

    Which is approximately 2:47:55, in case you were wondering.



  • @tray said:

    Running on a veeeeery slow PC, I guess.

    Nope.  The system time rolled over to the new year while it was running.  Since the program (MeGUI) ignores the year when calculating the time, it shows an atrociously wrong runtime.



  • @Dark Shikari said:

    I'm guessing most of you can figure out what happened here ;)

    I didn't guess, although the bug reminds me of a similar flaw in Fetch 3 on the Macintosh. It fails to correctly interpret implicit dates on files on an FTP server if you're connected over a year change. Files whose listing entry has a time instead of a year (a UNIX lunacy that FTP gladly took on board) get last year's year inserted instead of the current year. That confused me for a while until I realised what was going on. No idea if modern Fetch versions still do this.



  • @Daniel Beardsmore said:

    @Dark Shikari said:

    I'm guessing most of you can figure out what happened here ;)

    I didn't guess, although the bug reminds me of a similar flaw in Fetch 3 on the Macintosh. It fails to correctly interpret implicit dates on files on an FTP server if you're connected over a year change. Files whose listing entry has a time instead of a year (a UNIX lunacy that FTP gladly took on board) get last year's year inserted instead of the current year. That confused me for a while until I realized what was going on. No idea if modern Fetch versions still do this.

    Filezilla has a similar bug when going to windows -> nix ftp server (only case I have tested) when set to over-ride if newer it will not transfer as the nix system reports files 7 hours in the future (I'm -7 GMT). Fun debugging why the updates didn't work, even more fun disabling said feature if I checked the "always do this" box.


  • @Dark Shikari said:

    @tray said:
    Running on a veeeeery slow PC, I guess.

    Nope.  The system time rolled over to the new year while it was running.  Since the program (MeGUI) ignores the year when calculating the time, it shows an atrociously wrong runtime.


    Wrong number? No. It just shows additional information.
    Maybe it's a ways the app says happy new year.



  • @Lingerance said:

    @Daniel Beardsmore said:
    @Dark Shikari said:

    I'm guessing most of you can figure out what happened here ;)

    I didn't guess, although the bug reminds me of a similar flaw in Fetch 3 on the Macintosh. It fails to correctly interpret implicit dates on files on an FTP server if you're connected over a year change. Files whose listing entry has a time instead of a year (a UNIX lunacy that FTP gladly took on board) get last year's year inserted instead of the current year. That confused me for a while until I realized what was going on. No idea if modern Fetch versions still do this.

    Filezilla has a similar bug when going to windows -> nix ftp server (only case I have tested) when set to over-ride if newer it will not transfer as the nix system reports files 7 hours in the future (I'm -7 GMT). Fun debugging why the updates didn't work, even more fun disabling said feature if I checked the "always do this" box.

    That's because Windows was conceived as a stand-alone OS, so the simplest thing to do was to set the computer clock to local time. Unix was long used in networking, where the right thing to do was to set the computer clock to UTC and let applications know the timezone. That Windows uses local time and Unix uses UTC causes no end of trouble.



  • @m0ffx said:

    @Lingerance said:
    @Daniel Beardsmore said:
    @Dark Shikari said:

    I'm guessing most of you can figure out what happened here ;)

    I didn't guess, although the bug reminds me of a similar flaw in Fetch 3 on the Macintosh. It fails to correctly interpret implicit dates on files on an FTP server if you're connected over a year change. Files whose listing entry has a time instead of a year (a UNIX lunacy that FTP gladly took on board) get last year's year inserted instead of the current year. That confused me for a while until I realized what was going on. No idea if modern Fetch versions still do this.

    Filezilla has a similar bug when going to windows -> nix ftp server (only case I have tested) when set to over-ride if newer it will not transfer as the nix system reports files 7 hours in the future (I'm -7 GMT). Fun debugging why the updates didn't work, even more fun disabling said feature if I checked the "always do this" box.
    That's because Windows was conceived as a stand-alone OS, so the simplest thing to do was to set the computer clock to local time. Unix was long used in networking, where the right thing to do was to set the computer clock to UTC and let applications know the timezone. That Windows uses local time and Unix uses UTC causes no end of trouble.

    How does the offset of the return value of an api put bugs in another program? Why can't the developers of filezilla deal with the timezone manually if they know both the client OS and the local timezone?



  • @shawnz said:

    @m0ffx said:

    @Lingerance said:
    @Daniel Beardsmore said:
    @Dark Shikari said:

    I'm guessing most of you can figure out what happened here ;)

    I didn't guess, although the bug reminds me of a similar flaw in Fetch 3 on the Macintosh. It fails to correctly interpret implicit dates on files on an FTP server if you're connected over a year change. Files whose listing entry has a time instead of a year (a UNIX lunacy that FTP gladly took on board) get last year's year inserted instead of the current year. That confused me for a while until I realized what was going on. No idea if modern Fetch versions still do this.

    Filezilla has a similar bug when going to windows -> nix ftp server (only case I have tested) when set to over-ride if newer it will not transfer as the nix system reports files 7 hours in the future (I'm -7 GMT). Fun debugging why the updates didn't work, even more fun disabling said feature if I checked the "always do this" box.
    That's because Windows was conceived as a stand-alone OS, so the simplest thing to do was to set the computer clock to local time. Unix was long used in networking, where the right thing to do was to set the computer clock to UTC and let applications know the timezone. That Windows uses local time and Unix uses UTC causes no end of trouble.

    How does the offset of the return value of an api put bugs in another program? Why can't the developers of filezilla deal with the timezone manually if they know both the client OS and the local timezone?

    FTP servers running on Windows tend to return timestamps in the local timezone, and the client can't tell the difference. Yes, this is completely broken.



  • On the topic of "Wrong number? No. It just shows additional information.":

    I used to drive around a 1970 Chevy Beauville van (kind of like this http://images.safeform.com/reviews/images/sporcar.gif but a lot worse).  The radio/clock decided at some point that it would drain the battery overnight every night, so we rigged it to only be powered on when the van was turned on.  This turned out to be a splendid feature: now we always new exactly how much time it took to get anywhere as the clock would be reset to 12:00:00 when turned on. hehe



  • @asuffield said:

    @Lingerance said:

    With random graphic glitches obscuring the footage's total running time.

    Which is approximately 2:47:55, in case you were wondering.

    Good! I can now blackmail the OP with this sensitive information!

     

    Wait. 



  • @m0ffx said:

    That's because Windows was conceived as a stand-alone OS, so the simplest thing to do was to set the computer clock to local time. Unix was long used in networking, where the right thing to do was to set the computer clock to UTC and let applications know the timezone. That Windows uses local time and Unix uses UTC causes no end of trouble.


    Eh? When you're programming an application to get the time from Windows, you either use 'GetSystemTime' or 'GetLocalTime' depending on whether you want UTC or local time. You never get the time from the hardware clock unless you are really disturbed, so what that is set to is irrelevant.

    An FTP client/server would just use the appropriate GetSystemTime/GetLocalTime call depending on what it wanted it for. File timestamps are all returned in UTC with a 'FileTimeToLocalFileTime' API call to convert them to local time if you need that.

    Now, if an application uses the wrong API call, that's not Windows' fault is it, or if the user sets the wrong timezone in Windows (which often happens IME) that's not Windows' fault either. Sounds like you're blaming Windows for something that's a 3rd party developer's (or user's) fault...




  • @dhromed said:

    Wait. 

    My thoughts exactly.

    Total frames divided by current frames multiplied by current time, in case anybody was too stupid to notice that.



  • Interesting that the final glyph in the scratched time is a 6.



  • @dhromed said:

    Interesting that the final glyph in the scratched time is a 6.

    Rounding error. I did say "approximately". 



  • @pscs said:

    @m0ffx said:
    That's because Windows was conceived as a stand-alone OS, so the simplest thing to do was to set the computer clock to local time. [...]


    Now, if an application uses the wrong API call, that's not Windows' fault is it, or if the user sets the wrong timezone in Windows (which often happens IME) that's not Windows' fault either. Sounds like you're blaming Windows for something that's a 3rd party developer's (or user's) fault...

    Not blaming - explaining why. If using UTC format times had been widespread practice in the Windows world, then no doubt Windows clents and servers would have used UTC, and everything would have been fine.

    I'm sort of reading between the lines here, but I believe m0ffx is saying that it's common practice to use local time, and that's why FTP clients and servers standardized on it too. I have little experience with Windows servers, so I'll take his word for it.

    It's interesting to note that the RFCs for FTP didn't (*) specify what timezone is to be used, and that is the real WTF here.

    (*) Yes, [url=http://tools.ietf.org/html/rfc3659]RFC 3659[/url] does specify that UTC should be used. RFC 3659 is from March 2007, it would have had zero impact on anything written before that date.



  • @magetoo said:

    I'm sort of reading between the lines here, but I believe m0ffx is saying that it's common practice to use local time, and that's why FTP clients and servers standardized on it too.

    I wouldn't call it "standardized" so much as "blindly broken due to being pieces of junk written by morons".

     

    It's interesting to note that the RFCs for FTP didn't (*) specify what timezone is to be used, and that is the real WTF here.

    Hardly the biggest thing that's wrong with FTP as a protocol. Please stop using it. HTTP is just better in every respect, as is SFTP. I half suspect that the only reason people keep using FTP is because it has "file transfer" in the name and they are idiots.


  • @asuffield said:

    @dhromed said:

    Interesting that the final glyph in the scratched time is a 6.

    Rounding error. I did say "approximately". 

    I know, but it takes pretty serious rounding to get from 54.8+ to 56.



  • @asuffield said:

    Hardly the biggest thing that's wrong with FTP as a protocol. Please stop using it. HTTP is just better in every respect, as is SFTP. I half suspect that the only reason people keep using FTP is because it has "file transfer" in the name and they are idiots.

    Echoed.  If you're using ftp, there's really no reason you shouldn't upgrade to sftp.

    However, I've noticed FTP to be considerably faster than sftp (but not than http) in some situations.  Like with the intranet in my house, going from my desktop (in the house) to a server (in the house).



  • @dhromed said:

    @asuffield said:

    @dhromed said:

    Interesting that the final glyph in the scratched time is a 6.

    Rounding error. I did say "approximately". 

    I know, but it takes pretty serious rounding to get from 54.8+ to 56.

    You have to realise that the times in the dialog have already been rounded once, to the nearest second (since they'll be computed by dividing the frame count by the frame rate). I haven't worked it out exactly, but stacking rounding this way should give an error of about +/-3. 



  • @belgariontheking said:

    However, I've noticed FTP to be considerably faster than sftp (but not than http) in some situations.

    Check for CPU load, and try switching the encryption algorithm to blowfish rather than RSA. That's the usual cause. 


Log in to reply