Flash Builder = FAIL^FAIL



  • One of my coworkers was working in Adobe Flash Builder today (which is based on Eclipse, one of the shittiest IDEs inflicted upon mankind). He noticed that he was using the wrong workspace, so he told Flash Builder to use the correct one... which happenened to be the parent of the current workspace. The IDE hung for a while (which is quite normal) but he became concerned because his hard disk access light was going crazy, so he killed Flash Builder and checked the folder, to be greeted with the following (scroll right for awesomeness):

    Flash Builder had taken the folder he'd chosen and copied it into itself. Then copied it into itself again, and again, and again...

    The end result was an un-deletable folder tree because the resulting path was longer than 255 characters; neither Explorer nor CMD could handle that. (A WTF in and of itself, but I digress.) We eventually did some PowerShell trickery using the \\?\ path prefix and, after determining that Flash Builder had nested the directories FIFTY-ONE LEVELS DEEP, finally nuked it.

    (The reason not all levels are shown in the screenshot is that Explorer will not allow you to navigate deeper than the aforementioned 255 characters.)

    Just... what. Seriously, what. I've seen bad software in my day, but this... it's a whole new level. I am now officially afraid of Java.



  •  We heard you like your Installer directories, so we put an Installer directory inside your Installer directory so you can see your Installer directory when you're in your Installer directory...



  • @The_Assimilator said:

    The end result was an un-deletable folder tree because the resulting path was longer than 255 characters
    @The_Assimilator said:
    after determining that Flash Builder had nested the directories FIFTY-ONE LEVELS DEEP
    I've run into this problem before and find it quite bizaare.  You can create a path longer than 255 characters, but you can't delete it.  That's some real design genius at work there.



  • @El_Heffe said:

    You can create a path longer than 255 characters, but you can't delete it.  That's some real design genius at work there.


    Actually, you can; just not with the ancient drive:\pa\th notation. Alas, the sins of MS-DOS and Windows 3.1 developers are thus visited on us; the price for "most-old-things-kinda-work". Not fixing this during the umpteen bazillion years since long filenames and long paths became common is a WTF, indeed.



  • @piskvorr said:

    @El_Heffe said:
    You can create a path longer than 255 characters, but you can't delete it.  That's some real design genius at work there.

     

    Actually, you can; just not with the ancient drive:\pa\th notation. Alas, the sins of MS-DOS and Windows 3.1 developers are thus visited on us; the price for "most-old-things-kinda-work". Not fixing this during the umpteen bazillion years since long filenames and long paths became common is a WTF, indeed.
    I know that there are vaious forms of trickery you can use in this situation but the point is you shouldn't be able to get into that situation in the first place.  If there's going to be a 255 character limit on path names, that's fine.  The OS should say HOLY SHIT YOU'RE CREATING A PATH LONGER THAN 255 CHARACTERS - SORRY CANNOT CONTINUE.

     



  • @El_Heffe said:

    @piskvorr said:

    @El_Heffe said:
    You can create a path longer than 255 characters, but you can't delete it.  That's some real design genius at work there.

     


    Actually, you can; just not with the ancient drive:\pa\th notation. Alas, the sins of MS-DOS and Windows 3.1 developers are thus visited on us; the price for "most-old-things-kinda-work". Not fixing this during the umpteen bazillion years since long filenames and long paths became common is a WTF, indeed.
    I know that there are vaious forms of trickery you can use in this situation but the point is you shouldn't be able to get into that situation in the first place.  If there's going to be a 255 character limit on path names, that's fine.  The OS should say HOLY SHIT YOU'RE CREATING A PATH LONGER THAN 255 CHARACTERS - SORRY CANNOT CONTINUE.

     

    The problem is that the limit is, at this point, merely cosmetic - Windows supports paths up to short.MaxValue (32,768) in length when the aformentioned \\?\ prefix is used. TRWTF is that Explorer and CMD don't support said prefix (seriously guys? in 2011?), but Java does - hence why Eclipse, a Java app, was able to nest the directories so deep, but why Explorer/CMD couldn't nuke them.

    Bonus WTFery: the .NET Framework doesn't support long paths by default while Java does. This is possibly one of the worst decisions Microsoft has ever made, ever.



  • This, among other reasons, is why I have cygwin installed on all of my Windows machines.  A simple "rm -rf Installer" would take care of an indefinitely long path, wouldn't it?

     

    They can make me use Windows to develop on but they can't take away my grep :)



  • Also, if anyone can explain to me why making the maximum path length a signed (32,768) rather than unsigned (65,535) integer makes ANY SENSE, please do. Unless "negative path lengths" is a Windows 8 feature.



  • @The_Assimilator said:

    Also, if anyone can explain to me why making the maximum path length a signed (32,768) rather than unsigned (65,535) integer makes ANY SENSE, please do. Unless "negative path lengths" is a Windows 8 feature.

    Maybe they count '..' as the negative notation for a path, thus only allowing you to go back 16,384 directories from the current directory.


  • ♿ (Parody)

    @The_Assimilator said:

    Also, if anyone can explain to me why making the maximum path length a signed (32,768) rather than unsigned (65,535) integer makes ANY SENSE, please do. Unless "negative path lengths" is a Windows 8 feature.

    You're assuming that 1 character is one byte. I suspect that the limit is based on the actual memory used, and the number of characters follows based on typical UTF-16 path encodings. Of course, by that logic, some paths might have a smaller limit if you use characters that are represented by 4 bytes.



  • @The_Assimilator said:

    ... Eclipse, one of the shittiest IDEs inflicted upon mankind ...

    Are there any IDEs which don't fit in that bracket?



  • @pjt33 said:

    @The_Assimilator said:
    ... Eclipse, one of the shittiest IDEs inflicted upon mankind ...
    Are there any IDEs which don't fit in that bracket?

    Visual Studio doesn't.  Eclipse does, but Visual Studio doesn't.


  • FAIL XOR FAIL is 0 for any definition of FAIL. (excepting language specific stuff like NaN)



  • @Sutherlands said:

    @pjt33 said:

    @The_Assimilator said:
    ... Eclipse, one of the shittiest IDEs inflicted upon mankind ...
    Are there any IDEs which don't fit in that bracket?

    Visual Studio doesn't.  Eclipse does, but Visual Studio doesn't.

    Really? When I started using VS I couldn't work out why it was so far behind Eclipse in the kind of basic stuff which an IDE is supposed to be useful for, like searching your code. Of the five IDEs I've used, Eclipse was the best.



  • @pjt33 said:

    @Sutherlands said:

    @pjt33 said:

    @The_Assimilator said:
    ... Eclipse, one of the shittiest IDEs inflicted upon mankind ...
    Are there any IDEs which don't fit in that bracket?

    Visual Studio doesn't.  Eclipse does, but Visual Studio doesn't.
    Really? When I started using VS I couldn't work out why it was so far behind Eclipse in the kind of basic stuff which an IDE is supposed to be useful for, like searching your code. Of the five IDEs I've used, Eclipse was the best.
    What kind? I'm using VS2010 right now.  It has Find References, Go to Definition, text search, etc...


  • Netbeans FTW!

    Eclipse is a turd compared to it. 

    Unfortunately, for most projects, I can't be bothered to use it and set everything up for that project, so I just use the default IDE that comes with the toolkit :o

     



  • @pjt33 said:

    Really? When I started using VS I couldn't work out why it was so far behind Eclipse in the kind of basic stuff which an IDE is supposed to be useful for, like searching your code. Of the five IDEs I've used, Eclipse was the best.

    You are soooo high, man! Wake and bake every day, huh? Wooo!



  • @The_Assimilator said:

    (scroll right for awesomeness):

    FTFY, now you can actually scroll in Firefox. Maybe it was possible to scroll in a different browser before, but now you actually scroll in Firefox.

    Edit: I have a similar story. A bug in a Miranda plugin I had once caused it to copy the whole program files dir into my profile dir. Back then, the profile dir was by default in the app dir, which caused infinite magic to happen. It didn't go that deep though because copying the program files folder took pretty long, especially on the older drive I had, so I could still delete it. The interesting thing is though that it renamed every single file to use only lower case letters.



    Edit2: I spent a significant amount of time trying to imagine how the function relation y=xx looks for x < 0 and y in the complex domain.



  • @derula said:

    FTFY, now you can actually scroll in Firefox.

    You have revealed to me... Cookie Monster!



  • @Sutherlands said:

    @pjt33 said:

    @Sutherlands said:

    @pjt33 said:

    @The_Assimilator said:
    ... Eclipse, one of the shittiest IDEs inflicted upon mankind ...
    Are there any IDEs which don't fit in that bracket?

    Visual Studio doesn't.  Eclipse does, but Visual Studio doesn't.
    Really? When I started using VS I couldn't work out why it was so far behind Eclipse in the kind of basic stuff which an IDE is supposed to be useful for, like searching your code. Of the five IDEs I've used, Eclipse was the best.
    What kind? I'm using VS2010 right now.  It has Find References, Go to Definition, text search, etc...

    Whereas Eclipse allows you to find read references, find write references, find all overrides of a method, etc. In VS 2008 (and I haven't heard that they've improved it in 2010), if you position the cursor on the keyword "set" inside a property and search for references it searches for all references to the property.



  • @pjt33 said:

    Whereas Eclipse allows you to find read references, find write references, find all overrides of a method, etc. In VS 2008 (and I haven't heard that they've improved it in 2010), if you position the cursor on the keyword "set" inside a property and search for references it searches for all references to the property.

    References

    Overloads

    The last one is resharper.  The first one is VS, but the last one is resharper.



  • @The_Assimilator said:

    Also, if anyone can explain to me why making the maximum path length a signed (32,768) rather than unsigned (65,535) integer makes ANY SENSE, please do. Unless "negative path lengths" is a Windows 8 feature.
     

    Probably to support UTF-16 paths.



  • @esoterik said:

    @The_Assimilator said:

    Also, if anyone can explain to me why making the maximum path length a signed (32,768) rather than unsigned (65,535) integer makes ANY SENSE, please do. Unless "negative path lengths" is a Windows 8 feature.
     

    Probably to support UTF-16 paths.

    (1) Unicode is unsigned (2) what does the length of a path have to do with the charset that path is encoded in? (3) are you trolling?



  • The reverse character obviously :D



  • @The_Assimilator said:

    (1) Unicode is unsigned (2) what does the length of a path have to do with the charset that path is encoded in? (3) are you trolling?

    @Boomzilla said:

    You're assuming that 1 character is one byte. I suspect that the limit is based on the actual memory used, and the number of characters follows based on typical UTF-16 path encodings. Of course, by that logic, some paths might have a smaller limit if you use characters that are represented by 4 bytes.

    So, basically, the idea is that 1 character = 2 bytes (UTF-16); limit on length of path = 64k bytes, thus 32k characters (excluding weirdo multi-2byte sequences in UTF16). It seems like a logical enough explanation, no idea if that's the actual reason.


  • ♿ (Parody)

    @The_Assimilator said:

    @esoterik said:

    @The_Assimilator said:

    Also, if anyone can explain to me why making the maximum path length a signed (32,768) rather than unsigned (65,535) integer makes ANY SENSE, please do. Unless "negative path lengths" is a Windows 8 feature.
     

    Probably to support UTF-16 paths.

    (1) Unicode is unsigned (2) what does the length of a path have to do with the charset that path is encoded in? (3) are you trolling?

    Are you trolling?



  • @boomzilla said:

    @The_Assimilator said:
    (1) Unicode is unsigned (2) what does the length of a path have to do with the charset that path is encoded in? (3) are you trolling?

    Are you trolling?

    We're all trolling, stop wasting time.



  • @blakeyrat said:

    @boomzilla said:
    @The_Assimilator said:
    (1) Unicode is unsigned (2) what does the length of a path have to do with the charset that path is encoded in? (3) are you trolling?

    Are you trolling?

    We're all trolling, stop wasting time.

    Are you trolling?



  • @derula said:

    @blakeyrat said:
    @boomzilla said:
    @The_Assimilator said:
    (1) Unicode is unsigned (2) what does the length of a path have to do with the charset that path is encoded in? (3) are you trolling?

    Are you trolling?

    We're all trolling, stop wasting time.

    Are you trolling?

    Once I caught a troll THIS BIG!


  • ♿ (Parody)

    @derula said:

    @blakeyrat said:
    @boomzilla said:
    @The_Assimilator said:
    (1) Unicode is unsigned (2) what does the length of a path have to do with the charset that path is encoded in? (3) are you trolling?

    Are you trolling?

    We're all trolling, stop wasting time.

    Are you trolling?

    I troll this forum sometimes. I wasn't on this thread, but sometimes I troll.



  • @Zemm said:

    @derula said:
    @blakeyrat said:
    @boomzilla said:
    @The_Assimilator said:
    (3) are you trolling?

    Are you trolling?

    We're all trolling, stop wasting time.

    Are you trolling?

    Once I caught a troll THIS BIG!

    Trolling on this forum is a unquestionable. It's not without humor, but it is a unquestionable.



  • @The_Assimilator said:

    @El_Heffe said:
    @piskvorr said:
    @El_Heffe said:
    You can create a path longer than 255 characters, but you can't delete it.  That's some real design genius at work there.

    Actually, you can; just not with the ancient drive:\pa\th notation. Alas, the sins of MS-DOS and Windows 3.1 developers are thus visited on us; the price for "most-old-things-kinda-work". Not fixing this during the umpteen bazillion years since long filenames and long paths became common is a WTF, indeed.
    I know that there are vaious forms of trickery you can use in this situation but the point is you shouldn't be able to get into that situation in the first place.  If there's going to be a 255 character limit on path names, that's fine.  The OS should say HOLY SHIT YOU'RE CREATING A PATH LONGER THAN 255 CHARACTERS - SORRY CANNOT CONTINUE.

    The problem is that the limit is, at this point, merely cosmetic - Windows supports paths up to short.MaxValue (32,768) in length when the aformentioned \?\ prefix is used. TRWTF is that Explorer and CMD don't support said prefix (seriously guys? in 2011?), but Java does - hence why Eclipse, a Java app, was able to nest the directories so deep, but why Explorer/CMD couldn't nuke them.

    piskvorr had it right, last I checked.  Everyone else quoted above seems to have it wrong, but piskvorr had it right.

    Basically, to remove a path that long in CMD, you need to cd into the path far enough so that either the relative path to the last component is characters long 255 or you are in the parent of the last component (if, for example, some ahole made a 255+3 file or directory name, and you don't know how to get the compatibility 8.3 filename.  You then use the relative path to delete from there.  Then you go back up a bit, rinse and repeat.  It may not work if you use the full path, but it should work doing it this way.

    Also, while I haven't tried it in ages, I seem to recall DELTREE worked just fine on these annoyances.  It may not work now, but it did work back in the DOS 6.22 days.

    Question: does it really limit you to only 32768 characters for the maximum existing file path?  Because I seem to recall some annoying putz back in college making one of these paths over a million characters long.  If I recall correctly, that was the incident for which I tried deltree, and was delighted to find it worked.



  • @tgape said:

    @The_Assimilator said:
    @El_Heffe said:
    @piskvorr said:
    @El_Heffe said:
    You can create a path longer than 255 characters, but you can't delete it.  That's some real design genius at work there.
    Actually, you can; just not with the ancient drive:\pa\th notation. Alas, the sins of MS-DOS and Windows 3.1 developers are thus visited on us; the price for "most-old-things-kinda-work". Not fixing this during the umpteen bazillion years since long filenames and long paths became common is a WTF, indeed.
    I know that there are vaious forms of trickery you can use in this situation but the point is you shouldn't be able to get into that situation in the first place.  If there's going to be a 255 character limit on path names, that's fine.  The OS should say HOLY SHIT YOU'RE CREATING A PATH LONGER THAN 255 CHARACTERS - SORRY CANNOT CONTINUE.
    The problem is that the limit is, at this point, merely cosmetic - Windows supports paths up to short.MaxValue (32,768) in length when the aformentioned \\?\ prefix is used. TRWTF is that Explorer and CMD don't support said prefix (seriously guys? in 2011?), but Java does - hence why Eclipse, a Java app, was able to nest the directories so deep, but why Explorer/CMD couldn't nuke them.

    piskvorr had it right, last I checked.  Everyone else quoted above seems to have it wrong, but piskvorr had it right.

    Basically, to remove a path that long in CMD, you need to cd into the path far enough so that either the relative path to the last component is characters long 255 or you are in the parent of the last component (if, for example, some ahole made a 255+3 file or directory name, and you don't know how to get the compatibility 8.3 filename.  You then use the relative path to delete from there.  Then you go back up a bit, rinse and repeat.  It may not work if you use the full path, but it should work doing it this way.

    Also, while I haven't tried it in ages, I seem to recall DELTREE worked just fine on these annoyances.  It may not work now, but it did work back in the DOS 6.22 days.

    Question: does it really limit you to only 32768 characters for the maximum existing file path?  Because I seem to recall some annoying putz back in college making one of these paths over a million characters long.  If I recall correctly, that was the incident for which I tried deltree, and was delighted to find it worked.

    FORMAT also works.





  • @tgape said:

    Basically, to remove a path that long in CMD, you need to cd into the path far enough so that either the relative path to the last component is characters long 255 or you are in the parent of the last component (if, for example, some ahole made a 255+3 file or directory name, and you don't know how to get the compatibility 8.3 filename.  You then use the relative path to delete from there.  Then you go back up a bit, rinse and repeat.  It may not work if you use the full path, but it should work doing it this way.

    Also, while I haven't tried it in ages, I seem to recall DELTREE worked just fine on these annoyances.  It may not work now, but it did work back in the DOS 6.22 days.

     

    I don't feel like taking the time to try it, but couldn't you also SUBST a drive letter to some proper prefix of the path, and delete the rest of the path relative to that drive?

     


Log in to reply