Re: full path of file

Bruno Luong wrote:

[needs to calculate an MS Windows absolute path given an absolute file path and a relative
path.]


For the purpose of this discussion, I will refer to the "known" path, and the
"target to resolve" (the one you are trying to find the full pathname of.)

The first thing to do is to check to see whether there is a colon (':')
anywhere in the target to resolve. If there is, and the colon is
followed immediately by a directory separator ('\' or '/'), then
the target to resolve is already in absolute path format and does not
need to be processed further. If there is a ':' and it is *not*
followed immediately by a directory separator, then you have a case
of a device followed by a relative path, which is a situation that you cannot
resolve without further information. A device name followed by a relative
path is resolved by MS Windows to be on the named device, but relative
to the last directory on that device that you changed directory into --
so for example, C:A/B.txt cannot be resolved unless you know the last
directory on device C: that you changed directory into. This applies even
if the device named is the same as the device name for the file on the
known path. If you do happen to know the last directory changed into
on the given device, then substitute that directory for the "known path",
and set a flag indicating that that the known path is already in directory
format, and continue; if you do not know the last directory changed into
on the given device, then error out.

If there is no colon anywhere in the target to resolve, then look at the first
character of the target to resolve. If it is a directory separator, then the target
to resolve is an absolute path, but the device name for it is the device that
you last changed directory into, which again you do not necessarily know. If
you do, then just pull the device name out of that known directory, slap it
on the front of the absolute path and you are finished, and otherwise error out,
or make an assumption as described below.

If the target to resolve did not begin with a directory seperator, then
the target to resolve is a relative reference to the last device you
changed directory into and the last directory you changed directory into
on that device. If you know what that is, then substitute
[devicename directoryname] as the "known path" and set the flag indicating
that the "known path" is already in directory format. If you don't know the last
device and directory changed into, then error out, or make the assumption as
described below.

If you choose not to error out when the above MS Windows resolution logic indicated
that you should, then you are making the assumption that the target to resolve
should be treated as if it is relative to the "known path". As indicated above,
that isn't how MS Windows really works... but you might be willing to give up
correct MS Windows semantics in favour of getting an answer out of your routine,

If you got to here and the flag I mentioned earlier a couple of times
is *not* set, then the "known path" is in full filename format, not in
directory format. If your "known path" is a full filename, search for the
-last- directory separator in the full filename, and remove from that point
onward to produce a new "known path" that is in directory format.

Your "known path" is, at this point, in directory format, and your
target to resolve is, at this point, in relative pathname format.

Now start an unconditional loop, such as via 'while true'

Search for the first directory separator in the target to resolve. If there are no
directory separators to be found, then break out of the loop, your resolution is done.

If the name from the beginning of the target to resolve until the directory separator
is '.' (exactly one period) then remove that and the following directory separator from
the target to resolve and "continue" the loop (that is, tell it to resume at the
beginning of the loop.

If the name from the beginning of the target to resolve until the directory separator
is '..' (exactly period) then remove that and the following directory seperator from
the target to resolve. Then find the last directory separator in the "known path";
if there is none to be found then you are trying to go "upwards" from the root
of the device file system, an operation which is defined as staying in the same place,
so in that situation "continue" the loop; but if you found a directory separator
in the "known path" then remove from that directory separator to the end of the
"known path" out of the "known path" and "continue" the loop.

In any other situation, remove from the beginning of the target to be resolved until
the directory separator from the target to be resolved, and take that name and
put it on the end of the "known path" immediately after a directory separator.
For example, known='C:/A/B' target='D/E.txt' would become known='C:/A/B/D'
and target='E.txt'. Once that is done, "continue" the loop.

End the loop.

When you have reached this point, the 'known path' is the full directory name
of the absolute path, and the 'target to be resolved' is the filename within
that directory. Splice the two together with a directory separator between
them and you have the complete absolute path.


This all takes longer to write in words than it would take in code. In code,
it is a fairly small state engine: the next thing in your target to be resolved
is either your terminal name, or is '.' (which is ignored), or is '..'
(in which case, climb up one level in the directory you are putting together),
and if none of the previous, it is the next component of the directory name.


The name resolution algorithm is quite similar for unix, but in unix
symbolic links are built in to the file system, and in order to get the
correct filename you -must- check each path component to see whether it is
a symbolic link. In Unix, /A/B/../D/E.txt might not be anywhere even close
to /A/D/E.txt: if either A or B were symbolic links, then the '..' in
unix would operate on whatever directory you ended up in. Also, in unix,
when you are interpreting where symbolic links lead to, relative symbolic
links are interpreted relative to the -directory- the link is in, not
relative to a pathname that includes the name of the link. For example,
/A/B/C/D/E.txt if C resolves to '../G' then that doesn't mean "go up
one level from /A/B/C to /A/B and add /G to the end of that (/A/B/G)":
it would mean "go up one level relative to the /A/B directory that C is
in, to /A, and add /G to that (/A/G)".
.

Relevant Pages

  • Re: VS 2005 pb on web site publish
    ... Target "_CheckForInvalidConfigurationAndPlatform" skipped. ... Reference found at search path location ... Could not resolve this reference. ... If this reference is required by your code, you may get compilation ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: VS 2005 pb on web site publish
    ... Target "_CheckForInvalidConfigurationAndPlatform" skipped. ... Reference found at search path location ... Could not resolve this reference. ... If this reference is required by your code, you may get compilation ...
    (microsoft.public.dotnet.framework.aspnet)
  • Previous message are duplicated
    ... Target "_CheckForInvalidConfigurationAndPlatform" skipped. ... Reference found at search path location ... Could not resolve this reference. ... If this reference is required by your code, you may get compilation ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: ADMT v3
    ... Make sure the PES service is running under an account from the target ... " unable to open a session on the password export server. ... I can resolve the export server from the target domain using both ...
    (microsoft.public.win2000.active_directory)
  • RE: Duplicate folder name in URL
    ... that url (stored in the value of that appsetting key). ... used to perform the redirection. ... you try using an absolute path in such scenario. ... we can use code to programmatically resolve such server-side path. ...
    (microsoft.public.dotnet.framework.aspnet)
Loading