There is a canonical path concept in Java.
And there is a fully-qualified path in WinApi.
I know well what canonical path is, but I don't understand fully-qualified path's concepts.
For a file or directory, does fully-qulified path exist only one thing? -like canonical path.
Are both of them totally same concepts?
Edit:
One more thing,
Is a symbloc link or a hard link belong to Fully qualified path?
Edit
I asked someone who maintains Naming Files, Paths, and Namespaces page to let me know this.
And he replied me.
Is this also Fully-qualified path?
C:\directory\..\directory\file.txt
Technically that is a relative path because it contains the double dot (..) and some APIs do not process those correctly (the docs will clearly state that it needs a fully qualified path).
The two are mutually exclusive.
What he means is, in my guessing, if we put a param like this "C:\directory\..\directory\file.txt" to the function required fully-qualified path, the function never reinterpret the path and then fails.
If so, fully-qualified path is totally same with an canonical path. Isn't it.
Absolute path defines a path from the root of the file system e.g. C:\\ or D:\\ in Windows and from / in UNIX based operating systems e.g. Linux or Solaris. The canonical path is a little bit tricky because all canonical path is absolute, but vice-versa is not true.
The canonical path is always an absolute and unique path. If String pathname is used to create a file object, it simply returns the pathname. This method first converts this pathname to absolute form if needed. To do that it will invoke the getAbsolutePath() Method and then maps it to its unique form.
getPath(): The getPath() method is a part of File class. This function returns the path of the given file object. The function returns a string object which contains the path of the given file object. getAbsolutePath(): The getAbsolutePath() returns a path object representing the absolute path of given path.
CanonicalFilePath is the pathname of a file object. If we create the file object using an abstract path, the canonical file path is the same as the abstract file path. If we create the file object using a relative path, the canonical file path is the path that is both the shortest absolute and unique path.
Every location on a file system has a multitude of paths that could be used to refer to it, including numerous fully-qualified paths:
Conceptually speaking, one of those fully-qualified paths is the simplest, most straightforward way of specifying that resource - that's your canonical path.
For a file or directory, does fully-qulified path exist only one thing? -like canonical path.
No, a fully-qualified path is any path which is not a relative path (not relative to the current directory of the implied or specified context). Multiple, but distinct, fully-qualified paths could refer to the same location on the filesystem. Reread:
What's the difference between getPath(), getAbsolutePath(), and getCanonicalPath() in Java?
but substitute "fully-qualified" everywhere it says "absolute".
To be clear, some people will also use the term "relative path" to also refer to a path with a "relative reference" (double dots ..
) within it. For example, some might might called C:\Program Files\Microsoft\\..\temp.txt
a "relative path" because of the double dots, but I would call it an fully-qualified path with a relative reference. Hopefully, it will be clear from the conversation what they mean when they say "relative path" (a path that is relative to a context or a path with a relative reference in it).
Are both of them totally same concepts?
No, as indicated in the other SO question, there are lots ways to specify a fully-qualified path (absolute path) to a location, but only one of those fully-qualified paths is considered to be the canonical path to that location.
One more thing, Is a UNC path belong to fully-qualified path too?
Yes, UNC paths are not relative paths; they are fully-qualified paths. - http://msdn.microsoft.com/en-us/library/aa365247(v=VS.85).aspx#fully_qualified_vs._relative_paths
Is a symbolic link or a hard link belong to Fully qualified path?
Its an independent concept. A path (regardless of whether it is relative or full-qualified) leads to a location in the filesystem. The entity at that location could be one of many things: a normal file, a directory, a symbolic link, a hard link, a device, a named pipe, etc. A symbolic links or a hard link has meta-data that leads to the data you were actually looking for at that location.
You can think of paths and links in the terms of directions to someone's house:
/
".C:\
, D:\
, E:\
, etc.10 Elm Str
and 20 Main Str
. No matter which address you go to, you end up at the same house.Addendum
Edit
I asked someone who maintains Naming Files, Paths, and Namespaces page to let me know this. And he replied me.
Is this also Fully-qualified path? C:\directory..\directory\file.txt
I wonder what terms the maintainer of that page would use to differentiate between ..\file.txt
and C:\directory\..\directory\file.txt
since he calls them both relative path. I agree that double dots are a relative reference, but I wouldn't tag the whole path as relative because it has double dots in the middle of it. In his terminology, there doesn't seem to be a difference between fully-qualified and canonical. (Therein, I suppose, lies the source of your question).
I come from a Unix and Java background, so perhaps that makes the difference. As I learned it:
relative/partially-qualified - location cannot be determined without the associated context providing information, e.g. the current working directory, the current drive, the drive's current directory, the shell PATH setting, the Java CLASSPATH setting, or the referencing URL.
absolute/fully-qualified - location is independent of the the associated context, i.e. the location is the same regardless of the current working directory, the current drive, the drive's current directory, the shell PATH setting, the Java CLASSPATH setting, or the referencing URL.
canonical - the simplest fully-qualified, i.e. no double-dots
So
That section of the MSDN page isn't clear on C:\directory\..\directory\file.txt
: If C:\directory\..\directory\file.txt
is considered relative and won't work with Windows API that say they need a fully-qualified (but not necessarily canonical?) path, I'd suggest that page needs to make that clearer.
Fully-qualfied vs Relative
A file name is relative to the current directory if it does not begin with one of the following:
... * A disk designator with a backslash, for example "C:\" or "d:\". ...
Since C:\directory\..\directory\file.txt
starts with a disk designator with a blackslash, this path is fully-qualified, not relative.
A path is also said to be relative if it contains "double-dots"; that is, two periods together in one component of the path. This special specifier is used to denote the directory above the current directory, otherwise known as the "parent directory". Examples of this format are as follows:
- "..\tmp.txt" specifies a file named tmp.txt located in the parent of the current directory.
- "....\tmp.txt" specifies a file that is two directories above the current directory.
- "..\tempdir\tmp.txt" specifies a file named tmp.txt located in a directory named tempdir that is a peer directory to the current directory.
I interpreted the phrase contains double dots to mean leading double dots. The examples show only leading double dots. The terminology "current directory" usually means process's current working directory or the drive's current directory, which has bearing only when talking about leading double dots. I can, however, see how the section could be interpreted the other way.
Regardless, everyone grows up different and context is king, so I guess everyone will need to be careful of the nuances when reading docs or discussing with engineers of different backgrounds on what they mean by "fully-qualified" vs "relative"
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With