You could use ProcessBuilder or Runtime to execute the ls command and capture the results. Of course, this is a HUGE security hole, letting someone browse your server's file system. I caution against it. If you want to proceed, make sure you limit what directories can be examined in both the code and the server policy.
Assuming that your remote files are available via a remote filesystem mount (such as Samba, NFS, GFS or whatever), you can use the java.io.File package to enumerate the list of files. It's fairly easy to create a JSP that will display the list.
Since java.io.File is OS-independent, that won't give you the non-portable file attributes, but if all you want is the file name, size, and whether it's a directory, that's enough.
An IDE is no substitute for an Intelligent Developer.
Unless of course you're really asking if you can display the contents of only one or two chosen directories: in which case you could find a way to export only those from the background server (e.g. using another Web server, mini-Perl script, Java or C app.).
Or you could use SSH into the server, then execute the ls command. As long as you use PKC authentication, this is more secure than a regular user using a password to login. Also you'd want to create a new user on the background server, and only give it limited access (i.e. ensure correct permissions are used, and only give the user limited, if any, root-level commands via sudo). Provided your Web server isn't compromised, this is perfectly secure. Even if it is compromised, the damage is limited only to the commands the new user can run on your background server, and if limited to listing directory contents only, not much harm can happen.
Charles Lyons (SCJP 1.4, April 2003; SCJP 5, Dec 2006; SCWCD 1.4b, April 2004)
Author of OCEJWCD Study Companion for Oracle Exam 1Z0-899 (ISBN 0955160340 / AmazonAmazon UK )
As Pat noted, there are security issues here. I prefer using java.io.File over any of the ssh-type mechanisms for 2 reasons:
1. The overhead for gathering metadata about mounter files is less than the overhead for logging in to a remote server, loading and running an app and parsing the results.
2. You can't run random programs or do other common exploits on the target machine over a filesystem interface the way you can with a general remote command execution environment.
You're also limiting your security exposure somewhat, since the only files you'll be able to snoop are those that the mounted filesystem has access rights to. That's not total protection, since those rights would be applied under the security scope of the appserver, which typically has fairly broad rights. But it's better than many of the alternatives.
Originally posted by Charles Lyons: Or you could use SSH into the server, then execute the ls command. As long as you use PKC authentication, this is more secure than a regular user using a password to login.
As if I could trust say you, Charles, to only do an 'ls' command and not something else. Again, not on a system that I administer.
Web users get to run applications that my developers write, after they have been through QA.
Joined: Mar 27, 2003
As if I could trust say you ... not something else.
Clearly you haven't heard of SSH forced commands...