If the "blah blah blah..." is meant to represent a very long file name or path, my guess would be that you've bumped up against the Windows path limit (260 chars) which can manifest itself in weird ways. See cause 4 here:
http://support.microsoft.com/kb/320081 Since you're also having issues in Windows/DOS it seems unlikely that this is a Java or Clojure bug since they probably use the same underlying file system APIs as Explorer. Good luck, Dave On Tue, Apr 26, 2011 at 2:12 PM, Ken Wesson <kwess...@gmail.com> wrote: > Anyone know what is going on here? I'm trying to use my Clojure REPL > to rename a file that's gotten "stuck" on my Windows box (somehow, > both Explorer and the command prompt claim the file isn't found if I > try to move, delete, or rename it) but I get this: > > com.example.isii=> (FileInputStream. (nth (.listFiles (java.io.File. > "C:\\Users\\Owner\\Documents\\Downloads")) 44)) > #<CompilerException java.io.FileNotFoundException: > C:\Users\Owner\Documents\Downloads\blah blah blah blah blah blah blah > blah blah blah blah blah blah blah blah blah blah blah blah blah blah > blah blah blah blah blah blah blah blah blah.mpeg (The system cannot > find the file specified) (NO_SOURCE_FILE:97)> > > Either Java has the same bug as Windows Explorer and Windows cmd.exe, > which seems very unlikely (why would Sun/Oracle and Microsoft make > identical mistakes?), the NTFS volume itself is corrupt in some way > (practically unheard-of), or something's going wrong with interop. > > I first tried pasting the file name into (.renameTo (File. > "C:\\Users\\blah blah blah")) and it didn't work so I had the idea > that maybe the file had a funny character in its name that was causing > problems. But the above uses .listFiles on the directory to pull the > File object right out of the system (it happens to be the 45th file in > the order produced by .listFiles). So it *should* work. But it > doesn't! The .listFiles method is listing a file that .renameTo cannot > rename and the FileInputStream constructor cannot open; both claim the > file doesn't exist. > > Crazily, .isFile says false for this File object, so does > .isDirectory, and so does .exists. I'm pretty sure that File objects > returned by .listFiles are supposed to .exists, at the very least. > Unless the Java API has a bug here, and this is an old but > non-deprecated part of a heavily-used stock JavaSE API so that seems > highly unlikely, then I have to suspect some wires are getting crossed > during Clojure's Java interop. Clojure is newer and much less > well-tested than the JavaSE API in question. > > Perhaps one object is being replaced with another, or the wrong > methods are being called? > > At this point, the only other alternatives are increasingly outlandish > and unlikely: > > 1. A bug in an old, heavily-used, non-deprecated, standard JavaSE API > that's gone undetected for ages. > > 2. A bug in a low-level kernel file-handling routine that causes a > file to exist for listing purposes but not for opening/rename/delete, > in an NT kernel operating system on its second service pack rather > than a Windows 7 beta or Windows 3.1 or some such crap. (Microsoft is > of course notorious for bugs, but generally of the > dodgy-C-pointer-arithmetic variety and the security-hole variety; > getting basic file handling wrong is not really their style, and > besides, something like that would be an utter showstopper in high > performance server environments, a market Microsoft has been trying to > gain significant share in for eons. Servers needing to be rebooted > every few days? Annoying. Servers that get hacked every few months and > need to be reloaded from the last backup? Annoying. Servers that can't > find, read, or handle files correctly, resulting in spurious 404 > errors and the like consistently afflicting particular web pages? > Unusable.) > > 3. Some kind of damage to the underlying NTFS volume. > > Case 3, if true, would be especially worrying since that's my C drive. > If it goes, the computer goes. Oh, most of my data is backed up and > recoverable but having to replace the drive, the operating system, and > reinstall all applications is likely to be very time consuming and > expensive. So I hope you'll pardon me if I hope it's a bug in Clojure > instead. :) > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
