Java question (regarding java.io.File class)

In a program I am writing, I am wanting to look at the contents of the current directory (that is, the directory in which my .class files reside) and get, for example, a list of all the image files in the directory. I am trying to achieve this via the java.io.File class (particularly the list() method of the class).

The problem I am having is this, though: an exception is being thrown because I don’t have the proper permissions (i.e. read access) for this particular directory. Now, I can understand how this can be possible… but according to the Java Documentation (look under the entry for FilePermission) the application/applet has read access to all files in the same directory as the .class file, by default.

So… is the documentation incorrect with this “assumption”, or am I just completely missing something? (I figured I would try to find answers here, before I write a java policy file or something).

Much thanks to anyone who can offer any ideas. :slight_smile:

LilShieste

Could you post the section of code where you’re accessing the the files? Are you sure you’re really only asking for read-only access? Have you tried giving yourself all permissions just to verify it’s really a permissions problem? (and not a mis-reported concurrency violation).

OS? I know I had trouble in the Windows world with “folders”.

DarrenS:

Here is the code that is causing the problem:


.
.
File myFile = new File("."); // Creates an instance of File,
                                // as the current directory
String[] fileList = myFile.list(); // returns an array of filenames (strings)

The problem really is with the second line of code. Creating an instance of the File object poses no problems

Actually… no, I haven’t. I think I will go ahead and try that, and see if the exception still gets thrown.

ccwaterback:

Yeah, I’m trying to view this using IE6. That might be a problem as well.

Thanks for the responses,

LilShieste

ACK! Sorry about the formatting there… I forgot about that kinda stuff happening…

:smack:

I just finished a similar project. Mine is a raw executable and not an applet. Code at end of my post.

The first thing to do when having trouble with applets is to turn any security on the browser off and test with IE and a Mozilla based browser (Opera, Mozilla, Gecko, Netscape), you should also be able to run the applet from within you developer (Jbuilder, J++) or from the command line.

path is a string in the form of “c://directory//directory//”



public String[] GenerateFileList()
  {
    //string array to hold the file list
    String output[] = new String[100];
    //a File to hold the directory contents
    File lister = new File(path);
    //File.list() returns a string array with all the files in a path
    output = lister.list();
  }


Almost forgot. After turning security off, slowly bump it back up to at least ‘medium’ before releasing your applet. If this is going on a busy webpage go as far as you can without actually turning java support off.

Almost forgot. After turning security off, slowly bump it back up to at least ‘medium’ before releasing your applet. If this is going on a busy webpage go as far as you can without actually turning java support off.

Oh I also know that the code snippet here is not well formatted code and I’m missing a return. The rest of the function does other stuff with the string array before returning it.

Almost forgot. After turning security off, slowly bump it back up to at least ‘medium’ before releasing your applet. If this is going on a busy webpage go as far as you can without actually turning java support off.

Oh I also know that the code snippet here is not well formatted code and I’m missing a return. The rest of the function does other stuff with the string array before returning it.

LilShieste - please post the solution if you find it - I’m curious now.

One thing you might want to do is call getAbsolutePath on your File object - it’s idea of “.” may not be the same as yours. You may be trying to access a totally different directory than you think. Another thing to try is hard-coding the directory rather than using “.” - if this works, you know you have a problem with using “.”.