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
