• drrk (unregistered) in reply to Zylon
    Zylon:
    A real geek would have typed, "corruption never^H^H^H^H^H rarely happens".

    no, a real geek woudl have typed "corruption never^W rarely happens." no point in all those wasted keystrokes with backspace now!

  • dkf (unregistered) in reply to James Schend
    James Schend:
    FTP is, indeed, a terrible protocol. But suns can flare to life, form planets, evolve life, and die during the length of time it takes WebDAV to upload a 10,000 file website. Or at least Apple's implementation of it, which appears to reconnect for every single file...
    It can't be the reconnecting that's killing it, or at least not by comparison with FTP which also has exactly that feature (FTP data channels are just standard sockets) which is one of the many reasons why FTP sucks. Other reasons relate to how to how it does port management and how it interacts with firewalls. The ASCII/BINARY thing is just icing on the cake, and is a workaround for a catastrophic practical problem back when FTP was developed.

    In any case, I suspect (from what you say, not experience, so don't trust what I say) that the Apple WebDAV must be transferring the data in encoded (base64 or worse) form. That's got to be a form of lunacy; I'm pretty sure that HTTP upload doesn't require that the data be encoded that way so long as the (upload) content type is right...

  • doom (unregistered) in reply to DigitalXeron
    DigitalXeron:
    What about the event that you die? Do you continue the loop? shouldn't there be a break in there in the event you die? =p

    Death gives you Ctrl-C so you get a SIGINT and disappear from the processor.

  • Cheong (unregistered)

    Why don't they simply set the FTP server to ignore ASCII request? (So transfer is always done in binary whatever the client says)

    I thought many FTP servers nowadays has this feature.

  • J Random Hacker (unregistered) in reply to Cheong
    Cheong:
    Why don't they simply set the FTP server to ignore ASCII request? (So transfer is always done in binary whatever the client says)

    I thought many FTP servers nowadays has this feature.

    A lot do. I love it when you need a file to be transferred in ASCII mode, and your file is corrupted by having it transferred it in binary instead.

  • (cs) in reply to James Schend
    James Schend:
    dkf:
    Confused:
    I hate, loathe and despise ASCII mode. The concept is flawed to begin with.
    Maybe you've never been "fortunate" enough to use FTP with systems that used the EBCDIC charsets? In those cases, you really really REALLY want to have ASCII mode set by default so that your directory listings work, and back when FTP as a protocol came into service such machines were still fairly common. (They were still hanging on in the '90s, for goodness sake!)

    If this was a WTF from any time recently, the Real WTF! is that they're using FTP at all. It's a horrible protocol in rather many ways, and WebDAV (or even just plain HTTP) is much better in a number of important technical ways.

    FTP is, indeed, a terrible protocol. But suns can flare to life, form planets, evolve life, and die during the length of time it takes WebDAV to upload a 10,000 file website. Or at least Apple's implementation of it, which appears to reconnect for every single file...

    FTP isn't as bad as is being suggested. However, if I had, say, a delivery service and I asked the intern to do the delivery with my old model 1 Ford....

    FTP is old, and the design choices made were good enough for the time. Character sets differed...enormously. Also, since you were alot more likely to send a character file than a binary file it made sense to default to Ascii(text) mode. Security was less important because way back everyone on the internet liked eachother and were friends. All this means is that you shouldn't be using FTP because the sell by date has expired, not because it wasn't any good to begin with.

    Bet you ftp users also use VI instead of a modern editor like Emacs. (ducks and runs for cover)

  • (cs) in reply to brian
    brian:
    uh, yeah.

    Random file corruption DOES happen.

    That was my first thought. Ironically enough, just a few minutes ago a machine I'm using warned me that a delayed write to one of the disks failed, and that the data was lost and the file likely corrupt. There's an incompatibility between the drive and the motherboard; at random intervals the drive essentially drops off the system, requiring a power cycle.

    As the failures are random, the file corruption is random...

    (So why haven't I replaced the hardware? It's my machine and I can't afford to at the moment, and it's rare enough that it isn't a real problem)

  • PC Paul (unregistered) in reply to drrk
    drrk:
    Zylon:
    A real geek would have typed, "corruption never^H^H^H^H^H rarely happens".

    no, a real geek woudl have typed "corruption never^W rarely happens." no point in all those wasted keystrokes with backspace now!

    I think Alex did type ^H^H^H^H or ^W.. but the forum software cleverly recognised it and transformed it into a neat typographical overstrike to enhance the reading experience.

    Oh, wait....

  • (cs)

    Guess that happens when you try to do something without a pilot test. The ftp backup person should have verified that the data could be restored correctly from the backup long before all of it went in place. Blame management for not putting the proper controls in place and trusting it to just work without some kind of proof. They just brought the tapes later to cover their own butts.

  • SQB (unregistered)

    Wow, FTP! The way we do backups, well, first we print out each and every record in all of our tables. Then we have a rather large wooden table...

  • micromoog (unregistered) in reply to Darth Vader

    That wouldn't work. It would convert the erroneous CRLFs back to LFs, but it would also convert those CRLFs that were actually correct to LFs, creating new corruption.

  • Rich (unregistered) in reply to seaturnip
    seaturnip:
    (assuming that no character set is stupid enough to use 0 as the encoding of a character...)

    Why, exactly, would that be stupid? And yes, I do know of at least one that does (though it's not in common use).

  • Rich (unregistered) in reply to Watson
    Watson:

    ASCII/BIN ... CRLF/LF/CR ... defaulting to ASCII .... No doubt there were very good reasons for all of these at one time or another. Remember people: your quick hack may one day end up becoming an ineradicable standard protocol.

    There are never good reasons for munging unknown data without the explicit request of the user. Defaulting to ASCII for data files in FTP was quite simply a mistake. A naive mistake perhaps. If the program was called TEXTTP or something, maybe.

    Rich

  • Rich (unregistered) in reply to *
    *:
    Which may only appear to be random because of the tiny tots of energy needed to influence quantum particles.

    So you've heard of it but have no understanding.

    Rich

  • Rich (unregistered) in reply to VeXocide
    VeXocide:
    Why ? Why does it always have to go wrong before management decides to buy tapes..

    Not always. Sometimes it's enough for a $400/hr consultant to come in and repeat what everyone in the IT department has been saying for the past several years.

    The added mention of jail time also helps seal the deal. (SOX does have its uses)

    Rich

  • Andrew (unregistered)

    Actually a lot of the time you can fix CR/LF problems by intentionally getting it "wrong". That is, if you get a file that was sent ASCII when it should have been sent BIN, send it back in ASCII then get it in BIN. This shouldn't always work, but its a real good "poor man's" of correcting the problem. I've used is a good bit in the past. (Now I just use SCP and worry about converting CR/LFs myself.)

  • Andrew (unregistered) in reply to wtfwtf
    wtfwtf:
    The new WTF is the crazy opinions in the articles. Files don't get corrupted? On what planet, in what alternate reality, are bits always stored perfectly, never get flipped, and a program never does anything wrong?? I want to live there. Maybe they even name their wtf sites properly.

    I'd have to agree. I guess all of that ECC code that exist is for the people who think gullible is not in the dictionary.

  • Andrew (unregistered) in reply to Andrew
    Andrew:
    wtfwtf:
    The new WTF is the crazy opinions in the articles. Files don't get corrupted? On what planet, in what alternate reality, are bits always stored perfectly, never get flipped, and a program never does anything wrong?? I want to live there. Maybe they even name their wtf sites properly.

    I'd have to agree. I guess all of that ECC code that exist is for the people who think gullible is not in the dictionary.

    Err, that EEC code. (Danged flipping keyboard keys.)

  • ewww (unregistered) in reply to Andrew
    Andrew:
    wtfwtf:
    The new WTF is the crazy opinions in the articles. Files don't get corrupted? On what planet, in what alternate reality, are bits always stored perfectly, never get flipped, and a program never does anything wrong?? I want to live there. Maybe they even name their wtf sites properly.

    I'd have to agree. I guess all of that ECC code that exist is for the people who think gullible is not in the dictionary.

    I for one had to check to see if it really was in the dictionary.

  • AdT (unregistered) in reply to doom
    doom:
    Death gives you Ctrl-C so you get a SIGINT and disappear from the processor.

    What if I trap SIGINT? Eternal life...

    Oh no, Death just sends SIGKILL.

  • (cs) in reply to Bobbo
    Bobbo:
    seejay:
    I'll try to remember that when my 2GB thumb drive wouldn't allow me access to a directory last week

    That's some high quality tense-mixing. Can I borrow your time machine please?

    I had a long day and my brain farted while trying to put together a coherent thought. Shush you. :P

  • Worf (unregistered) in reply to Anodyne
    Anodyne:
    The translation is reversible if the ASCII-mode transfer was from a UN*X machine to a Windows machine - the single byte LF (line feed) becomes CRLF (carriage return followed by line feed), and this is fairly straightforward to fix - just replace all occurrences of CRLF with LF. Even if there was a CRLF pair in the original file, this will have become CRCRLF so no problem.

    Actually, a naive ASCII transfer will turn all LF->CR/LF. A smarter ASCII transfer will actually check to make sure that if an LF was encountered, a CR didn't precede it. So while the naive implementation will turn CR/LF to CR/CR/LF, a smarter implementation will turn <anything-but-CR>/LF to CR/LF, and leave CR/LF alone as is. So even that's not reversible.

    And also, Macs (pre-OS X) used CR as the line ending. So LFs turn to CR's, and CR/LF were transformed to just CR.

    OS X Macs, because of their Unix-ish heritage, started inheriting the LF lineending as well.

    (And Word has been known to corrupt files once the filesize starts getting up there - the liklihood of Word corrupting a file increases with filesize - after around 60MB or so, you'd want to break it into a new file if nothing else than to prevent possible file corruption.

  • Anonymous (unregistered) in reply to TheJasper
    TheJasper:
    Bet you ftp users also use VI instead of a modern editor like Emacs. (*ducks and runs for cover*)

    Nope. Real Emacs users use FTP transparently via the ange-ftp package. Browsing/editing remote directories/files in Emacs is as easily as browsing/editing local directories/files, thanks to ange-ftp. The FTP operations are transparent and automagic. I have to laugh at vi users who need to manually do "ftp get", "vi", "ftp put" repetitively. (In the same way I laugh at vi users who need to manually do "co", "vi", "ci" (when using RCS). Emacs do those for me automagically.)

    Update: The TRAMP package, a successor to the decades old ange-ftp package, can handle not only FTP, but also sftp, scp, rcp, etc.

  • Watson (unregistered) in reply to drrk
    drrk:
    Zylon:
    A real geek would have typed, "corruption never^H^H^H^H^H rarely happens".

    no, a real geek woudl have typed "corruption never^W rarely happens." no point in all those wasted keystrokes with backspace now!

    Though I like the way that in the abstract displayed before the comments the overstriking doesn't appear - the sentence makes much more sense that way.

  • Old_Unix_Geezer_Mac_Noobie (unregistered) in reply to Anonymous
    Anonymous:
    ...(In the same way I laugh at vi users who need to manually do "co", "vi", "ci" (when using RCS). Emacs do those for me automagically.)

    Update: The TRAMP package, a successor to the decades old ange-ftp package, can handle not only FTP, but also sftp, scp, rcp, etc.

    I learn something useful everytime I read this site...

  • Watson (unregistered) in reply to Rich
    Rich:
    Watson:

    ASCII/BIN ... CRLF/LF/CR ... defaulting to ASCII .... No doubt there were very good reasons for all of these at one time or another. Remember people: your quick hack may one day end up becoming an ineradicable standard protocol.

    There are never good reasons for munging unknown data without the explicit request of the user. Defaulting to ASCII for data files in FTP was quite simply a mistake. A naive mistake perhaps. If the program was called TEXTTP or something, maybe.

    Rich

    "Never"? Not even in 1971?

    When ftp was developed architectures and software varied so wildly that the only data format they had in common was plain text (usually fixed-width fields) - and even then they varied in character encoding. It made sense for text to be the default because that's how data was exchanged, and it made sense for a common transfer encoding to be specified - telnet-style ASCII, in this case. Providing mechanisms to describe data file structure (field widths) would be a bonus.

  • Anonymous (unregistered) in reply to Dark Shikari

    The Microsoft FTP that comes with Windows.

    Or at least with Windows 2000 it still defaulted to ASCII. Haven't had misfortune of using it since.

  • Christian Smith (unregistered) in reply to Darth Vader
    Darth Vader:
    No, the real WTF is that he used a month old backup instead of running sed -e 's/\r\n/\n/g' on the backed up file. Seriously, WTF was he doing as an admin?

    \r\n is a perfectly valid sequence in a binary file, and if the file is compressed, changing the \r\n to a \n will break the compressed file.

  • linux hater (real men run sco) (unregistered) in reply to seebs
    seebs:
    Well, given that MS just stole the old Berkeley one, yes. Only it would be about 15 years newer, and would default to binary.

    Anyone who would actually choose to run linux on their desktop would probably only ever access linux servers.

    In which case it doesn't matter whether you are in ascii or binary mode. This could explain why you think linux is switching to binary mode.

  • linux hater (real men run sco) (unregistered) in reply to Worf
    Worf:
    Actually, a naive ASCII transfer will turn all LF->CR/LF. A smarter ASCII transfer will actually check to make sure that if an LF was encountered, a CR didn't precede it. So while the naive implementation will turn CR/LF to CR/CR/LF, a smarter implementation will turn <anything-but-CR>/LF to CR/LF, and leave CR/LF alone as is. So even that's not reversible.

    And also, Macs (pre-OS X) used CR as the line ending. So LFs turn to CR's, and CR/LF were transformed to just CR.

    I work on a cross platform source available project and consistent line endings used to be a problem. There would be files that had been editted on windows, unix and macos and the endings were never cleaned ( they are now ).

    An interesting project is writing a program that can fix the mess. As the files are source files it's not 100% criticial.

    The problem is caused by editors that "intelligently" allow you to edit files with wrong line endings without converting the whole file. Like the terminally brain dead editors that when you press tab will either insert 4 spaces or a tab depending on whether the destination is a multiple of 8, please someone the keyboard away from whoever came up with that and make sure they get sacked from their job & never work with computers again.

  • SomeName (unregistered)

    One time when I was writing some C++ code I was trying to read/write files and did something akin to "path" + "path" (not strings, but char arrays), it somehow went through compiler and obviously didn't do what I expected. Random address result in a valid(!!!) path. It was inside a loop. Whole thing ended up destroying a lot of files - mostly source code of itself.

Leave a comment on “The Loony BIN”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article