Netbeans Recursive folder generation



  • I killed the Netbeans when it stalled on generating a project. When I looked at the project's folders in windows explorer, I saw this:






    Perhaps the real wtf is the image's poor quality.



  • Well it certainly makes me go WTF?!  Been around a while though I think



  • The real WTF here is that Windows Explorer has an arbitrary path length limit that is significantly less than the actual path length limit for Windows applications. Some utter moron at Microsoft used a static buffer that wasn't big enough, in the single most frequently used application that they ship!

    And, despite this fairly simple bug having been present and widely known since at least win2k, it still hasn't been fixed.



  • Yeah, I've seen lots of completely pointless and arbitrary limitations in MS software. The parameter limit in Excel's "CHOOSE" function comes readily to mind...



  • @asuffield said:

    The real WTF here is that Windows Explorer has an arbitrary path length limit that is significantly
    less than the actual path length limit for Windows applications. Some
    utter moron at Microsoft used a static buffer that wasn't big enough,
    in the single most frequently used application that they ship!

    And, despite this fairly simple bug having been present and widely known since at least win2k, it still hasn't been fixed.


    And that nicely sums up the entire problem with Windows, doesn't
    it?  Not only does it illustrate their level of programmer
    expertise;  it illustrates their approach to fixing broken code
    and their idea of usability.



  • I get the idea that these moronic problems are a combination of moronic programmers ("I don't know how to fix it") and moronic management ("I want to fix it but they won't let me").

    Not all coders at MS are idiots; I imagine most are pretty damn knowledgeable.



  • @VGR said:

    Not only does it illustrate their level of programmer expertise;  it illustrates their approach to fixing broken code and their idea of usability.

    Since the documented limit on pathnames has been 260 characters since 1993, it isn't accurate to call software that only supports 260 character pathnames "broken". It should, instead, be called "standard compliant".

    And if you think you need more than 260 characters for a path in the name of usability, you're retarded.

     



  • @CDarklock said:

    Since the documented limit on pathnames has
    been 260 characters since 1993, it isn't accurate to call software that
    only supports 260 character pathnames "broken". It should, instead, be
    called "standard compliant".


    I think you're forgetting the obvious...





    ...it was the same software that CREATED those folders to begin with.
    "I'll happily make the dumb folders, for no purpose at all, since I am
    buggy, but I'll die before I let you access them or try to correct my
    mistake by deleting them!"



  • @RayS said:

    @CDarklock said:
    Since the documented limit on pathnames has
    been 260 characters since 1993, it isn't accurate to call software that
    only supports 260 character pathnames "broken". It should, instead, be
    called "standard compliant".


    I think you're forgetting the obvious...





    ...it was the same software that CREATED those folders to begin with.
    "I'll happily make the dumb folders, for no purpose at all, since I am
    buggy, but I'll die before I let you access them or try to correct my
    mistake by deleting them!"


    WTF???   Windows Explorer did not create the folders.



  • Oops my mistake. I think I got carried away thinking about something
    else I've been wrestling with recently that does a very similar thing
    (making files & folders it won't let you delete).

    I missed the part about trying to access it in Explorer, and assumed it was a part of the IDE.



  • @CDarklock said:

    Since the documented limit on pathnames has been 260 characters since 1993, it isn't accurate to call software that only supports 260 character pathnames "broken". It should, instead, be called "standard compliant".



    So why does Windows allow any application to create longer paths?



  • @ender said:

    @ammoQ said:
    So why does Windows allow any application to create longer paths?
    Because 2000 and newer don't have this limit (I'm not sure about NT4 and older though).

    So why does the Windows Explorer not know about that? One would think this program is an important part of the operating system.



  • @ammoQ said:

    @ender said:
    @ammoQ said:
    So why does Windows allow any application to create longer paths?
    Because 2000 and newer don't have this limit (I'm not sure about NT4 and older though).

    So why does the Windows Explorer not know about that? One would think this program is an important part of the operating system.


    One would think so, yes.

    But Windows Explorer is possible one of the programs that has undergone the least possible amount of revisions in the last ELEVEN YEARS.

    I mean, for freak's sake, it doesn't even have a New Folder button in its main application. You have to right-click, select New and wait (depending on how fast your machine is) until the Templates menu has loaded, before you can add a new folder. The irony is that its baby application, the Save and Open dialogs, DO have a New Folder button.

    And of course its tie-in with IE is a complete fuckup, with the exception of the address bar. But that should be made Explorer-native, and respond to http:// requests, not be a function of IE itself.

    Let's not get started on its screwy folder-layout memory. I have the filesize column before the filename column, because of its text alignment. Handy. But sometimes it just arbitrarily decides to undo that. Also for the presence of Filmstrip in the View menu.

    Hm.

    One wonders why I've never seriously looked into Explorer replacements...



  • @ammoQ said:


    So why does Windows allow any application to create longer paths?

    There are several reasons.

    First, the disk partition may not belong exclusively to Windows. Other operating systems exist which can create and use NTFS partitions, and which do not have a 260 character limitation on paths.

    Second, the limitation in Windows exists only for certain API functions, which in turn propagates outward to the applications that depend on those APIs. But you don't have to use those API functions. You can use other ones which don't have this limitation. Microsoft has chosen not to do so, because the value of this change is virtually zero when compared to the amount of developer effort it would take to make it. If you disagree, the APIs are public and documented, so you can put forth that effort yourself.

    Third, since the NTFS filesystem can handle paths of essentially arbitrary length, people would scream incessantly about Microsoft crippling their computers if they were unable to exercise the full power of their hardware by making all the directories they want. It's immensely stupid, and nobody in their right mind should expect it to work at all, but many people are quite distinctly NOT in their right mind.

    I think the official "general public" answer is the first one. The second one is for developers and IT people, who are a bit more technical. The third one, however, is probably closest to the truth.



  • @CDarklock said:

    @ammoQ said:


    So why does Windows allow any application to create longer paths?

    There are several reasons.

    First, the disk partition may not belong exclusively to Windows. Other operating systems exist which can create and use NTFS partitions, and which do not have a 260 character limitation on paths.



    Heh? Which operating systems other than Windows know how to operate on NTFS partitions without breaking them? Doing that in Linux is still a risky game for writing operations.


    Second, the limitation in Windows exists only for certain API functions, which in turn propagates outward to the applications that depend on those APIs. But you don't have to use those API functions. You can use other ones which don't have this limitation. Microsoft has chosen not to do so, because the value of this change is virtually zero when compared to the amount of developer effort it would take to make it.

    The value of the Windows Explorer being able to operate on the file system without arbitrary limits is IMO not "virtually zero". It means customers get a tool that actually works as expected.


    If you disagree, the APIs are public and documented, so you can put forth that effort yourself.


    I probably could, but I think that's not my job.


    Third, since the NTFS filesystem can handle paths of essentially arbitrary length, people would scream incessantly about Microsoft crippling their computers if they were unable to exercise the full power of their hardware by making all the directories they want. It's immensely stupid, and nobody in their right mind should expect it to work at all, but many people are quite distinctly NOT in their right mind.


    So they can make all the directories they want, but not use the file management tools to work on those directories? That's what I'd call "crippling their computers".



  • @asuffield said:

    The real WTF here is that Windows Explorer has an arbitrary path length limit that is significantly less than the actual path length limit for Windows applications. Some utter moron at Microsoft used a static buffer that wasn't big enough, in the single most frequently used application that they ship!

    This may not be just a matter of the size of a static buffer.  If the length limit of about 256 characters is exceeded, you'll need to use Unicode versions of some API functions instead of straight ASCII path names.  See Making Room for Long Filenames and search for CreateDirectory.

    Oh, and by the way, arbitrary limits are a matter of course in standard UNIX command-line utilities ("too many arguments") so don't act like this symptom is in any way specific to Microsoft...

    Finally, even if Windows had allowed the Netbeans IDE to create an infinitely long path, it probably would still not have been enough for what NetBeans apparently had in mind here, or at least it would have taken it an infinitely long time to create the directory tree.  Remember, the real WTF here is the infinite recursion in NetBean's directory tree.


Log in to reply