Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
To stop XCOPY asking F or D in batch?
1,317 views
Skip to first unread message
dr.j.r....@gmail.com
Jan 24, 2019, 3:25:59 PM1/24/19
to
I run a batch program (Windows 10 usually; could be earlier maybe)
which uses XCOPY (I cannot use COPY, as XCOPY's /D is needed).
I use
FOR /F "eol=; tokens=1*" %%J IN ... (
...
XCOPY /D /Y %%J %unto%%%J %%K | FIND /v " File(s) copied"
)
After various enhancements, it now sometimes asks whether the
name on the destination should be a file or a directory, but
without the (F = file, D = directory)? - I expect the FIND /v
eats that.
Is there a good way to eliminate that question, and choose
file every time? Nothing shown by FIND /? seems suitable,
but ICBW. I can answer it "blind", but that's not nice.
This is an example of what I mean, I think :-
Prompt>xcopy pascal.htm e:fred.kk
Does E:fred.kk specify a file name
or directory name on the target
(F = file, D = directory)?
--
(c) John Stockton, near London, UK. Using Google Groups. |
Mail: J.R.""""""""@physics.org - or as Reply-To, if any. |
which uses XCOPY (I cannot use COPY, as XCOPY's /D is needed).
I use
FOR /F "eol=; tokens=1*" %%J IN ... (
...
XCOPY /D /Y %%J %unto%%%J %%K | FIND /v " File(s) copied"
)
After various enhancements, it now sometimes asks whether the
name on the destination should be a file or a directory, but
without the (F = file, D = directory)? - I expect the FIND /v
eats that.
Is there a good way to eliminate that question, and choose
file every time? Nothing shown by FIND /? seems suitable,
but ICBW. I can answer it "blind", but that's not nice.
This is an example of what I mean, I think :-
Prompt>xcopy pascal.htm e:fred.kk
Does E:fred.kk specify a file name
or directory name on the target
(F = file, D = directory)?
--
(c) John Stockton, near London, UK. Using Google Groups. |
Mail: J.R.""""""""@physics.org - or as Reply-To, if any. |
JJ
Jan 24, 2019, 5:49:41 PM1/24/19
to
On Thu, 24 Jan 2019 12:25:58 -0800 (PST), dr.j.r....@gmail.com wrote:
> I run a batch program (Windows 10 usually; could be earlier maybe)
> which uses XCOPY (I cannot use COPY, as XCOPY's /D is needed).
>
> I use
> FOR /F "eol=; tokens=1*" %%J IN ... (
> ...
> XCOPY /D /Y %%J %unto%%%J %%K | FIND /v " File(s) copied"
> )
>
> After various enhancements, it now sometimes asks whether the
> name on the destination should be a file or a directory, but
> without the (F = file, D = directory)? - I expect the FIND /v
> eats that.
>
> Is there a good way to eliminate that question, and choose
> file every time? Nothing shown by FIND /? seems suitable,
> but ICBW. I can answer it "blind", but that's not nice.
>
> This is an example of what I mean, I think :-
> Prompt>xcopy pascal.htm e:fred.kk
> Does E:fred.kk specify a file name
> or directory name on the target
> (F = file, D = directory)?
XCOPY will prompt you that if the destination doesn't exist. To always treat
> I run a batch program (Windows 10 usually; could be earlier maybe)
> which uses XCOPY (I cannot use COPY, as XCOPY's /D is needed).
>
> I use
> FOR /F "eol=; tokens=1*" %%J IN ... (
> ...
> XCOPY /D /Y %%J %unto%%%J %%K | FIND /v " File(s) copied"
> )
>
> After various enhancements, it now sometimes asks whether the
> name on the destination should be a file or a directory, but
> without the (F = file, D = directory)? - I expect the FIND /v
> eats that.
>
> Is there a good way to eliminate that question, and choose
> file every time? Nothing shown by FIND /? seems suitable,
> but ICBW. I can answer it "blind", but that's not nice.
>
> This is an example of what I mean, I think :-
> Prompt>xcopy pascal.htm e:fred.kk
> Does E:fred.kk specify a file name
> or directory name on the target
> (F = file, D = directory)?
the destination as a file, make sure the destination exists as a file. So,
create an empty file using the destination path, before executing XCOPY.
e.g.
set src=pascal.htm
set dest=e:fred.kk
(rem.>%dest%)2>nul
xcopy /y %src% %dest%
Zaidy036
Jan 24, 2019, 10:43:50 PM1/24/19
to
On 1/24/2019 5:49 PM, JJ wrote:
> set dest=e:fred.kk
I really hope that is a typo
Shouldn't it be: set dest=e:\fred.kk
Also RoboCopy may be a better and faster program to use
--
Zaidy036
> set dest=e:fred.kk
I really hope that is a typo
Shouldn't it be: set dest=e:\fred.kk
Also RoboCopy may be a better and faster program to use
--
Zaidy036
dr.j.r....@gmail.com
Jan 25, 2019, 7:22:13 AM1/25/19
to
On Thursday, 24 January 2019 22:49:41 UTC, JJ wrote:
That, as is, will not do; it will erase the old file %dest%, and
I want to copy only the few new files, leaving the many other old
ones untouched (especially as the destination might be a slow
device, and some files are vast). So I can use 'if not exist
dest create a dest first'.
I'd rather not use both XCOPY and XCOPY /D, but instead of
your redirected REM I could copy over an ancient (and perhaps
empty) file. DOS datestamps used a 16-bit unsigned integer
for days since 1980-01-01 = Day 0, but I see that imported
Touch32 in Win10 can go back to 1601-01-01. But XCOPY is
ancient, and might not like that. Going back to, say, 1981
should be safe.
H'mmm - I've used various ways to create a zero-length file
in the past, presumably because the obvious one did not then
work.
But (command line)
copy nul zzz > nul
touch32 zzz 1981 > nul
dir zzz
shows
1981-01-01 00:00 0 zzz
That looks promising.
P.S. I don't mind using an already-imported tool, Touch32; but
I don't want to import and learn another tool for this. Hence
- no RoboCopy.
Thanks.
I want to copy only the few new files, leaving the many other old
ones untouched (especially as the destination might be a slow
device, and some files are vast). So I can use 'if not exist
dest create a dest first'.
I'd rather not use both XCOPY and XCOPY /D, but instead of
your redirected REM I could copy over an ancient (and perhaps
empty) file. DOS datestamps used a 16-bit unsigned integer
for days since 1980-01-01 = Day 0, but I see that imported
Touch32 in Win10 can go back to 1601-01-01. But XCOPY is
ancient, and might not like that. Going back to, say, 1981
should be safe.
H'mmm - I've used various ways to create a zero-length file
in the past, presumably because the obvious one did not then
work.
But (command line)
copy nul zzz > nul
touch32 zzz 1981 > nul
dir zzz
shows
1981-01-01 00:00 0 zzz
That looks promising.
P.S. I don't mind using an already-imported tool, Touch32; but
I don't want to import and learn another tool for this. Hence
- no RoboCopy.
Thanks.
dr.j.r....@gmail.com
Jan 25, 2019, 8:50:29 AM1/25/19
to
> P.S. I don't mind using an already-imported tool, Touch32; but
> I don't want to import and learn another tool for this. Hence
> - no RoboCopy.
https://en.wikipedia.org/wiki/Robocopy says "File names and wildcard characters (such as * and ?) are not valid as source or destination arguments.", which makes it incapable of doing the whole job itself.
Robert Roland
Jan 28, 2019, 4:19:36 PM1/28/19
to
On Fri, 25 Jan 2019 05:50:28 -0800 (PST), dr.j.r....@gmail.com
wrote:
>https://en.wikipedia.org/wiki/Robocopy says "File names and wildcard characters (such as * and ?) are not valid as source or destination arguments.", which makes it incapable of doing the whole job itself.
It is true that you cannot use wildcard in the source folder name, but
in the file names, you can.
You can also exclude certain files based on wildcards. The /XF option
does that.
--
RoRo
wrote:
>https://en.wikipedia.org/wiki/Robocopy says "File names and wildcard characters (such as * and ?) are not valid as source or destination arguments.", which makes it incapable of doing the whole job itself.
in the file names, you can.
You can also exclude certain files based on wildcards. The /XF option
does that.
--
RoRo
dr.j.r....@gmail.com
Feb 2, 2019, 3:40:25 PM2/2/19
to
On Monday, 28 January 2019 21:19:36 UTC, Robert Roland wrote:
the other for BLOK - as the first one is working I should be
able to manage the other.
The default "log" on the screen is grossly excessive - the
required needles cannot be seen in the haystacks flying past.
XCOPY just listed the name of each file actually copied (and an
easily-suppressed count line) which would be ideal.
I see
/DST : Compensate for one-hour DST time differences.
which may annoy users on Lord Howe Island.
Thanks.
> On Fri, 25 Jan 2019 05:50:28 -0800 (PST), JRS wrote:
>
>> https://en.wikipedia.org/wiki/Robocopy says "File names and wildcard
>> characters (such as * and ?) are not valid as source or destination
>> arguments.", which makes it incapable of doing the whole job itself.
>
> It is true that you cannot use wildcard in the source folder name, but
> in the file names, you can.
>
> You can also exclude certain files based on wildcards. The /XF option
> does that.
The job has two successive loops, the first one for %user% and
>
>> https://en.wikipedia.org/wiki/Robocopy says "File names and wildcard
>> characters (such as * and ?) are not valid as source or destination
>> arguments.", which makes it incapable of doing the whole job itself.
>
> It is true that you cannot use wildcard in the source folder name, but
> in the file names, you can.
>
> You can also exclude certain files based on wildcards. The /XF option
> does that.
the other for BLOK - as the first one is working I should be
able to manage the other.
The default "log" on the screen is grossly excessive - the
required needles cannot be seen in the haystacks flying past.
XCOPY just listed the name of each file actually copied (and an
easily-suppressed count line) which would be ideal.
I see
/DST : Compensate for one-hour DST time differences.
which may annoy users on Lord Howe Island.
Thanks.
Konrad
Feb 4, 2019, 9:51:28 AM2/4/19
to
Hi,
You could try this:
echo F|xcopy <source> <destination>
Regards
Konrad
You could try this:
echo F|xcopy <source> <destination>
Regards
Konrad
dr.j.r....@gmail.com
Feb 12, 2019, 10:20:39 AM2/12/19
to
On Monday, 4 February 2019 14:51:28 UTC, Konrad wrote:
> You could try this:
>
> echo F|xcopy <source> <destination>
But <source> may contain wildcarding, so multiple F characters could be needed for one XCOPY call.
> You could try this:
>
> echo F|xcopy <source> <destination>
--------------------
XCOPY by default outputs, on-screen, just the name of each file that it actually copies from; and, in this application, that output is psychologically invaluable. Robocopy outputs a great deal for each call, including much more than, but not including, that.
To try Robocopy, it had been (for me) easier to do a systematic alteration to the control files than it would have been to parse the lines of the original control files into arguments for Robocopy.
Reverting to XCOPY, with the new control files, I therefore found it natural to express my wishes to XCOPY on a more explicit form than before - and this appears to have prevented XCOPY from feeling a need to ask "F or D?".
Therefore, the problem no longer exists.
By the way, XCOPY has a /I option which, maybe, would have helped.
Konrad
Feb 13, 2019, 8:01:59 AM2/13/19
to
Hi,
as far as I know xcopy never asks this question if there is any wildcard
in source or in destination. If you have an example please let me know.
On the other hand, in similiar cases you could prepare a file (e.g.
named "FF") which contains a billion F's. Then you could try:
xcopy [source] [destination] <FF
Regards
Konrad
as far as I know xcopy never asks this question if there is any wildcard
in source or in destination. If you have an example please let me know.
On the other hand, in similiar cases you could prepare a file (e.g.
named "FF") which contains a billion F's. Then you could try:
xcopy [source] [destination] <FF
Regards
Konrad
Konrad
Feb 13, 2019, 9:15:55 AM2/13/19
to
Hi again,
> as far as I know xcopy never asks this question if there is any
> wildcard in source or in destination.
This is not the whole truth, instead the criteria for getting this
question seems to be:
<destination> does not exist AND
<destination> does not contain wildcards
PS: Using input redirection may help in some cases but it may be useless
when there are other questions like "Overwrite existing files?".
Regards
Konrad
> as far as I know xcopy never asks this question if there is any
> wildcard in source or in destination.
question seems to be:
<destination> does not exist AND
<destination> does not contain wildcards
PS: Using input redirection may help in some cases but it may be useless
when there are other questions like "Overwrite existing files?".
Regards
Konrad
Tom Del Rosso
Feb 14, 2019, 1:29:37 AM2/14/19
to
dr.j.r....@gmail.com wrote:
>
> The default "log" on the screen is grossly excessive - the
> required needles cannot be seen in the haystacks flying past.
> XCOPY just listed the name of each file actually copied (and an
> easily-suppressed count line) which would be ideal.
Try xxcopy. Its options are a superset of xcopy but it's otherwise
>
> The default "log" on the screen is grossly excessive - the
> required needles cannot be seen in the haystacks flying past.
> XCOPY just listed the name of each file actually copied (and an
> easily-suppressed count line) which would be ideal.
similar.
dr.j.r....@gmail.com
Feb 14, 2019, 4:59:28 AM2/14/19
to
On Thursday, 14 February 2019 06:29:37 UTC, Tom Del Rosso wrote:
Why? I wrote, three days ago, "Therefore, the problem no longer exists." - using XCOPY with more explicit arguments.
XXCOPY would need to be imported to client computers. Also (see http://www.xxcopy.com/) XXCOPY is sadly no longer supportable.
XXCOPY would need to be imported to client computers. Also (see http://www.xxcopy.com/) XXCOPY is sadly no longer supportable.
Tom Del Rosso
Feb 14, 2019, 3:21:32 PM2/14/19
to
dr.j.r....@gmail.com wrote:
> On Thursday, 14 February 2019 06:29:37 UTC, Tom Del Rosso wrote:
>> JRS wrote:
>>>
>>> The default "log" on the screen is grossly excessive - the
>>> required needles cannot be seen in the haystacks flying past.
>>> XCOPY just listed the name of each file actually copied (and an
>>> easily-suppressed count line) which would be ideal.
>>
>> Try xxcopy. Its options are a superset of xcopy but it's otherwise
>> similar.
>
> Why? I wrote, three days ago, "Therefore, the problem no longer
> exists." - using XCOPY with more explicit arguments.
I replied before reading the entire thread of course. That message
> On Thursday, 14 February 2019 06:29:37 UTC, Tom Del Rosso wrote:
>> JRS wrote:
>>>
>>> The default "log" on the screen is grossly excessive - the
>>> required needles cannot be seen in the haystacks flying past.
>>> XCOPY just listed the name of each file actually copied (and an
>>> easily-suppressed count line) which would be ideal.
>>
>> Try xxcopy. Its options are a superset of xcopy but it's otherwise
>> similar.
>
> Why? I wrote, three days ago, "Therefore, the problem no longer
> exists." - using XCOPY with more explicit arguments.
followed the one to which I replied.
> XXCOPY would need to be imported to client computers. Also (see
> http://www.xxcopy.com/) XXCOPY is sadly no longer supportable.
apparent to me. I saw only one bug in earlier versions and it's no
longer there.
0 new messages