如何检查文件/目录是否是受保护的操作系统文件？

Question

I'm working on a project which, in part, displays all the files in a directory in a JTable, including sub-directories. Users can double-click the sub-directories to update the table with that new directory's content. However, I've run into a problem.

My lists of files are generated with file.listFiles(), which pulls up everything: hidden files, locked files, OS files, the whole kit and caboodle, and I don't have access to all of them. For example, I don't have permission to read/write in "C:\\Users\\user\\Cookies\\" or "C:\\ProgramData\\ApplicationData\\". That's ok though, this isn't a question about getting access to these. Instead, I don't want the program to display a directory it can't open. However, the directories I don't have access to and the directories I do are behaving almost exactly the same, which is making it very difficult to filter them out.

The only difference in behavior I've found is if I call listFiles() on a locked directory, it returns null. Here's the block of code I'm using as a filter:

for(File file : folder.listFiles())
    if(!(file.isDirectory() && file.listFiles() == null))
        strings.add(file.getName());

Where 'folder' is the directory I'm looking inside and 'strings' is a list of names of the files in that directory. The idea is a file only gets loaded into the list if it's a file or directory I'm allowed to edit. The filtering aspect works, but there are some directories which contain hundreds of sub-directories, each of which contains hundreds more files, and since listFiles() is O(n), this isn't a feasible solution (list() isn't any better either).

However, file.isHidden() returns false

canWrite()/canRead()/canExecute() return true

getPath() returns the same as getAbsolutePath() and getCanonicalPath()

createNewFile() returns false for everything, even directories I know are ok. Plus, that's a solution I'd really like to avoid even if that worked.

Is there some method or implementation I just don't know to help me see if this directory is accessible without needing to parse through all of its contents?

(I'm running Windows 7 Professional and I'm using Eclipse Mars 4.5.2, and all instances of File are java.io.File).

Answer 1

The problem you have is that you are dealing with File . By all accounts, in 2016, and, in fact, since 2011 (when Java 7 came out), it has been superseded by JSR 203.

Now, what is JSR 203? It is a totally new API to deal with anything file systems and file system objects; and it extend the definition of a "file system" to include what you find on your local machine (the so called "default filesystem" by the JDK) and other file systems which you may use.

Sample page on how to use it: here

Among the many advantages of this API is that it grants access to metadata which you could not access before; for instance, you specifically mention the case, in a comment, that you want to know which files Windows considers as "system files".

This is how you can do it:

// get the path
final Path path = Paths.get(...);
// get the attributes
final DosAttributes attrs = Files.readAttributes(path, DosFileAttributes.class);
// Is this file a "system file"?
final boolean isSystem = attrs.isSystem();

---

Now, what is Paths.get() ? As mentioned previously, the API gives you access to more than one filesystem at a time; a class called FileSystems gives access to all file systems visible by the JDK (including creating new filesystems), and the default file system, which always exists, is given by FileSystems.getDefault() .

A FileSystem instance also gives you access to a Path using FileSystem#getPath .

Combine this and you get that those two are equivalent:

Paths.get(a, b, ...)
FileSystems.getDefault().getPath(a, b, ...)

---

About exceptions: File handles them very poorly. Just two examples:

• File#createNewFile will return false if the file cannot be created;
• File#listFiles will return null if the contents of the directory pointed by the File object cannot be read for whatever reason.

JSR 203 has none of these drawbacks, and does even more. Let us take the two equivalent methods:

• File#createNewFile becomes Files#createFile ;
• File#listFiles becomes either of Files#newDirectoryStream (or derivatives; see javadoc) or (since Java 8) Files#list .

These methods, and others, have a fundamental difference in behaviour: in the event of a failure, they will throw an exception.

And what is more, you can differentiate what exception this is:

• if it is a FileSystemException or derivative, the error is at the filesystem level (for instance, "access denied" is an AccessDeniedException );
• if is is an IOException , then the problem is more fundamental.

---

This answer cannot contain each and every use case of JSR 203; this API is vast, very complete, although not without flaws, but it is infinitely better than what File has to offer in any case.

Answer 2

I faced the very same problem with paths like C://users/myuser/cookies .

I already used JSR203, so the above answer kind of didn't help me. In my case the important attribute of those files was the hidden one.

I ended up using the FileSystemview, which excluded those files as I wanted.

File[] files = FileSystemView.getFileSystemView().getFiles(new File(strHomeDirectory), !showHidden);