On Tue, Apr 26, 2011 at 2:36 PM, Ken Wesson <kwess...@gmail.com> wrote: > On Tue, Apr 26, 2011 at 2:26 PM, Dave Ray <dave...@gmail.com> wrote: >> 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. > > I assume that the file name cannot exceed any system limit, or else it > could not exist as such in the first place. Obviously the browser was > able to write the file to that directory with that name, after all; > the current state of the filesystem resulted from the same operating > system low level APIs rather than springing fully-formed from the brow > of Zeus. It would not make sense for those APIs to have one limit for > writing files and another, lower limit for reading them. Not even by > the sometimes-peculiar notion of what "makes sense" that they use in > Redmond. > > No, the problem is surely either at a lower level (drive damage?) or a > higher one (issues in Explorer, cmd.exe, and either java.io or > Clojure), or else it's an outright bug and not just an intentional > "limit".
However, one of the suggestions at that Microsoft page *kinda* worked. Specifically: "To resolve this issue, you may want to use the auto-generated 8.3 name to access the file." Doing that at cmd.exe produced the same nonsensical "File not found" error messages. On the other hand, user=> (.renameTo (java.io.File. "C:\\Users\\Owner\\Documents\\Downloads\\BLAHBL~1") (java.io.File. "C:\\Users\\Owner\\Documents\\Downloads\\blah blah.jpg")) true Since Microsoft's proposed fix didn't work using Microsoft's own tools, presumably the actual cause of the problem wasn't the limit in question (which presumably only gets exceeded when other operating systems than Windows have written to the NTFS volume anyway). On the other hand, it did suggest another way of getting a handle on the file, and that way apparently bypasses the Java IO/interop problem. And the file once renamed is usable and even what it should be, which appears to rule out disk drive failure or FS corruption as the cause (sigh of relief). Surprisingly, it looks like we are indeed dealing with either two bugs or three. The three case: 1. Explorer fails to access the file, though it should work. 2. cmd.exe fails to access the file, though it should work. 3. Either java.io ditto, or something wrong with interop. The two case: 1. Some bug allows the OS APIs to write a file that exceeds the limit you discussed. 2. Some other bug prevents Microsoft's remedy for that limit being exceeded from working in cmd.exe, without preventing it from working when implemented via java.io. Of course, the second case seems less likely despite having fewer apparent separate failures, because bug 1 in particular seems less likely, and because in the first case bugs 1 and 2 might not really be separate, if Explorer and cmd.exe share code. -- 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
