Are there cases where File.getCanonicalPath() and File.toPath().toRealPath() will produce different results?
They seem to do both rather similar things but the documentation never atually states that they are supposed to do the same thing.
Are there border cases where I would to prefer one method over the other?
And how about File.getAbsolutePath() versus Path.toAbsolutePath() - are they supposed to work in the same way?
Conclusions:
getAbsolutePath and getPath never fail as they don't do validation
getCanonicalPath reach invalid results when drive letter from url is invalid or different than the current folder
toPath().toRealPath() is checking the validity but the file needs to exist and can also follow or not follow symbolic links
toPath() is safe enough and doesn't need the file to exist.
.toPath().toAbsolutePath().normalize() is the best one without the need for file to exist
I did a similar test of #John in windows
#Test
public void testCanonical() throws IOException {
test("d:tarGet\\..\\Target", "File exist and drive letter is on the current one");
test("d:tarGet\\..\\Target\\.\\..\\", "File exist and drive letter is on the current one, but parent of current drive should exist");
test("d:tarGet\\non-existent\\..\\..\\Target\\.\\..\\", "Relative path contains non-existent file");
test("d:target\\\\file", "Double slash");
test("c:tarGet\\..\\Target\\.", "File doesn't exist and drive letter is on different drive than the current one");
test("l:tarGet\\..\\Target\\.\\..\\", "Drive letter doesn't exist");
test("za:tarGet\\..\\Target\\.\\..\\", "Drive letter is double so not valid");
test("d:tarGet|Suffix", "Path contains invalid chars in windows (|)");
test("d:tarGet\u0000Suffix", "Path contains invalid chars in both linux and windows (\\0)");
}
private void test(String filename, String message) throws IOException {
java.io.File file = new java.io.File(filename);
System.out.println("Use: " + filename + " -> " + message);
System.out.println("F-GET: " + Try.of(() -> file.getPath()));
System.out.println("F-ABS: " + Try.of(() -> file.getAbsolutePath()));
System.out.println("F-CAN: " + Try.of(() -> file.getCanonicalPath()));
System.out.println("P-TO: " + Try.of(() -> file.toPath()));
System.out.println("P-ABS: " + Try.of(() -> file.toPath().toAbsolutePath()));
System.out.println("P-NOR: " + Try.of(() -> file.toPath().normalize()));
System.out.println("P-NOR-ABS: " + Try.of(() -> file.toPath().normalize().toAbsolutePath()));
System.out.println("P-ABS-NOR: " + Try.of(() -> file.toPath().toAbsolutePath().normalize()));
System.out.println("P-REAL: " + Try.of(() -> file.toPath().toRealPath()));
System.out.println("");
}
The results are:
Use: d:tarGet\..\Target -> File exist and drive letter is on the current one
F-GET: Success(d:tarGet\..\Target)
F-ABS: Success(d:\home\raiser\work\restfs\tarGet\..\Target)
F-CAN: Success(D:\home\raiser\work\restfs\target)
P-TO: Success(d:tarGet\..\Target)
P-ABS: Success(D:\home\raiser\work\restfs\tarGet\..\Target)
P-NOR: Success(d:Target)
P-NOR-ABS: Success(D:\home\raiser\work\restfs\Target)
P-ABS-NOR: Success(D:\home\raiser\work\restfs\Target)
P-REAL: Success(D:\home\raiser\work\restfs\target)
Use: d:tarGet\..\Target\.\..\ -> File exist and drive letter is on the current one, but parent of current drive should exist
F-GET: Success(d:tarGet\..\Target\.\..)
F-ABS: Success(d:\home\raiser\work\restfs\tarGet\..\Target\.\..)
F-CAN: Success(D:\home\raiser\work\restfs)
P-TO: Success(d:tarGet\..\Target\.\..)
P-ABS: Success(D:\home\raiser\work\restfs\tarGet\..\Target\.\..)
P-NOR: Success(d:)
P-NOR-ABS: Success(D:\home\raiser\work\restfs\)
P-ABS-NOR: Success(D:\home\raiser\work\restfs)
P-REAL: Success(D:\home\raiser\work\restfs)
Use: d:tarGet\non-existent\..\..\Target\.\..\ -> Relative path contains non-existent file
F-GET: Success(d:tarGet\non-existent\..\..\Target\.\..)
F-ABS: Success(d:\home\raiser\work\restfs\tarGet\non-existent\..\..\Target\.\..)
F-CAN: Success(D:\home\raiser\work\restfs)
P-TO: Success(d:tarGet\non-existent\..\..\Target\.\..)
P-ABS: Success(D:\home\raiser\work\restfs\tarGet\non-existent\..\..\Target\.\..)
P-NOR: Success(d:)
P-NOR-ABS: Success(D:\home\raiser\work\restfs\)
P-ABS-NOR: Success(D:\home\raiser\work\restfs)
P-REAL: Success(D:\home\raiser\work\restfs)
Use: d:target\\file -> Double slash
F-GET: Success(d:target\file)
F-ABS: Success(d:\home\raiser\work\restfs\target\file)
F-CAN: Success(D:\home\raiser\work\restfs\target\file)
P-TO: Success(d:target\file)
P-ABS: Success(D:\home\raiser\work\restfs\target\file)
P-NOR: Success(d:target\file)
P-NOR-ABS: Success(D:\home\raiser\work\restfs\target\file)
P-ABS-NOR: Success(D:\home\raiser\work\restfs\target\file)
P-REAL: Failure(java.nio.file.NoSuchFileException: D:\home\raiser\work\restfs\target\file)
Use: c:tarGet\..\Target\. -> File doesn't exist and drive letter is on different drive than the current one
F-GET: Success(c:tarGet\..\Target\.)
F-ABS: Success(c:\\tarGet\..\Target\.)
F-CAN: Success(C:\Target)
P-TO: Success(c:tarGet\..\Target\.)
P-ABS: Success(C:\tarGet\..\Target\.)
P-NOR: Success(c:Target)
P-NOR-ABS: Success(C:\Target)
P-ABS-NOR: Success(C:\Target)
P-REAL: Failure(java.nio.file.NoSuchFileException: C:\Target)
Use: l:tarGet\..\Target\.\..\ -> Drive letter doesn't exist
F-GET: Success(l:tarGet\..\Target\.\..)
F-ABS: Success(l:\tarGet\..\Target\.\..)
F-CAN: Success(L:\)
P-TO: Success(l:tarGet\..\Target\.\..)
P-ABS: Failure(java.io.IOError: java.io.IOException: Unable to get working directory of drive 'L')
P-NOR: Success(l:)
P-NOR-ABS: Failure(java.io.IOError: java.io.IOException: Unable to get working directory of drive 'L')
P-ABS-NOR: Failure(java.io.IOError: java.io.IOException: Unable to get working directory of drive 'L')
P-REAL: Failure(java.io.IOException: Unable to get working directory of drive 'L')
Use: za:tarGet\..\Target\.\..\ -> Drive letter is double so not valid
F-GET: Success(za:tarGet\..\Target\.\..)
F-ABS: Success(D:\home\raiser\work\restfs\za:tarGet\..\Target\.\..)
F-CAN: Success(D:\home\raiser\work\restfs)
P-TO: Failure(java.nio.file.InvalidPathException: Illegal char <:> at index 2: za:tarGet\..\Target\.\..)
P-ABS: Failure(java.nio.file.InvalidPathException: Illegal char <:> at index 2: za:tarGet\..\Target\.\..)
P-NOR: Failure(java.nio.file.InvalidPathException: Illegal char <:> at index 2: za:tarGet\..\Target\.\..)
P-NOR-ABS: Failure(java.nio.file.InvalidPathException: Illegal char <:> at index 2: za:tarGet\..\Target\.\..)
P-ABS-NOR: Failure(java.nio.file.InvalidPathException: Illegal char <:> at index 2: za:tarGet\..\Target\.\..)
P-REAL: Failure(java.nio.file.InvalidPathException: Illegal char <:> at index 2: za:tarGet\..\Target\.\..)
Use: d:tarGet|Suffix -> Path contains invalid chars in windows (|)
F-GET: Success(d:tarGet|Suffix)
F-ABS: Success(d:\home\raiser\work\restfs\tarGet|Suffix)
F-CAN: Failure(java.io.IOException: The filename, directory name, or volume label syntax is incorrect)
P-TO: Failure(java.nio.file.InvalidPathException: Illegal char <|> at index 8: d:tarGet|Suffix)
P-ABS: Failure(java.nio.file.InvalidPathException: Illegal char <|> at index 8: d:tarGet|Suffix)
P-NOR: Failure(java.nio.file.InvalidPathException: Illegal char <|> at index 8: d:tarGet|Suffix)
P-NOR-ABS: Failure(java.nio.file.InvalidPathException: Illegal char <|> at index 8: d:tarGet|Suffix)
P-ABS-NOR: Failure(java.nio.file.InvalidPathException: Illegal char <|> at index 8: d:tarGet|Suffix)
P-REAL: Failure(java.nio.file.InvalidPathException: Illegal char <|> at index 8: d:tarGet|Suffix)
A canonical path is absolute and unique, but will have different meaning on different systems.
A canonical pathname is both absolute and unique. The precise definition of canonical form is system-dependent.
A real path is the actual path with respect to the system. You would also have to pass in whether or not you don't deal with symbolic links, where it's implicitly handled with canonicalPath.
The precise definition of this method is implementation dependent but in general it derives from this path, an absolute path that locates the same file as this path, but with name elements that represent the actual name of the directories and the file. For example, where filename comparisons on a file system are case insensitive then the name elements represent the names in their actual case. Additionally, the resulting path has redundant name elements removed.
So yes, these two methods can return different things, but it really depends on your system. If you need something that's unique, then canonicalPath is your safest bet, even if it's not a Path.
What I noticed from my tests is that
Path.toRealPath() will throw java.nio.file.NoSuchFileException if the file does not exist (Javadoc: Returns the real path of an existing file.)
File.getCanonicalPath() will not throw an exception if the file does not exist (it will only throw IOException if
the file name itself is invalid and contains a '\0' char in it).
So the former would not be suitable if you want to use it for path checks before actually creating the file.
You are right that the Javadoc for both methods is somewhat shallow.
Sure, the example below shows some of the differences. Also getCanonicalPath will throw an exception if the file does not exist.
getCanonicalPath returns the path in its canonical or simplest form (from http://www.merriam-webster.com/dictionary/canonical%20form)
import java.io.File;
public class FileExample {
public static void main(String[] args) throws Exception {
File file = new File("/TEMP/../TEMP/myfile.txt");
System.out.println("ABS: " + file.getAbsolutePath());
System.out.println(" TO: " + file.toPath());
System.out.println("GET: " + file.getPath());
System.out.println("CAN: " + file.getCanonicalPath());
}
}
ABS: C:\TEMP\..\TEMP\myfile.txt
TO: \TEMP\..\TEMP\myfile.txt
GET: \TEMP\..\TEMP\myfile.txt
CAN: C:\TEMP\myfile.txt
The API states that the canonical path usually removes redundancies and resolves symbolic links and so on.
Try the following on a UNIX machine:
File file = new File("../test.txt"); // execute from /tmp/java/example
file.getAbsolutePath(); // evaluates to /tmp/java/example/../test.txt
file.getCanonicalPath(); // evaluates to /tmp/java/test.txt
The difference between File and Path is that Path is part of the newer NIO API which has many improvements and is more flexible.
As an example you could exchange the implementation of the file system with NIO (see https://github.com/google/jimfs), whereas java.io.File forces you to operate on your host file system.
Related
We write our jenkins pipeline using groovy script. Is there any way to identify the folder size or file size.
Our goal is to identify size of two zip files and calculate the difference between them.
I tried below code but its not working.
stage('Calculate Opatch size')
{
def sampleDir = new File('${BuildPathPublishRoot}')
def sampleDirSize = sampleDir.directorySize()
echo sampleDirSize
}
Getting below error :-
hudson.remoting.ProxyException: groovy.lang.MissingMethodException: No signature of method: java.io.File.directorySize() is applicable for argument types: () values: []
Possible solutions: directorySize()
at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onMethodCall(SandboxInterceptor.java:154)
Here's what worked for me. Grab all the files in a directory and sum the lengths.
Please note that you'll need to use quotes (") in order for string interpolation to work, i.e. "${BuildPathPublishRoot}" places the value of the BuildPathPublishRoot variable into the string, whereas '${BuildPathPublishRoot}' is taken literally to be the directory name.
workspaceSize = directorySize("${BuildPathPublishRoot}")
/** Computes bytes in the directory*/
public def directorySize(directory){
long bytes = 0
directory = (directory?:'').replace('\\','/')
directory = (directory =='') ? '' : (directory.endsWith('/') ? directory : "${directory}/")
def files=findFiles(glob: "${directory}*.*")
for (file in files) {
if (!file.isDirectory()){
bytes += file.length
}
}
return bytes
}
I have a directory: <dir>\Report\<env>\Log_XXX\Logs
where XXX is randomly created at run time, so I have to create a file inside Logs folder.
Following is what I tried to generate the Logs folder:
new File(System.getProperty("user.dir") + "/Report/" + System.getProperty("env") + "/" + Pattern.compile("^Log_") + "/Logs").mkdirs();
Based on your comments, it appears you are trying to locate the one and only subdirectory whose base name starts with Log_. You can accomplish this with Files.list:
Path logParent = Paths.get(
System.getProperty("user.dir"),
"Report",
System.getProperty("env"));
Path logDir;
try (Stream<Path> listing = Files.list(logParent)) {
Optional<Path> match = listing.filter(p -> Files.isDirectory(p) &&
p.getFilename().toString().startsWith("Log_")).findFirst();
logDir = match.orElseThrow(() -> new RuntimeException(
"No log directory found in " + logParent));
}
I want to be able to write a vim snippet that automatically turns into the required package.
E.g. expanding pkg while inside of .../com/theonlygust/project/Main.java would become
package com.theonlygusti.project;
I think the ways to do this are to either: read up the directory tree until seeing a TLD directory name (com, io, net, etc.) and then use the encountered directory names to build the package string, or to look up the directory tree for the pom.xml and find the package from there.
I learned about python interpolation.
I'm now trying this:
snippet pkg "Create package" b
package `!p
import os
from xml.etree import ElementTree
def get_package_name(pom_file_path):
namespaces = {'xmlns' : 'http://maven.apache.org/POM/4.0.0'}
tree = ElementTree.parse(pom_file_path)
root = tree.getroot()
groupId = root.find(".//xmlns:groupId", namespaces=namespaces)
artifactId = root.find(".//xmlns:artifactId", namespaces=namespaces)
return groupId.text + '.' + artifactId.text
def find_nearest_pom():
absolute_path = os.path.abspath(os.path.dirname('__file__')).split("/")
pom_dir_index = -1
# Find index of 'base_dir_name' element
while not os.path.isfile('/'.join(absolute_path[:pom_dir_index]) + '/pom.xml'):
pom_dir_index -= 1
return '/'.join(absolute_path[:pom_dir_index]) + '/pom.xml'
snip.rv = get_package_name(find_nearest_pom())`;
endsnippet
But I get the error
Name __file__ does not exist
And os.getcwd() doesn't work because that returns the directory from which vim was opened, not the directory that contains the current buffer.
I had a look at the snip object because I know it provides snip.fn to get the filename, but I couldn't find out if it provides the current file's directory.
Nevermind, finally learned that UltiSnips sets a global variable "path"
UltiSnips stores Java snippets in java.snippets, which on my machine is ~/.vim/bundle/vim-snippets/UltiSnips/java.snippets (I am usinghonza/vim-snippets` as well).
Snippets for Java are implemented using Python, so I have implemented the snippet below using Python as well (you can do it using multiple languages in UltiSnips).
There is already a snippet for package, which adds simply "package" word followed with a placeholder:
snippet pa "package" b
package $0
endsnippet
Let's create a pad snippet that will automatically insert package name, based on the directory chain, instead of the $0 placeholder:
snippet pad "package" b
package `!p
def get_package_string(base_dir_name):
import os
# Get absolute path of the package (without filename)
absolute_path = os.getcwd().split("/")
src_dir_index = 0
# Find index of 'base_dir_name' element
while absolute_path[src_dir_index] != base_dir_name:
src_dir_index+=1
# Create a 'package ' string, joining with dots
package_string = ".".join(absolute_path[src_dir_index+1:])
return package_string
# snip.rv is UltiSnips' return value we want to paste between ``
snip.rv = get_package_string("java")`
endsnippet
Note that this solution is based on the fact that in many Java projects, there is an src directory with main/java and test/java directories in it and you are editing one of the files in java directory (e.g. for src/main/com/google/common it will return com.google.common). You may need to modify this to be more flexible.
You can find more information about creating snippets in screencasts linked in its README.
I use a combination of the file path and the groupId and the artifactId from the nearest pom.xml (upwards)
global !p
import os
from xml.etree import ElementTree
def get_package_name(pom_file_path):
namespaces = {'xmlns' : 'http://maven.apache.org/POM/4.0.0'}
tree = ElementTree.parse(pom_file_path)
root = tree.getroot()
groupId = root.find(".//xmlns:groupId", namespaces=namespaces)
artifactId = root.find(".//xmlns:artifactId", namespaces=namespaces)
return groupId.text + '.' + artifactId.text
def find_nearest_pom():
current_file_dir = '/'.join((os.getcwd() + ('/' if os.getcwd()[-1] != '/' else '') + path).split('/')[:-1])
absolute_path = current_file_dir.split("/")
pom_dir_index = -1
if os.path.isfile('/'.join(absolute_path) + '/pom.xml'):
return '/'.join(absolute_path) + '/pom.xml'
# Find index of 'base_dir_name' element
while not os.path.isfile('/'.join(absolute_path[:pom_dir_index]) + '/pom.xml'):
pom_dir_index -= 1
return '/'.join(absolute_path[:pom_dir_index]) + '/pom.xml'
def get_file_package():
current_file_location = '.'.join((os.getcwd() + ('/' if os.getcwd()[-1] != '/' else '') + path).split('/')[:-1])
package = get_package_name(find_nearest_pom())
return package + current_file_location.split(package)[1]
endglobal
snippet pkg "package" b
package `!p snip.rv = get_file_package()`;
endsnippet
friends, in
gnu.getopt.Getopt.jar
there is some problem i am getting some problem when i am giving b* as option argument then it is taking as bin
Getopt g = new Getopt("cm_log_parser", args, "i:s"); //-D to enable debug log
while((opt = g.getopt()) != -1)
{
switch (opt)
{
case 'f'://To set file name(if above is not specified)
fileNameWithPath = getAndCheckOptArg(fFlag, opt, g);
fFlag = true;
break;
case 'p'://To set the pattern
String pattern = g.getOptarg();
hFlag = true;
break;
case '?':
usage("Invalid option" + opt + " option");
break;
}
}
When I specify -p "b*" it is returns bin , why this is happening?
The shell (I suspect you use Linux, right?) resolves the b* literal to bin (there must be a directory named bin in the current working directory), because it is treated as a wildcard.
Depending on the shell you use, you have to escape the asterisk... For example in bash, use
-p b\*
To escape it to be an asterisk instead of getting resolved by the shell
If I try to use a path that contains spaces in Linux I get FileNotFoundException, obviously. But if I try to add double/single quotes in the path as workaround, I get the same exception.
I was trying to check the reason and I found out that the generated absolute path when using quotes became: the user.home system property + specified path.
For example:
If I use this path:
/home/db2inst1/Desktop/testing - Development Environmet/64_dev/testing/logs
This is the absolute path I get when trying to use quotes:
/home/db2inst1/"/home/db2inst1/Desktop/testing - Development Environmet/64_dev/testing/logs"
I also tried to replace the spaces with "\ " instead of adding quotes, but it did not work.
I tried a lot of API's and it happens every time, made this code just for testing:
System.out.println("- regular path: ");
System.out.println(new File(path).getPath());
System.out.println(new File(path).getAbsolutePath());
System.out.println("- quoted path: ");
System.out.println(new File(quotedPath).getPath());
System.out.println(new File(quotedPath).getAbsolutePath());
And this is the output:
- regular path:
/home/db2inst1/Desktop/testing - Development Environmet/64_dev/testing/logs/testing.log
/home/db2inst1/Desktop/testing - Development Environmet/64_dev/testing/logs/testing.log
- absolute path:
"/home/db2inst1/Desktop/testing - Development Environmet/64_dev/testing/logs/testing.log"
/home/db2inst1/"/home/db2inst1/Desktop/testing - Development Environmet/64_dev/testing/logs/testing.log"
Does anyone know why this is happening and how to make it work?
From your description it seems that you are calling the File(java.lang.String pathname) constructor.
If so, the String used to represent your path should not use quotes.
Quotes are not considered as special characters in the abstract pathname definition, as described in the java.io.File documentation.
An abstract pathname has two components:
An optional system-dependent prefix string, such as a disk-drive specifier, "/" for the UNIX >root directory, or "\\" for a Microsoft Windows UNC pathname, and
A sequence of zero or more string names.
Since quotes are not special characters, they are considered part of a name.
Example:
public static void main(String[] args) {
File quotes = new File("\"C:\\myFolder\"");
File noQuotes = new File("C:\\myFolder");
System.out.println("Absolute path with quotes:" + quotes.getAbsolutePath());
System.out.println("Absolute path without quotes:" + noQuotes.getAbsolutePath());
System.out.println("Equal: " + quotes.equals(noQuotes));
File empty = new File("");
File emptyQuotes = new File("\"\"");
System.out.println("Empty path with quotes:" + empty.getAbsolutePath());
System.out.println("Empty path without quotes:"
+ emptyQuotes.getAbsolutePath());
System.out.println("Equal: " + empty.equals(emptyQuotes));
}
will produce the following output when run in C:\temp on Windows:
Absolute path with quotes:C:\temp\"C:\myFolder"
Absolute path without quotes:C:\myFolder
Equal: false
Empty path with quotes:C:\temp
Empty path without quotes:C:\temp\""
Equal: false
In windows a file name without blanks and the same quoted should refer to the same file (or folder). For instance if we have a folder called c:\uni2 both command lines
dir c:\uni2
dir "c:\uni2"
should give the same result. But in java
String rename;
boolean ya;
File f1 = new File ("C:/UNI2"); // given that exists and it is a directory
ya = f1.exists(); // true
ya = f1.isFile(); // false
ya = f1.isDirectory(); // true
rename = f1.getAbsolutePath(); // "C:\\UNI2"
f1 = new File ("\"C:/UNI2\""); // in windows this should be the same directory!!
ya = f1.exists(); // false
ya = f1.isFile(); // false
ya = f1.isDirectory(); // false
rename = f1.getAbsolutePath(); // "C:\tmp\"C:\UNI2""
which is not the expected behavior (even if it is documented).