NoSuchFileException in windows

[Esteban Estupinan]

Hi everyone, I am trying to execute a small code that is on page 804 of the OCP Java 17 book on the topic "Retrieving the Real File System Path".

When I run the code it seems that java cannot find the "/zebra/food.txt" directory in Windows file explorer.

I have created the horse folder in the root of the C drive that contains two elements: a schedule folder that contains my compiled class, and a food.txt text file
I also have the symbolic link called zebra in the root of C drive. I m using Windows 11 and Visual Studio Code

Please could you tell me where the error is and how I can correct it?

import java.io.IOException;
import java.nio.file.Paths;

public class Clase {
    public static void main(String[] args) throws IOException {
        System.out.println(Paths.get("/zebra/food.txt").toRealPath()); //* !!!
        System.out.println(Paths.get(".././food.txt").toRealPath()); //* !!!
    }
}

[snow Atlas]

Hi,
i think this code is for linux, for windows t think t'm not sure  you should use.
System.out.println(Paths.get("C:\\Users\\zebra\\food.txt").toRealPath());

[Rob Spoor]

On Windows you can still use /. Those get turned into \ for you. Paths.get("/zebra/food.txt") will refer to file <drive>:\zebra\food.txt, where <drive> is the drive of the current directory. Paths.get(".././food.txt") will refer to file <current directory>\..\.\food.txt.

Esteban, you can check the result of Paths.get("/zebra/food.txt").toAbsolutePath().normalize() and Paths.get(".././food.txt").toAbsolutePath().normalize() to see what files they actually refer to. You can see what the current directory is using Paths.get(".").toAbsolutePath().normalize().

[Esteban Estupinan]

The absolute paths that these strings represent have been printed. What I don't understand is that using the exists method of Files confirms that these directories or files do not exist, even though I do have them in the root of the C drive. Why is this supposed contradiction generated?

import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.Path;
import java.nio.file.Paths;

public class Clase {
    public static void main(String[] args) throws IOException {
        // System.out.println(Paths.get("/zebra/food.txt").toRealPath()); //* !!!
        // System.out.println(Paths.get(".././food.txt").toRealPath()); //* !!!
        System.out.println(Paths.get("/horse/food.txt").toAbsolutePath().normalize());
        System.out.println (Paths.get(".././food.txt").toAbsolutePath().normalize());
        Path ruta1 = Paths.get("/horse/food.txt").toAbsolutePath().normalize();
        System.out.println(Files.exists(ruta1));

        Path ruta2 = Paths.get(".././food.txt").toAbsolutePath().normalize();
        System.out.println(Files.exists(ruta2));
    }
}

[Paul Clapham]

I think it would be interesting to see what the "notExists" method produces. (From the documentation: "Note that this method is not the complement of the exists method.")

[Esteban Estupinan]

I have used notExists and it prints true twice. Confirm that the directories do not exist.

[Paul Clapham]

Besides the concept of "current directory", Windows also has the concept of "current drive". If you're working at the command line you could change the current drive to the D drive by simply entering the command "D:".

So going on the theory that the current drive is undefined when you run that code, try using "C:/horse/food.txt" and so on, see what happens.

[Esteban Estupinan]

Sadly is the same

[Paul Clapham]

I personally wouldn't care too much about those messages. I would care if I wrote some code to read a file and was told it didn't exist, though. Try that.

[Esteban Estupinan]

I detected something, when I just pass the directory, it does recognize me but when I pass the food.txt file it doesn't.

import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.Path;
import java.nio.file.Paths;

public class Clase {
    public static void main(String[] args) throws IOException {
        // System.out.println(Paths.get("/zebra/food.txt").toRealPath()); //* !!!
        // System.out.println(Paths.get(".././food.txt").toRealPath()); //* !!!
        System.out.println(Paths.get("/horse").toAbsolutePath().normalize());
        System.out.println (Paths.get(".././food.txt").toAbsolutePath().normalize());
        Path ruta1 = Paths.get("/horse").toAbsolutePath().normalize();
        System.out.println(Files.exists(ruta1));
        Path ruta2 = Paths.get(".././food.txt").toAbsolutePath().normalize();
        System.out.println(Files.exists(ruta2));
    }
}

here exists is true but if i write /horse/food.txt it prints false. I think that this detail is the beginning of the problem.

[Paul Clapham]

You know that ".././food.txt" is a relative path, relative to your current working directory, right? You can see that in your original post with your screenshot. As it stands now, after reading the last few posts I'm getting lost and I don't know what's working and what isn't.

[Carey Brown]

In your screen snapshot the path starts with "first:". What is that? Is that specific to Visual Studio?

What is the absolute path to your symbolic link (shortcut)? What path does the link refer to?

