Actually, I would think it is a bug to assume that "c:/temp" is a full path if the OS is UNIX. In fact that is a quite valid local specification for a UNIX file.
I wish we could refactor this code in some sort of factory created object that isolates the checks based on the specifics of the file system. What it really bothers me is that all this things were supposed to be managed correctly by fuctions in the JVM and I do not understand why they do not do the job. Jose Alberto ----- Original Message ----- From: "Jeff Tulley" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, October 11, 2001 9:24 PM Subject: disregard my FileUtils patch I have found some problems with my FileUtils patch, namely: - it is not up to spec - it does not upper case the NetWare volume name. I must have missed that part of the spec - There are other problems with some border cases that have come out as I have added NetWare specific test cases in FileUtilsTest.java I'll get these fixed. Now, I'm wondering about some basic functionality here that I might be misunderstanding. Are resolveFile and normalize supposed to be able to handle all three types of file system names, "/usr/bin", "c:\temp", and "sys:/tmp" while executing on any given system, or is it ok for "sys:/tmp" to be handled only when executing on NetWare, or "c:\temp" to be handled when executing on Windows, etc? If I need to handle everything on every system, then I'll have to refactor resolveFile and normalize a whole lot more. The going assumption used to be that if it contained a ":" as the second character, that was automatically a windows path. Things get a little more complicated for general support if that colon can move to later in the string and still represent a valid "drive" name.(really, a NetWare volume). Jeff Tulley ([EMAIL PROTECTED]) (801)861-5322 Novell, Inc., the leading provider of Net services software.
