I have a Java program that is supplied a directory name, gets a list of all the file in that directory using dirName.listFiles() and then iterates through every file parsing information from them.
The files would normally all just be normal text files, but I am using SVN and there seems to be a directory called .svn in my dirName directory which is causing my program to fail because .svn is a directory and not a text file.
Now, I could implement filters using a FileFilter object, but I would really only expect text files to be in that directory in the final program.
My question is: Is there a way round my issue without using a FileFilter? I also think that my program is ignoring the .svn directory in other programs that I've written, so I'm not sure why it's an issue now.
Thanks in advance.
You would have this issue with many version control systems (not just SVN) as some of them have files on disk that help identify where the working copy comes from (.svn for SVN, view.dat for clearcase). You really should just implement a FileFilter to exclude those, or use the ones from commons-io:
makeSvnAware
It's null safe, so if you give it null input, it simply returns an svn filter for you. If you give it another IOFileFilter (a subinterface of FileFilter) it simply returns one that does an AND between the existing filter and the svn filter.
FileFilter svnFilter = FileFilterUtils.makeSvnAware(null);
You could call isDirectory() on each object that listFiles() returns.
Two possible soulutions (at least):
FileFilter or FileNameFilter
isFile()
Look here: http://docs.oracle.com/javase/6/docs/api/java/io/File.html
Better than using java for file and directory search, i would prefer writing a jni program and use C's dirent.h and stat.h to differentiate between files. The jni program would be much faster.
If dirName is not the root directory of your working copy, you can upgrade to the latest version of svn. This doesn't have an .svn directory for every directory but only for the root.
Related
I'm making a file import system, and I can't move files into the compiled .jar file the application is in.
Here's what I'm trying to do:
Path FROM = Paths.get(filePath.getText());
Path TO = Paths.get("C:\\Users\\" + System.getProperty("user.name") +
"\\AppData\\Roaming\\.minecraft\\mods\\music_crafter-1.0\\src\\main\\resources\\assets\\music_crafter\\sounds\\block\\music_player");
//jar file
Files.move(FROM, TO.resolve(FROM.getFileName()), StandardCopyOption.REPLACE_EXISTING);
You need to handle the jar file internally. A Jar is not a directory, it is a compressed container file (pretty much a ZIP file with a different extension).
To do this, given that you are on Java 6, you have 2 options:
Unzip the contents to a temporary working directory (there are built
in APIs for this, or use a library such as Apache Commons Compress)
do your work (copying, deleting, etc) and then re-zip.
Make external command line calls to the Jar utilities that come with
Java
Of those, only (1) makes any real sense.
A third option would be available if you could up your Java to 7+ which would be:
3. Use a Zip File System Provider to to treat it as a file system in code
All that said, however:
As per comments on your question, you really might want to look at if this something you need to do at all? Why do you need to insert into existing jars? If this is 'external' data, it would be much better in a separate resource location/container, not the application jar.
I need to move the files from one HDFS directory to another HDFS directory.
I wanted to check if there's some easier way (some HDFS API) to achieve the same task, other than InputStream/OutputStream ?
I've heard of FileSystem.rename(srcDir, destDir); but is unsure if this will delete the original src directory.
I don't want to remove the original directory structure, only move the files from one folder to another directory.
e.g
input Dir - /testHDFS/input/*.txt
dest Dir - /testHDFS/destination
After moving the files, directory should look something like this :-
input Dir - /testHDFS/input
dest Dir - /testHDFS/destination/*.txt
PS : I want to achieve this working inside mapper function for each file.
Any help would be appreciated.
FileSystem.rename will move the file from source to destination directory. I believe you can use it for your requirement.
The best way to do this is with org.apache.hadoop.fs.FileUtil.copy(), setting the deleteSource parameter to true. People commonly use FileSystem.rename(), but that function will fail silently for invisible issues (such as the source and destination Paths being on different volumes)
You can use DistCp programmatically verify this
How can I check that I can delete a file in Java?
For example, I should be able to delete file C:/file.txt but I never will be able to delete the C:/ or Computer, or My Documents etc.
Solution described in possible duplicate does not work for me.
Removing file requires write permission of the file's parent, i.e. directory where file is stored. Directory in java is also represented by instance of class java.io.File that has method canWrite().
So, to check whether file can be deleted you should call file.getParent().canWrite().
On my Windows 7 64 bit box using NTFS and Java 7 (Oracle JDK), the only thing which worked for me reliably is
boolean canDelete = file.renameTo(file)
This is surprisingly simple and works also for folders, which have "somewhere below" an "open" or "locked" file.
Other things I tried and produced false-positives: aquire a FileLock, File#canWrite, File#setLastModified ("touch"), file.getParent().canWrite()
My Java program references a lot of data files. I put them in a top level directory called data/, along with src/ and bin/. In Eclipse, references to data/ and ../data/ both seem to work. When I run it from the command line, only ../data/ works.
When I put the bin/ and data/ directories in a jar and correctly set the entry point, it doesn't seem to know that I want it to access the data/ directory inside the jar. The only way I've been able to get it to work is by setting the references to ../data/ and placing the jar in the bin directory. This obviously doesn't do me any good, because it's not self-contained.
What do I need to do to the references to make them work?
Thanks
I'd recommend you access the files in a classpath-relative way, whether in Eclipse or in a compiled JAR.
There are a few ways you might go about it, but a basic JDK-only approach would be to use Class's getResourceAsStream() method, giving you access to an InputStream object that you can read in.
If your resources are in a jar file, consider using this method to read them:
class Class {
InputStream getResourceAsStream(String name)
}
This looks for the resource relative to a class (which may be in a jar), rather than relative to the working directory.
Thanks for pointing me down this path, guys. I ended up doing a really hacked up workaround because I'm not very good with IO yet. I used getClass() to construct a URL:
http://forums.sun.com/thread.jspa?threadID=5258488
Then made a new File object from this string (new File(file)):
String file = url.toString().replaceFirst("file:", "");
This allowed me to keep the same code that referenced the file objects.
I've never seen that,internally generated?How does it work?
Can check what I meen here:
http://issues.apache.org/jira/secure/attachment/12401970/nutch_0.9_OR.patch
search "java~"
and you can see "java.old" there,what's that again?
It's probably some cruft leftover from emacs. With emacs, whenever you save a file, it saves a backup of the previous version of the file, and the backup is named with the original filename with a tilde appended to it. If this is the case (which you can easily verify by comparing file with file~), then you can safely ignore all of the files named with tildes.
Are you sure its generated from some java process? ~ in files typically means a temporary file created by editors, such as vim when you modify something.