[Ron McLeod]

Carey Brown wrote:In your screen snapshot the path starts with "first:". What is that? Is that specific to Visual Studio?

It is an inlay hint where the IDE adds some information inline such as parameter name or type.  I've seen it in VSCode and Intellij.

first is the name of the first parameter in Paths#get​(String first, String... more)

[Ron McLeod]

Is this the structure of the folders and files that you are working with?
C:. | \---zebra |   |   food.txt |   | |   \---schedule | \---horse    |   food.txt    |    \---schedule

[Ron McLeod]

Maybe add this to your code so that it is clear which drive and folder your application is working from:

System.out.println("Working location: " + System.getProperty("user.dir"));

[Ron McLeod]

I am trying to reproduce what you did using what I understand to be the setup that you used in your first post.

The code is like this:

import java.io.IOException;
import java.nio.file.Paths;
 
public class Clase {
    public static void main(String[] args) throws IOException {
        System.out.println("Working location: " + System.getProperty("user.dir"));
        System.out.println(Paths.get("/zebra/food.txt").toRealPath());
        System.out.println(Paths.get(".././food.txt").toRealPath());
    }
}

The files are organized like this:C:. | \---zebra |   |   food.txt |   | |   \---schedule \---horse    |   food.txt    |    \---schedule            Clase.java
The code is complied from the C:\horse\schedule folder:
C:\horse\schedule>java Clase
The complied application is then from the C:\horse\schedule folder:
C:\horse\schedule>java Clase Working location: C:\horse\schedule C:\zebra\food.txt C:\horse\food.txt
Are you doing something different?

[Tim Holloway]

If you ever need to know what your JVM's current working directory is:

        System.out.println(Paths.get(".").toRealPath());

Old-style using java.io.File:

           System.out.println((new File(".")).getAbsolutePath());

Current/working directory is a treacherous thing on the whole since if the app is running multiple threads (for example, as a webapp server), then one thread might change directories and confuse other threads, since current-directory is a JVM-wide, not per-thread.

And, of course, there's what Paul said. In Windows, you can have one "current directory" per drive and the "working directory" depends on which drive you have currently logged to. The Unix-like OS's don't have that concept.

[Esteban Estupinan]

I already know what the mistake was. In the image capture-3.png the food file has a double extension. It appears in my file explorer as food.txt, but the file is actually called food.txt.txt. That's why when running the program from schedule/horse, even though the zebra link and everything else was fine, food.txt.txt was never going to be found by java and the file not found exception was thrown. I hope this experience helps someone who has a similar problem.

Thank you very much for your help and time. I find those file location schemes in the file explorer useful. Maybe they do it with a shortcut like ```java to insert code or something similar?

[Paul Clapham]

Esteban Estupinan wrote:It appears in my file explorer as food.txt, but the file is actually called food.txt.txt.

Argh. One of Windows's more stupid defaults. It's supposed to help people by automatically appending suitable suffixes to files based on what type of file they are - for example having Adobe append ".pdf" to files that they output - and then to hide that action from the user. So when you have Adobe save "arrrghhh.pdf" to a directory, you only see "arrrghhh" in Windows Explorer. That's fine for casual users but definitely NOT fine for programmers. But you can turn that setting off somewhere in Explorer, I strongly advise doing that.

[Tim Holloway]

Paul Clapham wrote:

Esteban Estupinan wrote:It appears in my file explorer as food.txt, but the file is actually called food.txt.txt.

Argh. One of Windows's more stupid defaults. It's supposed to help people by automatically appending suitable suffixes to files based on what type of file they are - for example having Adobe append ".pdf" to files that they output - and then to hide that action from the user. So when you have Adobe save "arrrghhh.pdf" to a directory, you only see "arrrghhh" in Windows Explorer. That's fine for casual users but definitely NOT fine for programmers. But you can turn that setting off somewhere in Explorer, I strongly advise doing that.

Yeah. This comes from Macintosh Envy.

The original Macintosh computer had two 4-character fields in its file directory entries. I forget their exact names, but one served essentially the same purpose as file extensions do on Windows and Unix-like OS's. Except that they were invisible unless you opened up a file details dialog on the file. They weren't actually part of the filename itself, but meta-data about the file.

So Microsoft, hoping to look cool, did something intended to resemble that by hacking the UI filename displays.

One of the first things I do when an Windows computer is inflicted on me is turn that feature off. As noted, it's more trouble than it is worth,

[Rob Spoor]

That feature was heavily abused for email viruses. One of the best examples: Anna Kournikova (computer virus). The actual file name was AnnaKournikova.jpg.vbs but Outlook didn't display the actual extension, so it looked like an image file.