• Fristo (unregistered)

    FirstPostman360

  • Lothar (unregistered)

    The RWTF is why the application isn't just stripping away the trailing backslash if it's so nasty and rely on the ability of users to read and understand text.

  • (nodebb) in reply to Lothar

    The RRWTF is that it probably is doing that, and nobody ever thought to fix the comment that's far away in a different file.

  • Richard (unregistered)

    The property is called "...FilePath" so I'd expect it to be wanting the path to a file. Putting the backslash on the end means that you're referring to a folder (like "C:" or "C:\Program Files"). If it wants a folder, then a name like "...FolderPath" or "...DirectoryPath" or whatever might be appropriate.

  • Matt W (unregistered)

    string.TrimEnd('\');

  • (nodebb)

    var fullPath = Path.Combine(firstPart, secondPart); This handles all permutations as all the are looking for is the path and the second part will have the file. Building paths with string concatenation is so wrong these days.

  • Mike5 (unregistered)

    So, no comments about the fact that the application is initializing its database from a path called TESTdata ?

  • David (unregistered)

    TRWTF is of course that it is using backslashes as path separators, instead of forward slashes as any sane system uses.

  • NULL (unregistered) in reply to Mike5

    Maybe it was stumbled upon in a test build or its a TDWTF-redaction

  • Hannes (unregistered) in reply to Mike5

    Maybe the company runs various tests on products that are being sold (like https://en.wikipedia.org/wiki/Stiftung_Warentest ), and they use this data base to store their TEST data?

  • Edsger Dijkstra (unregistered)

    TRWTF is .net not compiling the comments. It'd work just fine if the compiler did what the programmer said.

  • ApoY2k (unregistered) in reply to David

    Especially because (File|Directory)Info classes in .NET can handle them just as well

  • MaxArt (unregistered)

    TRWTF is that "I don't know why..." at the beginning.

    Dig in the problem and solve it, then!

  • Developer Dude (google)

    Does C# not have a method for normalizing paths?

  • Viktoras (unregistered)

    Don't push the red button!

  • Anonymous (unregistered)

    I don't think this article will be popular. I'm expecting a public backslash.

  • Carl Witthoft (google)

    {drifting off into meta-analogy land} When you're stuck in a jungle of code snarls, you need to do a lot of slash-ing to clear your path . Hmmm... maybe I'll write a function called "machete.exe" that rotates back- and forward-slashes by +/- 15 degrees .

  • Robert Hanson (unregistered)

    Does anybody but me get really pissed when an ad on the radio or tv reads a URL, and it looks like xyz.com/special, but they read it as "xyz dot com BACKSLASH special"? And don't get me started on using the special-character-escape token as a directory separator; one of the stupidest decisions MS ever made.

  • Zenith (unregistered) in reply to Robert Hanson

    MSDN says that the Win32 path functions will take either form. Then along comes Office 2010 that inexplicably won't. The errors that come out of it if you use / are along the lines of "part of the path is missing."

  • 8128 (unregistered)

    the unicorn thing is pretty easy to find for us elinks users

  • Adam (unregistered)

    Well, this is a new one, having the current day's WTF be applicable to a code review.

  • (nodebb)

    What are the odds they have a custom xml parser. And try to create C:\TestData\"

  • Anon (unregistered) in reply to Robert Hanson

    Worse than nails on a chalkboard.

  • WindowsDev (unregistered) in reply to Robert Hanson

    DOS used "^" as the escape character and "/" as the character for command line switches (eg "ls -r" is roughly equivalent to "dir /S"). DOS also didn't have folders; there were just files. MSDOS 2.0 added a directory hierarchy, but they couldn't make the path separator "/" since it would break all those old programs with command line switches. They did make all of the filesystem APIs and built-in programs accept "/" as a directory separator too, so you can use "C:/foo/bar/" notation 99% of the time.

  • Klimax (unregistered) in reply to Robert Hanson

    WinAPI accept both. And IIRC it is backward compatibility with CP/M.

  • Anonymous') OR 1=1; DROP TABLE wtf; -- (unregistered)

    TRWTF is that they put their database into a subfolder of the root of the drive, which normal users don't have permission to do, instead of in the user profile directory or the application's directory under Program Files.

    Actually wait, TRWTF is XML.

  • FuuzyFoo (unregistered)

    And this is why I assume in file name handling that I'm going to write some code when I'm half-asleep or that the configuration file will get corrupted:

    Always sanitize directory names - remove any trailing backslashes, and always always add your own. The Path class actually does this really simply.

  • Gerry (unregistered) in reply to Robert Hanson

    " And don't get me started on using the special-character-escape token as a directory separator; one of the stupidest decisions MS ever made."

    I don't think 8086 assembler had an "escape character". DOS wasn't written in C

    Here's an alternative quote:

    "Using the path separator as an escape token was one of the stupidest decisions Dennis Ritchie made."

    Not very sensible eh? Or do you have a time machine, so unless you have a time machine to tell Gary Kildall (C/PM) not to use / for parameters, be quiet.

  • Ryan (unregistered) in reply to Anonymous

    ba dum tss

  • (nodebb) in reply to Zenith

    "MSDN says that the Win32 path functions will take either form"

    It says rather more than that, actually. Specifically, taking the example of CreateFile(...);

    • There are two functions hiding behind that. CreateFileA takes the filename as a string of "ASCII" (extended ASCII in your system's MBCS code page, actually) characters, while CreateFileW takes the filename as a string of "Wide" characters, approximately BMP-only UCS-2 Unicode.
    • Both are limited to MAX_PATH (260) characters in the path, counting MBCS characters according to their byte count, not as one each.
    • CreateFileW is also not limited to MAX_PATH characters, but 32767 characters.

    How does that last bit work? Well, if you use a fully parsed absolute pathname and prefix it with \\.\, you can go up to eleven, er, 32767. If not, you are limited to MAX_PATH. Notably: relative paths, paths containing . or .. and paths containing forward slashes are not fully parsed. UNC paths are supported, and they end up beginning \\.\\\servername\(yes, three backslashes in a row).

  • Quite (unregistered) in reply to WindowsDev

    TRWTF was DOS.

    Having grown up with DEC, cut my teeth on a VAX and had lullabies sung to me in VMS, I could not believe the short-sighted design decisions made with DOS. 8 character limitation on filenames. 3-character extensions. Misimplemented wildcards. And so on. But hey, that's where they were, PCs were bodged together quickly and cheaply in order to make a flailing grasp at the tailgate of a rapidly-departing bandwagon -- and it just about managed to hang on, and the PC joined the many other portable computers that were available in the 1980s. Yes, if they had taken their time about it, they could have developed a seriously good machine, of a similar quality to the products produced at the time by Acorn.

    In due course, PCs evolved into something more-or-less usable, and many of the appalling design decisions made at the time were eventually superseded, and some 15 years on they had more-or-less come up with a halfway-decent product. Or at least, that's how they are perceived -- there are so few alternatives to the PC nowadays, we cannot tell what a well-designed machine looks like any more.

    The secret of the PC's success? Rigorous attention to backward compatibility. This lasted until they had achieved a stranglehold on the market. It's less important now that everyone is so firmly wedded to the Windows solution, and now when you buy a new machine you need to be prepared for the eventuality that many of your programs which worked perfectly well on your XP / Vista machine won't even install on Windows 10. "You should have upgraded it several versions ago," you learn, and, for example, your complete financial records are now completely unusable because there is no longer an upgrade path from Microsoft Money to its half-baked replacement for legacy files.

  • Zenith (unregistered) in reply to Steve_The_Cynic

    Even more than that, it says that Windows 10 can opt out of the 260 limit in Unicode via registry keys or application manifests. Not real fond of the latter method as I think they abuse that to cover up poor design decisions (like how VerifyVersionInfo() will report all kinds of misinformation).

  • Simon (unregistered) in reply to Quite

    When I first met VMS (1981) filenames were max 8.3. I forget when they were extended to 39.39 ...

  • Nasukkin (unregistered) in reply to Steve_The_Cynic

    TRRRWTF is that someone still saw the comment and implemented the trailing-backslash-stripper-logic in a separate place.

  • IChrisI (unregistered)

    These days, Windows supports forward slashes for most things. C:/TestData/ likely would have worked as well, may have avoided backslash / double-escaping issues in the program, and may have avoided incorrect escaping issues in the config file.

    This has been the case since at least Windows XP, maybe even Windows 95.

  • S. Ivar (unregistered) in reply to David

    I see that you never worked with Oracle One Retail applications, where in the same configuration file you need to have either "\" as a separator or "/" as a separator (when working on Windows of course). And as for the ending separator it also depends on the variable, regardless of the "\" or "/" notation...

  • gnasher729 (unregistered) in reply to MaxArt

    "The real WTF is not knowing why"

    Not at all. I personally like knowing why things work the way they do, but there is so much stupidity around, there is no point of knowing the reason for every bit of stupidity. And if the answer is "because the author of the relevant code is an idiot", or "because the author of the relevant code was ordered by management", how would that improve things in any way?

  • gnasher729 (unregistered) in reply to Nasukkin

    How do you know they saw the comment? They saw that the application was broken, because some function was handed a string ending in \ when it shouldn't. If removing the \ if present reliably fixes the problem, how are they going to know about the comment? Especially since there is no code path from the caller to the file where the code path is set.

  • doubting_poster (unregistered)

    This one made me chuckle. I can see the person filling in the config going: "I'm just... just... going to put a backslash there... yeah."

  • Ali Razeghi (google)

    That awkward moment when I remember my own scripts had this bug before I used join-path in Powershell so it didn't matter anymore.

  • Peter Wolff (unregistered) in reply to David

    MacOS up to 9 uses the colon as path separator. I wouldn't call it insane.

    And, I'd expect a sane OS to treat a directory like a file. A sane shell would show either nothing or the directory name on ls <dirname> instead of the contents of that directory. ls isn't cat to files, so why to directories? (Listing the file in a directory is ls <dirname><pathseparator>)

  • Mitch (unregistered) in reply to Viktoras

    What, THIS one?

Leave a comment on “The Installer Configuration”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article