Различное поведение для Path.toFile () и нового файла (pathString) - PullRequest
Новая
       42

Различное поведение для Path.toFile () и нового файла (pathString)

0 голосов
/ 27 апреля 2018

Я подключил сетевой диск (сервер samba) в Windows.

У меня на диске есть файл, который я хотел прочитать в программе на Java.

Прежде чем я пытался прочитать файл, используя: 

Paths.get(basePath, fileName).toFile()

Но произошла ошибка из-за того, что файл не существует. Файл был там, и путь был хорош.

Затем я попробовал следующий код, который работал: 

String path = Paths.get(basePath, fileName).toAbsolutePath().toString()
File file = new File(path)

Есть ли разница между обоими подходами? Требуются ли какие-либо настройки безопасности?

Обновление

Так что после того, как я использовал вторую часть (ту, которая работала), я вернулся к первоначальной (как это было) проверке отладки, и на этот раз она работала. Я попробовал это с другим файлом в том же каталоге, и это не удалось. Это кажется странным, но я проверю больше.

Ответы [ 2 ]

0 голосов
/ 27 апреля 2018

Чтобы лучше понять, что, возможно, происходит, я бы порекомендовал отладку кода Ниже я объясню, в чем может быть проблема, основываясь на моем понимании исходного кода.

Прежде всего, существуют различные реализации Path, и, как вы упомянули, вы работаете в Windows, поэтому я взглянул на исходный код WindowsPath, который я нашел здесь .

Так что метод Path.toFile() довольно прост. Это: 

public final File toFile() {
    return new File(this.toString());
}

this относится к экземпляру реализации Path, а в случае Windows это реализация WindowsPath.

Глядя на класс WindowsPath, мы видим, что toString() реализован следующим образом: 

@Override
public String toString() {
    return path;
}

Теперь посмотрим, как создается эта переменная path. Класс WindowsPath вызывает класс WindowsPathParser, который строит путь. Источник для WindowsPathParser можно найти здесь .

В методе parse в WindowsPathParser вам нужно отладить, чтобы точно узнать, что происходит. В зависимости от вашего начального path, который вы передаете в качестве параметра метода, этот метод анализирует его как другой WindowsPathType, например. ABSOLUTE, DIRECTORY_RELATIVE.

Приведенный ниже код показывает, как начальный вход path может изменить тип WindowsPathType

Код 

private static final String OUTPUT = "Path to [%s] is [%s]";

public static void main(String args[]) throws NoSuchFieldException, IllegalAccessException {
    printPathInformation("c:\\dev\\code");
    printPathInformation("\\c\\dev\\code");
}

private static void printPathInformation(String path) throws NoSuchFieldException, IllegalAccessException {
    Path windowsPath = Paths.get(path);

    Object type = getWindowsPathType(windowsPath);

    System.out.println(String.format(OUTPUT,path, type));
}

private static Object getWindowsPathType(Path path) throws NoSuchFieldException, IllegalAccessException {
    Field type = path.getClass().getDeclaredField("type");

    type.setAccessible(true);

    return type.get(path);
}

выход 

Path to [c:\dev\code] is [ABSOLUTE]
Path to [\c\dev\code] is [DIRECTORY_RELATIVE]
0 голосов
/ 27 апреля 2018

Я бы проверил ваши пути к файлам и, возможно, импортировал, потому что это работало нормально для меня, также я не уверен, почему вы разбили свой путь, но, возможно, говорили о 2 разных путях импорта 

System.out.println("File:"+new File(path).exists());
System.out.println("Path:"+Paths.get(path).toFile().exists());

Мой импорт, если вы хотите сравнить 

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

Я бы сказал, дайте ему шанс с полным путём, не разбитым вообще, посмотрите, что изменится

...