Path: utzoo!attcan!uunet!samsung!munnari.oz.au!csource!david
From: david@csource.oz.au (david nugent)
Newsgroups: comp.os.msdos.programmer
Subject: Re: "file cannot be copied onto itself"
Message-ID: <745@csource.oz.au>
Date: 24 Sep 90 15:11:17 GMT
References: <2091@nyx.UUCP> <10478@pt.cs.cmu.edu>
Reply-To: david@csource.oz.au
Organization: Unique Computing Pty Ltd, Melb, Aust.
Lines: 45

In <10478@pt.cs.cmu.edu> ralf@b.gp.cs.cmu.edu (Ralf Brown) writes:

> In article <2091@nyx.UUCP> cla@nyx.UUCP () writes:
> }How does one determine that two files are indeed the same physical file?

> Under DOS 3.0 and up, the easiest way is to apply the following undocumented
> function to both names and then do a string compare.

> INT 21 - DOS 3+ internal - RESOLVE PATH STRING TO CANONICAL PATH STRING
>         AH = 60h
>         DS:SI -> ASCIZ relative path string or directory name
>         ES:DI -> 128-byte buffer for ASCIZ canonical fully qualified name



Just for your information, I'll relate some experience gained by use
under a wide variety of different DOS/LAN setups;

	Not supported at all under PC-MOS/386 (3.x and 4.x);
	
	Will not produce a valid and usable file name
		when done on a JOINed directory; it gets mapped
		back to the original drive/path, which is no longer
		considered valid by MS-DOS, (works fine on SUBST'd
		drives of course);

	Doesn't work well under MS-NET (fully resolved path
		names aren't valid there);

	Won't work under LAN manager, for the same reason as
		MS-NET;

So, this experience means that resolving paths is useful in the comparison
as above (to establish the file's identity), but such a path isn't
guaranteed to be useful for MS-DOS calls.  In other words, it should be
used for testing only, and the original paths used for the actual copying
once the verification is done.


david
-- 

        Fidonet: 3:632/348   SIGnet: 28:4100/1  Imex: 90:833/387
              Data:  +61-3-885-7864   Voice: +61-3-826-6711
 Internet/ACSnet: david@csource.oz.au    Uucp: ..!uunet!munnari!csource!david