We Keep Coding

Why can't I find the file with normalized path on windows system?

I want to check if a file exists by its filepath using java. I know there is a method in Paths class called normalized(). Here is my code:
File file = Paths.get(fileName).normalize().toFile();
if (!file.exists()) {
return "File does not exist.";
}
The filename is a file path with sysmbols of current directory like "."or".."
After the path is normalized, it just delete the dots of the path and windows can't find the new path with out dots. But the code above works fine on other systems. I wonder why and what should I do if I want to check if a path with dots exists or not?

Why are switching from the Paths API to the file API?
use: Files.exists(Paths.get(fileName).normalize());
As the docs says, normalize removes /./ constructs, as well as X/../ constructs. This can nevertheless result in slightly different intended files in case of weird softlink constructions, which, yes, even on windows, is a thing you can do. It may be related to that. Give us the path pre- and post normalization (just sysout it) and we can perhaps give you some more details on this.
Generally you don't want normalize. Depending on situation you either just want the path as is, or, (in case you need to store it for later, check it against certain filters, or render it to the user), path.toAbsolutePath().

When to use deleteOnExit and not delete?

First of all I am not asking for difference between the two. I am wondering what will be a scenario where one will choose to use deleteOnExit() over delete().

Sometimes we may want to create temporary files to save some data that gets written by an application or to temporarily store some data for use in the near future by this same application, etc. etc. In these scenarios, we may do something like this:
File tempFile = File.createTempFile(...);
tempFile.deleteOnExit();
.... // the rest of the code

deleteOnExit would be appropriate for temporary files you'd like to be cleaned up on exit

Saving to a folder

I'm writing an application that is writing to a file. I'm wondering if it's possible to write to a folder, without specifying a file name. The way I have it set up now, my program will overwrite the previous saved file. I'm looking to have it add to the folder rather than replace.
Here's the line in question:
File testFile = new File("C:/TargetFolder/testFile.png");

There is no way to write to a file without assigning a file name. However, if you don't want to chose a file name you can have your system generate a random one. For example look at these options: What is the best way to generate a unique and short file name in Java.
Another option would be to add numbers to your file name like: test01.png, test02.png and so on.

If you don't want to do the unique file in the folder logic yourself and you don't care much about the exact name, you might use:
java.io.File.createTempFile("testFile", ".png", new File("C:/TargetFolder"));

Saving a video file by increamenting file name in a loop

I want to save a video file in C:\ by incrementing the file name e.g. video001.avi video002.avi video003.avi etc. i want to do this in java. The program is on
Problem in java programming on windows7 (working well in windows xp)
How do i increment the file name so that it saves without replacing the older file.

Using the File.createNewFile() you can atomically create a file and determine whether or not the current thread indeed created the file, the return value of that method is a boolean that will let you know whether or not a new file was created or not. Simply checking whether or not a file exists before you create it will help but will not guarantee that when you create and write to the file that the current thread created it.

You have two options:
just increment a counter, and rely on the fact that you're the only running process writing these files (and none exist already). So you don't need to check for clashes. This is (obviously) prone to error.
Use the File object (or Apache Commons FileUtils) to get the list of files, then increment a counter and determine if the corresponding file exists. If not, then write to it and exit. This is a brute force approach, but unless you're writing thousands of files, is quite acceptable performance-wise.

Why I get an Exception on opening an empty ZIP-file with java.util.zip.ZipFile?

I want to open a ZIP-file, that have no entries with java.util.zip.ZipFile. But on the constructor I get the following exception: 'java.util.zip.ZipException: error in opening zip file'. How can I open the empty ZIP?
That ZIP-file is created by the commandline zip-program under linux. I simply deleted all entries from a ZIP-file.
I need this as testdata for a class I write. The class should simply return an empty list for this case, but broken ZIP-files should return an error.
For some more explanation on the problem. I have an interface, for extracting some documents from different sources. Other implementations gather them from webservices or directories, this implementation from ZIP-files. The interface give an Iterator with some more functionality. So I want to decide, if the ZIP-file is empty or broken.

hack: you can assume that all empty ZIPs are the same and just hardcode it's length/chechsum to validate against.

I don't know why is it implemented this way, but why do you need to succesfully open an empty Zip file? You can't modify it with java.util.zip.ZipFile anyway...
So you can just catch the ZipException (which is thrown for invalid format zip files), and skip the file if you catch it.

My solution for this problem is now, that I simply use ZipInputStream instead of ZipFile. This class works well with empty ZIP-files. I don't know about the reason, why one works and the other not.

I think the reason ZipInputStream works and ZipFile does not is because of the two different ways that zip files are read. The ZipFile constructor attempts to read the ZipFile's table of contents, which is written to the end of the file. If it can't read the TOC, it throws a ZipException (with almost no helpful info contained therein), which I think is what you're seeing. ZipInputStream, however, reads the entries out of the zip file sequentially starting at the beginning of the file, so it seems more robust in this case.
This is all very poorly documented and I've run into similar problems myself using ZipFile. Both methods of reading from a zip file are valid, but you'd think the API docs would mention the implications of the random access/TOC method of reading through constructor versus reading through a ZipInputStream.

Are you sure it is a valid zip file? That would be my first guess.

The ZIP file format has errors check the JDK here.

Use a ZipOutputStream.