[<<]Message[>>]    [<<]Author[>>]    [<<]Subject[>>]    [<<]Thread[>>]

Number   :  4396
Date     :  2003-04-21
Author   :  Garry Deane
Subject  :  Re: Blank Directories
Size(KB) :  4


--- In xxcopy@yahoogroups.com, Kan Yabumoto  wrote:
> OK, I got the gist of the original question about the "blank"
> directory.
> 
> That is, xxcopy *ALWAYS* insists on creating the destination
> directory before the action really starts.
> 
> xxcopy c:\something d:\newname
> 
> When XXCOPY does not find the destination directory,
> it will always prompt the user whether the new directory
> should be created. If the answer is no, the program
> terminates without making the new directory. If yes,
> the destination directory will be unconditionally created.
> If there is no file to be copied, the destination directory
> will be empty.
> 
> This has been the only behavior expected of XXCOPY
> since that's how Microsoft's XCOPY used to behave.
> (To be perfectly honest, XCOPY will give you an added
> twist by spewing the silly prompt:
> 
> Does newdir specify a file name
> or directory name on the target
> (F = file, D = directory)?
> 
> So, whether you like it or not, XXCOPY's behavior is
> legitimate --- it always make sure the destination
> directory exists before the real action starts.
> -----------------------------------------------------------

I don't know about others but I've gotten so used to using Xxcopy 
that I don't even consider using Xcopy anymore. I keep forgetting 
that much of Xxcopy's behaviour results from being backward 
compatibile with Xcopy.

Without dragging out a somewhat trivial (if interesting) discussion 
too much, Xxcopy only prompts for the directory creation if the 
trailing backslash is missing from the destination and therefore 
there is some ambiguity. Xxcopy behaves consistently with Xcopy in 
this regard, although with a more sensible prompt. Neither Xxcopy nor 
Xcopy prompt for directory creation if the destination is specified 
as a directory by using a trailing backslash.

Where Xxcopy and Xcopy (both W98 and NT) differ is if there are no 
files found to copy and /E is NOT used. Going back to my previous 
example of copying *.xyz files which do not exist and where the 
destination directory does not exist:

The following results in an empty d:\test\ being created without 
prompting.

xxcopy c:\test\*.xyz d:\test\

On both W98 and NT, the following results in an error message 
of "File not found - *.xyz" and d:\test\ *NOT* being created.

xcopy c:\test\*.xyz d:\test\

The situation is no different to the above if /S is used but is 
different if /E is used. With /E, both Xxcopy and Xcopy behave 
identically and create an empty directory tree.

 

> In WinXP,
> 
> xcopy c:\test\strange.txt d:\test\ /E/Y
> 
> will copy all the three files as expected.
> 
> xcopy c:\test\strange1.txt d:\test\ /E/Y
> 
> will result in error because "strange1.txt"
> does not exist in the first level even though
> the subdirectories have the specified files.

BTW, Xcopy in NT behaves the same as the above except that it does 
not accept the /Y prompt.

> Having said all this, let me give you one solution
> which almost fits the original case.
> 
> xxcopy c:\dir\filename.* d:\dst\ /IP:c:\dir\filename.*
> 
> The /IP: switch prevents the creation of d:\dst\
> if the specified items in the /IP: parameter is not
> present (/IP: stands for IF-Present, go ahead).
> Note that the item that was given in /IP: was
> independently specified and need not be the same
> as the pattern in the source specifier. Also,
> yuu may add as many /IP switches as you like.
> 
> -----------------------------------------------------

That's a good idea which hadn't occurred to me. Unfortunately it 
won't help with Bob's problem because he'll have files which match 
the pattern but won't match the date range.

> Sorry to bore you to the death. But, I just wanted
> point out that XXCOPY's behavior with a non-existent
> destination directory has always been consistent to
> what XCOPY has been doing (until Microsoft changed
> their XCOPY's behavior). It seems pointless
> for us to go along with the inconsistent changes
> adopted by Microsoft. I think Microsoft's fix
> --- not really a bug fix (rather a response to the
> unfortunate syntactic ambiguity) was misguided and
> created a questionable behavior which is less
> consistent with how XCOPY behaves overall.
> 
> In conclusion, XXCOPY insists on having the
> destination directory either already present or
> newly created before it proceed to the file-action.

Kan, I for one am never bored by your explanations. I think you do 
this Group and your product a great service with your condiderable 
and considered input.

Garry



This message if part of XXCOPY's message Archive.
The archive contains all the messages posted at Yahoo!Groups: XXCOPY.