Path: csiph.com!x330-a1.tempe.blueboxinc.net!aioe.org!news.glorb.com!postnews.google.com!news1.google.com!npeer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!spln!extra.newsguy.com!newsp.newsguy.com!news1 From: Michael Wojcik Newsgroups: comp.lang.java.programmer Subject: Re: Death To Sub-Sub-Sub-Directories! Date: Tue, 10 May 2011 11:48:57 -0400 Organization: Micro Focus Lines: 181 Message-ID: References: <34va98-dgm.ln1@dagon.net> NNTP-Posting-Host: pbdeb86408d4311d48b3dc68866ab0484861ba16352199f35.newsdawg.com Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.5.0 In-Reply-To: Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:3923 Zapotec wrote: > On 09/05/2011 1:15 PM, Michael Wojcik wrote: >> Zapotec wrote: >>> >>> 1. Typing long directory names or click-click-clicking to deeply-nested >>> folders is a pain, and will be required if you aren't using an IDE >>> like NetBeans or Eclipse >> >> I often use vim to edit my Java sources, and I don't have to type long >> directory names or click-click-click, thanks to the magic of filename >> completion. > > Completion again. People talk about it like it's a magic bullet, but > it's not, especially when there are a lot of possible completions, which > happens when there is a common prefix (like > src/java/com/mylongcompanyname/mylongprojectname/dal) to a lot of the > filenames. Works fine for me. Is it possible that your experience is different from mine? Nah. Surely you must be correct that I experience pain due to long directory names. >> Not that typing long directory names would be any great burden, since >> entering a filename is a tiny portion of the work I do when producing >> new code or maintaining old. > > Every little bit adds up, and time spent doing peripheral tasks is time > not spent coding, testing, or debugging. You have not demonstrated that it adds up to anything significant. I'll wager it doesn't. Certainly it's far less than the time I've spent over the last two decades writing Usenet posts. >>> 2. On Windows, at least, it's not implausible to reach the path name >>> length limit of the filesystem and run into even more headaches. >> >> Really? The NTFS path name length limit is 32KB, for applications that >> use the proper APIs, which seems like it ought to be enough. > > And what "proper APIs" might those be, that for instance Microsoft's own > cmd.exe and Explorer evidently don't use? RTFM. They're the Unicode versions of the File APIs. http://msdn.microsoft.com/en-us/library/aa365247%28VS.85%29.aspx Gosh, that was hard to find. First hit for "path length" on MSDN. cmd.exe doesn't support them properly (it does for some builtins, but it has its own path length limitations that are separate from the OS ones), because Microsoft frankly doesn't give a damn about cmd.exe. (If you're going to use one of their shells, they'd like it to be Powershell.) But that's rather beside the point, which is that the short path length limitation was corrected in Windows long ago - I think with NT 4.0. > I might add that Java doesn't use these phantom APIs either, as > evidenced if you try to use java.io.File/FileInputStream to read a file > that exceeds a much shorter length. Did you specify it correctly, using a UNC name? I thought not. > (Make a directory with a one-letter > name in a drive root and a file with a name about 150 characters long in > it. Then rename the directory to a similarly long name and try to access > it with java.io ... boom! FileNotFoundException.) ----- C:\tmp>dir c:\tmp\longdir1234567890123456789012345678901234567890123456789012345 67890123456789012345678901234567890123456789012345678901234567890123456789012345 678901234567890\averylongfilename12345678901234567890123456789012345678901234567 89012345678901234567890123456789012345678901234567890123456789012345678901234567 8901234567890123456789012345678901234567890 The filename or extension is too long. C:\tmp>java -cp . test \\?\c:\tmp\longdir123456789012345678901234567890123456789 01234567890123456789012345678901234567890123456789012345678901234567890123456789 0123456789012345678901234567890\averylongfilename1234567890123456789012345678901 23456789012345678901234567890123456789012345678901234567890123456789012345678901 23456789012345678901234567890123456789012345678901234567890 foo ----- Works just fine for me. Here's the source: ----- import java.io.*; class test { public static void main(String[] args) throws java.io.IOException { File file = new File(args[0]); FileInputStream fs = new FileInputStream(file); int ch; while ((ch = fs.read()) != -1) { System.out.print((char)ch); } fs.close(); } } ----- >> Even apps >> that use the old API get a path length of 260 ASCII characters, which >> requires some effort to exceed. > > Not with Java's long/and/deeply/nested/package/hierarchies... I've never had that problem. >> If the problem is your Windows source directories are buried under >> some unreasonably long path (which probably also contains spacey names >> and other infelicities), just create a junction to it in some more >> convenient place. > > Junctions are those funny-behaving versions of My Documents and such > that are in Vista and Windows 7, right? Junctions are a facility of NTFS, built on top of reparse points. If you're going to complain about Windows, maybe you should learn how it works first. > The last time I checked, the > user can't create those, Check again. > at least not with the default set of tools > available by e.g. right-click-and-drag in Explorer. Whereas in Unix and Linux installations, all possible actions are available in the various GUI file managers? > If Microsoft had been intelligent, competent, and capable of even decent > copycatting, let alone true creativity, outside of the > inventing-new-anticompetitive-dirty-tricks department, And now the ad hominem. Let's all watch as Zapotec loses the ability to formulate an actual argument. > Vista would have > included real proper symlinks, It does: ----- C:\tmp>mklink /? Creates a symbolic link. MKLINK [[/D] | [/H] | [/J]] Link Target /D Creates a directory symbolic link. Default is a file symbolic link. /H Creates a hard link instead of a symbolic link. /J Creates a Directory Junction. Link specifies the new symbolic link name. Target specifies the path (relative or absolute) that the new link refers to. ----- NTFS also supports hard links and junctions. > which you can click through in Explorer As indeed you can. > without getting error messages, and which would have been available on > the right click menu: right click, drag, "Make symlink here". :P I agree that being able to make links and junctions from Explorer would be useful for lazy whiners who can't be bothered to learn how their OS works. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State University