Whenever I run a command in a command prompt window, I can see what's
happening as it does. However, upon completion it the window resets to
basically a clear screen so that I'm unable to see what was done. Can
anybody tell me how to stop it from doing this? I never had this problem
in Windows 7.

TIA

--
John C.

On 02/04/2024 12:26, John C. wrote:
> Whenever I run a command in a command prompt window, I can see what's
> happening as it does. However, upon completion it the window resets to
> basically a clear screen so that I'm unable to see what was done. Can
> anybody tell me how to stop it from doing this? I never had this problem
> in Windows 7.
>
> TIA
>
I have also never had that problem in Windows 8, 10 or 11.
What command(s) are you running?

On 4/2/2024 8:25 AM, MikeS wrote:
> On 02/04/2024 12:26, John C. wrote:
>> Whenever I run a command in a command prompt window, I can see what's
>> happening as it does. However, upon completion it the window resets to
>> basically a clear screen so that I'm unable to see what was done. Can
>> anybody tell me how to stop it from doing this? I never had this problem
>> in Windows 7.
>>
>> TIA
>>
> I have also never had that problem in Windows 8, 10 or 11.
> What command(s) are you running?
>

Doing "cls" in a Microsoft window, seems to be a built-in
and it also happens to clear the scrollback.

That's not the same as Formfeed, which would not affect the scrollback.

014 12 0C FF '\f' (form feed)

Since "cls" is a built-in, even if you used ProcMon, there would
be no trace of it (no trace of cls.exe loading).

If the OP was using a .bat file, perhaps some clever
individual put a "cls" in there.

Paul

John,

MikeS said :

> What command(s) are you running?

My question : and how ?

If you start a commandline program without doing that from inside a console
(command-prompt) window than than a console window will be opened for you,
but will automatically close when the command terminates.

The only question that is where that "basically a clear screen" comes from.
And that needs a sample of the command(s) you're running.

The other possibility is that a "doskey" macro is involved, but that only
works for specific commands (not for all of them).

Regards,
Rudy Wieser

"John C." <r9jmg0@yahoo.com> wrote:

> Whenever I run a command in a command prompt window, I can see what's
> happening as it does. However, upon completion it the window resets
> to basically a clear screen so that I'm unable to see what was done.
> Can anybody tell me how to stop it from doing this? I never had this
> problem in Windows 7.

And the "command" is WHAT? When you don't give details, we have to
guess which means a high chance of wrong guesses. We aren't standing
over your shoulder to see your screen. Your curtains are drawn, so our
magical telescopes won't work that can bend around the curvature of the
Earth. Sorry, the battery to my crystal ball is on backorder.

Does "clear" mean the shell window remains but gets cleared? If so, are
there no scroll bars for the shell's window? Could be you have to
scroll back up to see stdout. Click on the top left corner of the
console window to show the Control menu, or use the Alt+Spacebar combo.
Select Properties. How big is the buffer under the Layout tab? Mine is
132 chars x 3000 lines. Up the line buffer to, say, 3000. When stdout
exceeds the window size (which you can also change under the Layout tab;
mine is 100 chars x 50 lines), scrollbars will appear to let you move
back through stdout to see past output. There are a lot of options to
the console window which have been present since Windows 95.

Does "clear" mean the shell's window disappears? If you use Win+R to
run a script, the shell (console window) loads in which to run the
script, but the console closes when the script completes. You need to
open the shell yourself (cmd.exe), and then run the batch script. When
the script completes, you're left in the shell window (unless the script
has an 'exit' command at the end).

Are you using a shortcut to run a batch script", or using Win+R, or
running cmd.exe to load a shell? If so, is the command you run use
"cmd /c ..." or "cmd /k ..."? The first will exit the console (it
closes) when the target (script or program) completes. The second will
leave open the console window after completion. Run "cmd /?" for help.

If it's a batch script, it could have a 'cls' command. You'll have to
edit the batch script to comment out or remove the 'cls' command, or put
a 'pause' before it. It is also possible the script opens another
command shell (console window) to run a command, and the latter shell
closes on completing the command to leave only the first shell. Upon
completion, you lose the 2nd shell, and are back to the 1st shell. If
it is an executable (.exe or .com) then the program is clearing stdout,
and you can't control that unless there are config options in the
program.

I'm sure given more time and further impetus, I could come up with more
scenarios that might fit whatever you're doing.

In alt.comp.os.windows-10, on Tue, 2 Apr 2024 04:26:48 -0700, "John C."
<r9jmg0@yahoo.com> wrote:

>Whenever I run a command in a command prompt window, I can see what's
>happening as it does. However, upon completion it the window resets to
>basically a clear screen so that I'm unable to see what was done. Can
>anybody tell me how to stop it from doing this? I never had this problem
>in Windows 7.
>
>TIA

Put your command in a bat file and follow one or more lines of the bat
file with
Pause
exit /b

Maybe you don't need the pause, I can't rememeber, but it doesn't hurt.

If it's the same command that you run over and over, you can have a
dedicated bat file, but if you don't want to have one each, you can make
a bat file with a parameter, which would be the ccommand you are going
to run at the moment. I'm not sure anymore how to do that but iirc you
would type:

Go (or whatever you called it) [command]
and the first line of the bat file would include %1, which would then be
filled in with the command.

MikeS wrote:
> John C. wrote:
>>
>> Whenever I run a command in a command prompt window, I can see what's
>> happening as it does. However, upon completion it the window resets to
>> basically a clear screen so that I'm unable to see what was done. Can
>> anybody tell me how to stop it from doing this? I never had this problem
>> in Windows 7.
>>
>> TIA
>>
> I have also never had that problem in Windows 8, 10 or 11.
> What command(s) are you running?

I still use an ancient freeware command line program called "XXCopy" to
clone folders from one drive or partition to another drive or partition.
Eg. (slightly modified for privacy) a shortcut with this target:

C:\WINDOWS\system32\cmd.exe /k C:\WINDOWS\system32\xxcopy.exe
"C:\Users\(Account name)\My Documents" D:\(Backup folder name) /clone /YY

When the command line windows does that CLS thing after this command and
parameters run, unlike in Windows 7 I'm unable to see the changes in
file structure that occurred between source and destination.

--
John C.

micky wrote:
> John C. wrote:
>>
>> Whenever I run a command in a command prompt window, I can see what's
>> happening as it does. However, upon completion it the window resets to
>> basically a clear screen so that I'm unable to see what was done. Can
>> anybody tell me how to stop it from doing this? I never had this problem
>> in Windows 7.
>>
>> TIA
>
> Put your command in a bat file and follow one or more lines of the bat
> file with
> Pause
> exit /b
>
> Maybe you don't need the pause, I can't rememeber, but it doesn't hurt.
>
> If it's the same command that you run over and over, you can have a
> dedicated bat file, but if you don't want to have one each, you can make
> a bat file with a parameter, which would be the ccommand you are going
> to run at the moment. I'm not sure anymore how to do that but iirc you
> would type:
>
> Go (or whatever you called it) [command]
>
> and the first line of the bat file would include %1, which would then be
> filled in with the command.

Thanks, Micky. I'll check all that out and give it a try.

--
John C.

John C. wrote:

>When the command line windows does that CLS thing after this command and
>parameters run, unlike in Windows 7 I'm unable to see the changes in
>file structure that occurred between source and destination.

The last version of your ancient programme dates from 2016, so probably
is not 100% compatible with Windows 10?
You could just use robocopy instead which comes with any Windows since
Windows NT4.

-jw-
--
And now for something completely different...

In alt.comp.os.windows-10, on Wed, 3 Apr 2024 05:00:45 -0700, "John C."
<r9jmg0@yahoo.com> wrote:

>MikeS wrote:
>> John C. wrote:
>>>
>>> Whenever I run a command in a command prompt window, I can see what's
>>> happening as it does. However, upon completion it the window resets to
>>> basically a clear screen so that I'm unable to see what was done. Can
>>> anybody tell me how to stop it from doing this? I never had this problem
>>> in Windows 7.
>>>
>>> TIA
>>>
>> I have also never had that problem in Windows 8, 10 or 11.
>> What command(s) are you running?
>
>I still use an ancient freeware command line program called "XXCopy" to
>clone folders from one drive or partition to another drive or partition.
>Eg. (slightly modified for privacy) a shortcut with this target:
>
>C:\WINDOWS\system32\cmd.exe /k C:\WINDOWS\system32\xxcopy.exe
>"C:\Users\(Account name)\My Documents" D:\(Backup folder name) /clone /YY
>
>When the command line windows does that CLS thing after this command and
>parameters run, unlike in Windows 7 I'm unable to see the changes in
>file structure that occurred between source and destination.

I use XXCopy all the time.

This is a sample of my backup bat file:

@echo off
REM C:\Bat\10Acer-With-FFProfile-XXCopy-clone-C-WD.bat

@echo.
@echo press cntl-C to cancel
pause
REM @echo press cntl-C to cancel
REM pause

REM, this version does not do FF profiles. If you want, copy the whole
profile at one time, and do it after these first 5 steps, if possible,
unless it takes .
REM much more time than copying file by file did.

@echo
=============================================================================================================
c:\bat\XXCopySU64 /clone C:\bat E:\AcerLaptop\bat
/ILSAcerLaptop /ILDElements /oB0 /oAC:\bat\logs\Acer-data.log /tc
/FF3602 /PZ0 /EC /oD3

@echo Results above are for Bat
@echo
=============================================================================================================
@echo.
C:\bat\XXCopySU64 /clone C:\data E:\AcerLaptop\data
/ILSAcerLaptop /ILDElements /oB0 /oAC:\bat\logs\Acer-data.log /tc
/FF3602 /PZ0 /EC /oX3 /oD3 /XC:\Data\FFProfiles\cache2\

@echo Results above are for Data
@echo
=============================================================================================================
@echo.
C:\bat\XXCopySU64 /clone C:\downloads E:\AcerLaptop\downloads
/ILSAcerLaptop /ILDElements /oB0 /oAC:\bat\logs\Acer-data.log /tc
/FF3602 /PZ0 /EC /oD3

@echo Results above are for Downloads
@Echo NOTE: Have to close Agent to run next step, and Firefox
before that. Should have closed Eudora too! [Otherwise the files can't
be accessed, but it's not really true about Eudora. Eudora backs up fine
even when it's running. I suppose once in a while I might be
downloading mail while backing up and there would be an inconsistency,
but I don't think it's happened yet, and if it did it would be corrected
at the next backup, which could be immediately.]
@echo
=============================================================================================================
REM MMMM C:\bat\XXCopySU64 /clone C:\Programs E:\AcerLaptop\Programs
/ILSAcerLaptop /ILDElements /oB0 /oAC:\bat\logs\Acer-data.log /tc
/FF3602 /PZ0 /EC /oD3 /oX3 /XC:\Programs\JCL\

REM REM @echo Results above are for Programs
@echo
=============================================================================================================
C:\bat\XXCopySU64 /clone C:\Users\mmm\Pictures E:\AcerLaptop\Pictures
/ILSAcerLaptop /ILDElements /oB0 /oAC:\bat\logs\Acer-data.log /tc
/FF3602 /PZ0 /EC /oD3

@echo End of Process, Scroll up to review
@echo or press any key to finish
@echo.
@echo.
Pause
exit /b
-----

At this point, I can click on the scroll bar to go up and see what has
happened, but if I were to press page-up or the up-arrow, the cmd window
closes and disappears.

The author of XXCopy, Kan Yamamoto, died suddenly in his 40's or 50's
and there was no one to take over the business, and he hadn't made
arrangements. The free version of XXCopy will work forever, it seems,
but the free version of XXClone does not. I wish I had bought XXClone.

Paul, here, helped me when XXCopy64 wasn't working as well as I thought
it used to. He suggested XXCopySU64. By switching to XXCopySU64, I
don't have to participate between steps. It just runs until it finishes.
(I'm not sure if the Command window has to have focus for it to run or
not. I often want to watch and I don't have the patience to see if it
will finish if it's not on top.)

But it still displays several lines of introductory text for each step,
lines that I thought were only displayed once. I'd like to get rid of
that if I could.

/ILSAcerLaptop and /ILDElements are important because if one relies only
drive letters, drive letters can be changed unknowingly by inserting or
removing a USB drive, or the SD card that fits in the laptop slot. Using
/ILSAcerLaptop and /ILDElements assures one is copying to the right
drive.

/oB0 Something to do with what displays on the screen or goes into the
log file.

/oAC:\bat\logs\Acer-data.log says where the log will be and how much
information it should contain.

/tc copies all 3 time stamps that each file has.

/FF3602 This parm refers to fuzzy filetime and it recognizes that, in
a clone operation bearing in mind that the date is also checked, because
of daylight savings time iirc, 2 identical copied files can have times
that are an hour apart, 3600 seconds. It might not be wise to include
this when backing up someone else's data, but with one's own, I think
it's a good idea. An extra 2 seconds are added per Kan's advice,
because FAT has a 2-second granularity in file time.

/PZ0 0 suppresses the prompt for confirmation of the destination
directory. Because it's a bat file, I only have to get the bat file
right the first time, when I write the bat file, and after that it
doesn't change.

/EC causes the actual command line to be displayed even when "echo
off" has been used. There is more to it...See the help file.

/oX3 this causes the exclusion list to be displayed 3, both 1 and 2,
both on the screen and in the log file.

/oD3 this causees the deleted file list to be displayed 3, both 1 and
2, both on the screen and in the log file. I rarely delete files,
especially my files, the kind I backup, so I wanted a reminder of what
got deleted.

/XC:\Data\FFProfiles\cache2\ this parm lets me exclude Firefox
profiles from this backup routine, because they are too long to do
completely everytime.

Maybe I could make the commands even better but I don't know how.

"John C." <r9jmg0@yahoo.com> wrote:

> I still use an ancient freeware command line program called "XXCopy" to
> clone folders from one drive or partition to another drive or partition.
> Eg. (slightly modified for privacy) a shortcut with this target:
>
> C:\WINDOWS\system32\cmd.exe /k C:\WINDOWS\system32\xxcopy.exe
> "C:\Users\(Account name)\My Documents" D:\(Backup folder name) /clone /YY
>
> When the command line windows does that CLS thing after this command and
> parameters run, unlike in Windows 7 I'm unable to see the changes in
> file structure that occurred between source and destination.

Do you know XXcopy (abandonware) will run under Windows 10? Open a
command shell (cmd.exe), and then enter the "xxcopy <parms>" command to
check for errors. Maybe XXcopy is crashing. If the console window
suddenly clears, take a look in Event Viewer to see if there are app
errors at the time you ran XXcopy.

Rather than scrolling around inside a console window, might be easier to
use Notepad to view a log. XXcopy is probably writing its output to
stdout, but you could redirect it to a file, like:

xxcopy ... > c:\temp\xxcopy.txt
notepad d:\temp\xxcopy.txt

If you only want to see XXcopy's errors, redirect its stderr to a file
(if XXcopy sends error output to a separate stream):

xxcopy ... 2> c:\temp\xxcopy.txt
notepad c:\temp\xxcopy.txt

File descriptor 1 is stdout, but that's the default, so it can be
omitted. File descriptor 2 is for stderr.

I thought XXcopy had switches to output to log files, like /o (see
http://fekete.x10host.com/xxtb3000.htm, or run "xxcopy /?" or "xxcopy
/help").

XXcopy had problems. Sometimes it won't copy DLL or EXE files. Error
when copying to a remote (networked) host. Can't use UNCs.

On 4/3/2024 2:52 PM, VanguardLH wrote:
> "John C." <r9jmg0@yahoo.com> wrote:
>
>> I still use an ancient freeware command line program called "XXCopy" to
>> clone folders from one drive or partition to another drive or partition.
>> Eg. (slightly modified for privacy) a shortcut with this target:
>>
>> C:\WINDOWS\system32\cmd.exe /k C:\WINDOWS\system32\xxcopy.exe
>> "C:\Users\(Account name)\My Documents" D:\(Backup folder name) /clone /YY
>>
>> When the command line windows does that CLS thing after this command and
>> parameters run, unlike in Windows 7 I'm unable to see the changes in
>> file structure that occurred between source and destination.
>
> Do you know XXcopy (abandonware) will run under Windows 10? Open a
> command shell (cmd.exe), and then enter the "xxcopy <parms>" command to
> check for errors. Maybe XXcopy is crashing. If the console window
> suddenly clears, take a look in Event Viewer to see if there are app
> errors at the time you ran XXcopy.
>
> Rather than scrolling around inside a console window, might be easier to
> use Notepad to view a log. XXcopy is probably writing its output to
> stdout, but you could redirect it to a file, like:
>
> xxcopy ... > c:\temp\xxcopy.txt
> notepad d:\temp\xxcopy.txt
>
> If you only want to see XXcopy's errors, redirect its stderr to a file
> (if XXcopy sends error output to a separate stream):
>
> xxcopy ... 2> c:\temp\xxcopy.txt
> notepad c:\temp\xxcopy.txt
>
> File descriptor 1 is stdout, but that's the default, so it can be
> omitted. File descriptor 2 is for stderr.
>
> I thought XXcopy had switches to output to log files, like /o (see
> http://fekete.x10host.com/xxtb3000.htm, or run "xxcopy /?" or "xxcopy
> /help").
>
> XXcopy had problems. Sometimes it won't copy DLL or EXE files. Error
> when copying to a remote (networked) host. Can't use UNCs.
>

You can also redirect stderr and stdout, when running

program 2>&1 1>output.txt # Redirect stderr to stdout, redirect stdout to output.txt file

program 2>NUL 1>output.txt # Throw away stderr, record stdout as before.
# NUL is a reserved word, but I don't know if it is considered
# to be an "existing file handle that needs the & character".

If you use ">>" it would append the log to an existing output.txt file.
Using the single ">" erases output.txt and then starts to dump into the file.

On Robocopy, on large jobs, I always use the output logging option,
to guarantee there's a record of what happened. Using the "tee" option,
I can get a console dump and a permanent log as well. Some programs
have a very nice set of options. This copies the Y: drive to my (empty) F: drive.

robocopy Y:\ F:\ /mir /COPYALL /dcopy:t /XJ /r:3 /w:2 /zb /np /tee /v /log:robocopy_y_to_f.log

Paul

Joerg Walther wrote:
> John C. wrote:
>>
>> When the command line windows does that CLS thing after this command and
>> parameters run, unlike in Windows 7 I'm unable to see the changes in
>> file structure that occurred between source and destination.
>
> The last version of your ancient programme dates from 2016, so probably
> is not 100% compatible with Windows 10?

Still does the job like in Windows 7, but the CLS problem after runnning
it is new.

> You could just use robocopy instead which comes with any Windows since
> Windows NT4.
>
> -jw-

Yeah, it's pretty long in the tooth at this point, I admit. And the
program author has since passed away, leaving the code with an
irritating occasional "you need to check for updates" message that
wastes a lot of time.

I just did a search for "does robocopy do incremental clones?" and found
this page:

https://superuser.com/questions/814102/robocopy-command-to-do-an-incremental-backup

which contains the following:
___________________________________________________________________________

I have been successfully using a variant of the following script for a
few years now:

robocopy C:\source M:\destination /MIR /FFT /R:3 /W:10 /Z /NP /NDL

Parameters explained

The /MIR option (equivalent to /E /PURGE) stands for "mirror" and is
the most important option. It regards your source folder as the
"master", causing robocopy to copy/mirror any changes in the source (new
files, deletions etc.) to the target, which is a useful setting for a
backup.

/FFT is a very important option, as it allows a 2-second difference
when comparing timestamps of files, such that minor clock differences
between your computer and your backup device don't matter. This will
ensure that only modified files are copied over, even if file
modification times are not exactly synchronized.

/R:3 specifies the number of retries, if the connection should fail,
and /W:10 specifies a wait time of 10 seconds between retries. These are
useful options when doing the backup over a network.

/Z copies files in "restart mode", so partially copied files can be
continued after an interruption.

/NP and /NDL suppress some debug output, you can additionally add
/NS, /NC, /NFL to further reduce the amount of output (see the
documentation for details). However, I would suggest to print some debug
output during the first runs, to make sure everything is working as
expected.

Additional useful parameters mentioned by other users

/XJD excludes "junction points" for directories, symbolic links that
might cause problems like infinite loops during backup. See Brian's
comments for details.

/MT[:N] uses multithreading and can speed up transfers of many small
files. For N, a value of 2-4 times the number of cores should do on a
normal machine. Commented by Zoredache on the original question.

Edit in response to Granger's comment:

If you really want to keep files that exist on the destination, but not
on the source side, simply replace the /MIR option with /E. However, I
would strongly suggest to use /MIR when you want to use the destination
for incremental backups. Otherwise any files that have been renamed or
moved at the source will clutter up the destination, meaning you get
duplicates. I usually create a subfolder "backup" on the destination
which contains a 1:1 copy of my source folder tree. That way you can
still keep around historical files next to the backup folder and remove
or reorganize them safely later on.
___________________________________________________________________________

I could create test source and destination folders with dummy files and
then run the command to see what happes. I'd have to vet this entire
thing first though, to ensure that I won't lose any files though.

--
John C.

John C. wrote:
> MikeS wrote:
>> John C. wrote:
>>>
>>> Whenever I run a command in a command prompt window, I can see
>>> what's happening as it does. However, upon completion it the window
>>> resets to basically a clear screen so that I'm unable to see what
>>> was done. Can anybody tell me how to stop it from doing this? I
>>> never had this problem in Windows 7.
>>>
>>> TIA
>>>
>> I have also never had that problem in Windows 8, 10 or 11.
>> What command(s) are you running?
>
> I still use an ancient freeware command line program called "XXCopy"
> to clone folders from one drive or partition to another drive or
> partition. Eg. (slightly modified for privacy) a shortcut with this
> target:
>
> C:\WINDOWS\system32\cmd.exe /k C:\WINDOWS\system32\xxcopy.exe
> "C:\Users\(Account name)\My Documents" D:\(Backup folder name) /clone
> /YY
>
> When the command line windows does that CLS thing after this command
> and parameters run, unlike in Windows 7 I'm unable to see the changes
> in file structure that occurred between source and destination.

I still use xxcopy on my Win 10 Pro machine even though it does not backup
everything. But it makes it easy to go to files that are backed up. I also
do full backups with Macrium and EaseUS. I stop the batch file at the end
with Pause but have never tried scrolling. I will test this next time but I
would assume pressing any key will move the batch past Pause and close the
file. What I do is write a log file and if I need to check something I can
look in there. The log file contains a list of the files that were not
backed up.

This what I use to xxcopy 4 partitions:

D:\Backup\XXCopy\xxcopy C:\ G:\DRIVE_C /Clone /PZ0 /FF /PB30K /oS0 /VL
/oNC:\XXCopy.log
D:\Backup\XXCopy\xxcopy D:\ G:\DRIVE_D /Clone /PZ0 /FF /TC /PB30K /oS0 /VL
/oAC:\XXCopy.log
D:\Backup\XXCopy\xxcopy E:\ G:\DRIVE_E /Clone /PZ0 /VL /FF
/X"E:\Pagefile.sys" /TC /PB30K /oS0 /oAC:\XXCopy.log
D:\Backup\XXCopy\xxcopy F:\ G:\DRIVE_F /Clone /PZ0 /VL /FF /TC /PB30K /oS0
/oAC:\XXCopy.log

PAUSE

<Bill>

In alt.comp.os.windows-10, on Thu, 4 Apr 2024 09:09:33 -0800, "Bill
Bradshaw" <bradshaw@gci.net> wrote:

>John C. wrote:
>> MikeS wrote:
>>> John C. wrote:
>>>>
>>>> Whenever I run a command in a command prompt window, I can see
>>>> what's happening as it does. However, upon completion it the window
>>>> resets to basically a clear screen so that I'm unable to see what
>>>> was done. Can anybody tell me how to stop it from doing this? I
>>>> never had this problem in Windows 7.
>>>>
>>>> TIA
>>>>
>>> I have also never had that problem in Windows 8, 10 or 11.
>>> What command(s) are you running?
>>
>> I still use an ancient freeware command line program called "XXCopy"
>> to clone folders from one drive or partition to another drive or
>> partition. Eg. (slightly modified for privacy) a shortcut with this
>> target:
>>
>> C:\WINDOWS\system32\cmd.exe /k C:\WINDOWS\system32\xxcopy.exe
>> "C:\Users\(Account name)\My Documents" D:\(Backup folder name) /clone
>> /YY
>>
>> When the command line windows does that CLS thing after this command
>> and parameters run, unlike in Windows 7 I'm unable to see the changes
>> in file structure that occurred between source and destination.
>
>I still use xxcopy on my Win 10 Pro machine even though it does not backup
>everything.

What doesn't it copy?

I think they are files I'm not trying to copy, but it would be good to
know for sure. ;-)

XXCopy will also do, I think it's called journaling? Keeping more than
one version of the same file, a user-determined number. That way if you
screw up a file and back up the screwed up file, you still have the
previous correct file. I haven't used that yet because unless I plan
carefully I think it will overwhelm me with multiple files. Does
Robocopy do what I called journaling?

BTW, XXCopy does not use the Modified bit to decide when to copy, when
one is only copying modified files. IIRC it uses a combination of
modified date, file size and maybe something else, if any have changed.

>But it makes it easy to go to files that are backed up. I also
>do full backups with Macrium and EaseUS.

Me too. I only use XXCopy for my data, including what others say here.

>I stop the batch file at the end
>with Pause but have never tried scrolling. I will test this next time but I
>would assume pressing any key will move the batch past Pause and close the
>file.

Yes, but clicking on the scroll bar will scroll. I think you can go
back hundreds of lines but probably not thousands of lines. However I've
made my screen output short enough that I don't have to. There is
probably a CMD buffer parm that could be set to allow one to go back
farther.

> What I do is write a log file and if I need to check something I can
>look in there. The log file contains a list of the files that were not
>backed up.
>
>This what I use to xxcopy 4 partitions:
>
>D:\Backup\XXCopy\xxcopy C:\ G:\DRIVE_C /Clone /PZ0 /FF /PB30K /oS0 /VL
>/oNC:\XXCopy.log
>D:\Backup\XXCopy\xxcopy D:\ G:\DRIVE_D /Clone /PZ0 /FF /TC /PB30K /oS0 /VL
>/oAC:\XXCopy.log
>D:\Backup\XXCopy\xxcopy E:\ G:\DRIVE_E /Clone /PZ0 /VL /FF
>/X"E:\Pagefile.sys" /TC /PB30K /oS0 /oAC:\XXCopy.log
>D:\Backup\XXCopy\xxcopy F:\ G:\DRIVE_F /Clone /PZ0 /VL /FF /TC /PB30K /oS0
>/oAC:\XXCopy.log
>
>PAUSE

I have to go check on switches I don't use. Maybe I should!
><Bill>
>

"John C." <r9jmg0@yahoo.com> wrote:

> Joerg Walther wrote:
>> John C. wrote:
>>>
>>> When the command line windows does that CLS thing after this command and
>>> parameters run, unlike in Windows 7 I'm unable to see the changes in
>>> file structure that occurred between source and destination.
>>
>> The last version of your ancient programme dates from 2016, so probably
>> is not 100% compatible with Windows 10?
>
> Still does the job like in Windows 7, but the CLS problem after runnning
> it is new.
>
>> You could just use robocopy instead which comes with any Windows since
>> Windows NT4.
>>
>> -jw-
>
> Yeah, it's pretty long in the tooth at this point, I admit. And the
> program author has since passed away, leaving the code with an
> irritating occasional "you need to check for updates" message that
> wastes a lot of time.
>
> I just did a search for "does robocopy do incremental clones?" and found
> this page:
>
> https://superuser.com/questions/814102/robocopy-command-to-do-an-incremental-backup
>
> which contains the following:
> ___________________________________________________________________________
>
> I have been successfully using a variant of the following script for a
> few years now:
>
> robocopy C:\source M:\destination /MIR /FFT /R:3 /W:10 /Z /NP /NDL
>
> Parameters explained
>
> The /MIR option (equivalent to /E /PURGE) stands for "mirror" and is
> the most important option. It regards your source folder as the
> "master", causing robocopy to copy/mirror any changes in the source (new
> files, deletions etc.) to the target, which is a useful setting for a
> backup.
>
> /FFT is a very important option, as it allows a 2-second difference
> when comparing timestamps of files, such that minor clock differences
> between your computer and your backup device don't matter. This will
> ensure that only modified files are copied over, even if file
> modification times are not exactly synchronized.
>
> /R:3 specifies the number of retries, if the connection should fail,
> and /W:10 specifies a wait time of 10 seconds between retries. These are
> useful options when doing the backup over a network.
>
> /Z copies files in "restart mode", so partially copied files can be
> continued after an interruption.
>
> /NP and /NDL suppress some debug output, you can additionally add
> /NS, /NC, /NFL to further reduce the amount of output (see the
> documentation for details). However, I would suggest to print some debug
> output during the first runs, to make sure everything is working as
> expected.
>
> Additional useful parameters mentioned by other users
>
> /XJD excludes "junction points" for directories, symbolic links that
> might cause problems like infinite loops during backup. See Brian's
> comments for details.
>
> /MT[:N] uses multithreading and can speed up transfers of many small
> files. For N, a value of 2-4 times the number of cores should do on a
> normal machine. Commented by Zoredache on the original question.
>
> Edit in response to Granger's comment:
>
> If you really want to keep files that exist on the destination, but not
> on the source side, simply replace the /MIR option with /E. However, I
> would strongly suggest to use /MIR when you want to use the destination
> for incremental backups. Otherwise any files that have been renamed or
> moved at the source will clutter up the destination, meaning you get
> duplicates. I usually create a subfolder "backup" on the destination
> which contains a 1:1 copy of my source folder tree. That way you can
> still keep around historical files next to the backup folder and remove
> or reorganize them safely later on.
> ___________________________________________________________________________
>
> I could create test source and destination folders with dummy files and
> then run the command to see what happes. I'd have to vet this entire
> thing first though, to ensure that I won't lose any files though.

Or you could use GUI apps that do mirroring, too, to keep source and
destination in sync, like SyncBack Free (*) or FreeFileSync, both free.

(*) Does not support VSS (Volume Shadow Service) to copy locked files.
Have to pay to get a more robust version for that. FreeFileSync
says it supports VSS.
NOTE: robocopy doesn't support VSC, either, nor did XXcopy.
Non-Home users can use vssadmin to create shadows.

In alt.comp.os.windows-10, on Thu, 4 Apr 2024 09:09:33 -0800, "Bill
Bradshaw" <bradshaw@gci.net> wrote:

>This what I use to xxcopy 4 partitions:
>
>D:\Backup\XXCopy\xxcopy C:\ G:\DRIVE_C /Clone /PZ0 /FF /PB30K /oS0 /VL
>/oNC:\XXCopy.log
>D:\Backup\XXCopy\xxcopy D:\ G:\DRIVE_D /Clone /PZ0 /FF /TC /PB30K /oS0 /VL
>/oAC:\XXCopy.log
>D:\Backup\XXCopy\xxcopy E:\ G:\DRIVE_E /Clone /PZ0 /VL /FF
>/X"E:\Pagefile.sys" /TC /PB30K /oS0 /oAC:\XXCopy.log
>D:\Backup\XXCopy\xxcopy F:\ G:\DRIVE_F /Clone /PZ0 /VL /FF /TC /PB30K /oS0
>/oAC:\XXCopy.log

/Clone, essential, what Robo calls /MIR
/PZ0 suppresses the prompt for confirmation of dest name. I use
this too, in my bat file.
/FF fuzzy file time, discussed in other posts. This just does the
2 seconds but there is a good reason involving DST to make it 3602.
/PB30K shows file and job progress bars. I might like that.
/oS0 skipped file list. I don't think I skip files. Maybe I
should.
/X"E:\Pagefile.sys" Excludes the pagefile from copying. Is this what
is meant by skipped?
/VL sets the maxiumum path length to 32767. I don't use the
ridiculously long paths like for appdata. I just use C:\data,
C:\downloads, C:\programs. Maybe I'm hurting myself by doing this, but
I don't know one way or the other.
/oNC:\XXCopy.log BTW, you can write a new log file each time, like
here, or append to your old one, /oAC:....

XXCopy takes quite a bit of reading and fiddling to set it up just the
way one wants, but after that, you only have to run it.

On 4/4/2024 7:29 AM, John C. wrote:
> Joerg Walther wrote:
>> John C. wrote:
>>>
>>> When the command line windows does that CLS thing after this command and
>>> parameters run, unlike in Windows 7 I'm unable to see the changes in
>>> file structure that occurred between source and destination.
>>
>> The last version of your ancient programme dates from 2016, so probably
>> is not 100% compatible with Windows 10?
>
> Still does the job like in Windows 7, but the CLS problem after runnning
> it is new.
>
>> You could just use robocopy instead which comes with any Windows since
>> Windows NT4.
>>
>> -jw-
>
> Yeah, it's pretty long in the tooth at this point, I admit. And the
> program author has since passed away, leaving the code with an
> irritating occasional "you need to check for updates" message that
> wastes a lot of time.
>
> I just did a search for "does robocopy do incremental clones?" and found
> this page:
>
> https://superuser.com/questions/814102/robocopy-command-to-do-an-incremental-backup
>
> which contains the following:
> ___________________________________________________________________________
>
> I have been successfully using a variant of the following script for a
> few years now:
>
> robocopy C:\source M:\destination /MIR /FFT /R:3 /W:10 /Z /NP /NDL
>
> Parameters explained
>
> The /MIR option (equivalent to /E /PURGE) stands for "mirror" and is
> the most important option. It regards your source folder as the
> "master", causing robocopy to copy/mirror any changes in the source (new
> files, deletions etc.) to the target, which is a useful setting for a
> backup.
>
> /FFT is a very important option, as it allows a 2-second difference
> when comparing timestamps of files, such that minor clock differences
> between your computer and your backup device don't matter. This will
> ensure that only modified files are copied over, even if file
> modification times are not exactly synchronized.
>
> /R:3 specifies the number of retries, if the connection should fail,
> and /W:10 specifies a wait time of 10 seconds between retries. These are
> useful options when doing the backup over a network.
>
> /Z copies files in "restart mode", so partially copied files can be
> continued after an interruption.
>
> /NP and /NDL suppress some debug output, you can additionally add
> /NS, /NC, /NFL to further reduce the amount of output (see the
> documentation for details). However, I would suggest to print some debug
> output during the first runs, to make sure everything is working as
> expected.
>
> Additional useful parameters mentioned by other users
>
> /XJD excludes "junction points" for directories, symbolic links that
> might cause problems like infinite loops during backup. See Brian's
> comments for details.
>
> /MT[:N] uses multithreading and can speed up transfers of many small
> files. For N, a value of 2-4 times the number of cores should do on a
> normal machine. Commented by Zoredache on the original question.
>
> Edit in response to Granger's comment:
>
> If you really want to keep files that exist on the destination, but not
> on the source side, simply replace the /MIR option with /E. However, I
> would strongly suggest to use /MIR when you want to use the destination
> for incremental backups. Otherwise any files that have been renamed or
> moved at the source will clutter up the destination, meaning you get
> duplicates. I usually create a subfolder "backup" on the destination
> which contains a 1:1 copy of my source folder tree. That way you can
> still keep around historical files next to the backup folder and remove
> or reorganize them safely later on.
> ___________________________________________________________________________
>
> I could create test source and destination folders with dummy files and
> then run the command to see what happes. I'd have to vet this entire
> thing first though, to ensure that I won't lose any files though.
>

Test it on a folder of files.

Put A,B,C files in source. Destination gets A,B,C

Save C, changing date Destination now has A,B,C and C has new date. One file copied

Add file D Destination now has A,B,C,D and one file copied

******

Now, this is the critical part. This distinguishes between "additive"
maintenance and "mirror".

Remove A Destination now has B,C,D and A was removed on destination (mirror)

*******

Some utilities, when you Remove A on the source, the Destination
continues to have A,B,C,D . That's more of an archival kind of maintenance.
Perhaps a file sync program has an option for supporting that policy.

Windows File History plus an external backup drive, can keep a lot
more copies of a file. It's just the interface for rolling back,
requires nerves of steel :-) It's possible it keeps the info, in
ZIP files on the external backup drive. A notification appears on
the screen to "connect backup drive now", so it can transfer a
blob of stuff to the external drive.

If you want things done in a particular way, it takes a lot
of research and (small scale) testing to ensure you are getting
exactly the effect desired.

Paul

VanguardLH wrote:
> "John C." <r9jmg0@yahoo.com> wrote:
>
>> Joerg Walther wrote:
>>> John C. wrote:
>>>>
>>>> When the command line windows does that CLS thing after this command and
>>>> parameters run, unlike in Windows 7 I'm unable to see the changes in
>>>> file structure that occurred between source and destination.
>>>
>>> The last version of your ancient programme dates from 2016, so probably
>>> is not 100% compatible with Windows 10?
>>
>> Still does the job like in Windows 7, but the CLS problem after runnning
>> it is new.
>>
>>> You could just use robocopy instead which comes with any Windows since
>>> Windows NT4.
>>>
>>> -jw-
>>
>> Yeah, it's pretty long in the tooth at this point, I admit. And the
>> program author has since passed away, leaving the code with an
>> irritating occasional "you need to check for updates" message that
>> wastes a lot of time.
>>
>> I just did a search for "does robocopy do incremental clones?" and found
>> this page:
>>
>> https://superuser.com/questions/814102/robocopy-command-to-do-an-incremental-backup
>>
>> which contains the following:
>> ___________________________________________________________________________
>>
>> I have been successfully using a variant of the following script for a
>> few years now:
>>
>> robocopy C:\source M:\destination /MIR /FFT /R:3 /W:10 /Z /NP /NDL
>>
>> Parameters explained
>>
>> The /MIR option (equivalent to /E /PURGE) stands for "mirror" and is
>> the most important option. It regards your source folder as the
>> "master", causing robocopy to copy/mirror any changes in the source (new
>> files, deletions etc.) to the target, which is a useful setting for a
>> backup.
>>
>> /FFT is a very important option, as it allows a 2-second difference
>> when comparing timestamps of files, such that minor clock differences
>> between your computer and your backup device don't matter. This will
>> ensure that only modified files are copied over, even if file
>> modification times are not exactly synchronized.
>>
>> /R:3 specifies the number of retries, if the connection should fail,
>> and /W:10 specifies a wait time of 10 seconds between retries. These are
>> useful options when doing the backup over a network.
>>
>> /Z copies files in "restart mode", so partially copied files can be
>> continued after an interruption.
>>
>> /NP and /NDL suppress some debug output, you can additionally add
>> /NS, /NC, /NFL to further reduce the amount of output (see the
>> documentation for details). However, I would suggest to print some debug
>> output during the first runs, to make sure everything is working as
>> expected.
>>
>> Additional useful parameters mentioned by other users
>>
>> /XJD excludes "junction points" for directories, symbolic links that
>> might cause problems like infinite loops during backup. See Brian's
>> comments for details.
>>
>> /MT[:N] uses multithreading and can speed up transfers of many small
>> files. For N, a value of 2-4 times the number of cores should do on a
>> normal machine. Commented by Zoredache on the original question.
>>
>> Edit in response to Granger's comment:
>>
>> If you really want to keep files that exist on the destination, but not
>> on the source side, simply replace the /MIR option with /E. However, I
>> would strongly suggest to use /MIR when you want to use the destination
>> for incremental backups. Otherwise any files that have been renamed or
>> moved at the source will clutter up the destination, meaning you get
>> duplicates. I usually create a subfolder "backup" on the destination
>> which contains a 1:1 copy of my source folder tree. That way you can
>> still keep around historical files next to the backup folder and remove
>> or reorganize them safely later on.
>> ___________________________________________________________________________
>>
>> I could create test source and destination folders with dummy files and
>> then run the command to see what happes. I'd have to vet this entire
>> thing first though, to ensure that I won't lose any files though.
>
> Or you could use GUI apps that do mirroring, too, to keep source and
> destination in sync, like SyncBack Free (*) or FreeFileSync, both free.

Yeah, I think it's going to have to go to that.

> (*) Does not support VSS (Volume Shadow Service) to copy locked files.
> Have to pay to get a more robust version for that. FreeFileSync
> says it supports VSS.
> NOTE: robocopy doesn't support VSC, either, nor did XXcopy.
> Non-Home users can use vssadmin to create shadows.

Thanks, VanguardLH. I've been using SyncBack Free for a long time. Ever
since Bear Bottoms recommended it to me. He also recommended
FreeFileSync, which I've used and will check out again.

I already have so many profiles in SyncBack Free that it'll be kind of
confusing if I add any more. Not sure if it's possible to arrange them
into groups though, but I can't see how to do that.

--
John C.

"John C." <r9jmg0@yahoo.com> wrote:

> I've been using SyncBack Free for a long time. Ever since Bear Bottoms
> recommended it to me. He also recommended FreeFileSync, which I've
> used and will check out again.
>
> I already have so many profiles in SyncBack Free that it'll be kind
> of confusing if I add any more. Not sure if it's possible to arrange
> them into groups though, but I can't see how to do that.

Not intuitive how to create groups (of jobs aka profiles). You create a
new profile, right-click on it to edit it (or select and Shift+M to edit
the profile), and then add other profiles under the one being modified.
While the profiles can be run in parallel, I group them and do NOT elect
to run in parallel. I'm grouping to run the included profiles in order
(sequentially) to avoid conflict between them.

For a better description, and since you have it installed, go into its
Help and search on "group". There is a section titled "Creating a
group". You must have at least 2 profiles defined to then group them.
No such thing as a group of one; that would be a solitary profile ran by
itself.

I am currently on Syncback Lite 8.0.0. I had Syncback Free, but needed
the VSS support in the Lite edition (which no longer exist, so the SE
edition is the next step up from the Free edition). Syncback is now up
to version 11, but my Lite version is not eligible for update. Nothing
in the SE v11 that I need, so I don't bother with upgrading. I'll
review https://www.2brightsparks.com/syncback/changes.html to see if
anything showed up since v8 that is worth $40 to me for the SE edition.

VanguardLH wrote:
> John C. wrote:
>>
>> I've been using SyncBack Free for a long time. Ever since Bear Bottoms
>> recommended it to me. He also recommended FreeFileSync, which I've
>> used and will check out again.
>>
>> I already have so many profiles in SyncBack Free that it'll be kind
>> of confusing if I add any more. Not sure if it's possible to arrange
>> them into groups though, but I can't see how to do that.
>
> Not intuitive how to create groups (of jobs aka profiles). You create a
> new profile, right-click on it to edit it (or select and Shift+M to edit
> the profile), and then add other profiles under the one being modified.
> While the profiles can be run in parallel, I group them and do NOT elect
> to run in parallel. I'm grouping to run the included profiles in order
> (sequentially) to avoid conflict between them.
>
> For a better description, and since you have it installed, go into its
> Help and search on "group". There is a section titled "Creating a
> group". You must have at least 2 profiles defined to then group them.
> No such thing as a group of one; that would be a solitary profile ran by
> itself.
>
> I am currently on Syncback Lite 8.0.0. I had Syncback Free, but needed
> the VSS support in the Lite edition (which no longer exist, so the SE
> edition is the next step up from the Free edition). Syncback is now up
> to version 11, but my Lite version is not eligible for update. Nothing
> in the SE v11 that I need, so I don't bother with upgrading. I'll
> review https://www.2brightsparks.com/syncback/changes.html to see if
> anything showed up since v8 that is worth $40 to me for the SE edition.

Thanks for your reply, VanguardLH. Yep, there are the instructions
exactly where they should be all right. I'll certainly make use of this
feature and maybe at last, I'll be able to get rid of XXCopy.

I won't need to purchase a version of SyncBack though, because I'm only
interested in making backups of data files and haven't had a need for
VSS support.

--
John C.

Paul wrote:
> MikeS wrote:
>> John C. wrote:
>>>
>>> Whenever I run a command in a command prompt window, I can see what's
>>> happening as it does. However, upon completion it the window resets to
>>> basically a clear screen so that I'm unable to see what was done. Can
>>> anybody tell me how to stop it from doing this? I never had this problem
>>> in Windows 7.
>>>
>>> TIA
>>>
>> I have also never had that problem in Windows 8, 10 or 11.
>> What command(s) are you running?
>
> Doing "cls" in a Microsoft window, seems to be a built-in
> and it also happens to clear the scrollback.
>
> That's not the same as Formfeed, which would not affect the scrollback.
>
> 014 12 0C FF '\f' (form feed)
>
> Since "cls" is a built-in, even if you used ProcMon, there would
> be no trace of it (no trace of cls.exe loading).
>
> If the OP was using a .bat file, perhaps some clever
> individual put a "cls" in there.

No, I'll explain. I'm running XXCopy by Pixelab, Inc. It's a freeware
command line program who's author is now passed away. I have shortcuts
to the program, all for synchronizing different folders with similarly
named folders on other internal hard drives. Here's an example of the
Target line of one such shortcut:

C:\WINDOWS\system32\cmd.exe /k C:\WINDOWS\system32\xxcopy.exe "C:\1\"
"E:\1\" /clone /YY /k

where C:\1 and E:\1 are just examples of source and destination folders.

Sorry about the line wrapping. I'm still having fits with Thunderbird
after I went from W7 to W10.

When I run a shortcut like that, I can see the new files in the first
folder scroll by in the command line window. However, once the program
has run, it's as if I ran a CLS command which cleared the window. This
is not what I want, because I want to be able to scroll upwards on the
screen to see what changes were made to the destination folder. In
Windows 7, this was easily possible. In Windows 10 though, that
seemingly automatic CLS command gets run and I lose the information I need.

Hope this helps you understand my dilemma.

--
John C.

On 09/04/2024 00:32, John C. wrote:
>
> C:\WINDOWS\system32\cmd.exe /k C:\WINDOWS\system32\xxcopy.exe "C:\1\"
> "E:\1\" /clone /YY /k
>
> where C:\1 and E:\1 are just examples of source and destination folders.
>
>
Why not just use robocopy?

robocopy c:\1 E:\1 * /S / E

This will allow you to scroll the screen at the time or after the
process is is going.

You don't need any other software to install and Robocopy is Microsoft's
own product already in Windows 7, 10 or 11.

"John C." <r9jmg0@yahoo.com> wrote:

> Paul wrote:
>> MikeS wrote:
>>> John C. wrote:
>>>>
>>>> Whenever I run a command in a command prompt window, I can see what's
>>>> happening as it does. However, upon completion it the window resets to
>>>> basically a clear screen so that I'm unable to see what was done. Can
>>>> anybody tell me how to stop it from doing this? I never had this problem
>>>> in Windows 7.
>>>>
>>>> TIA
>>>>
>>> I have also never had that problem in Windows 8, 10 or 11.
>>> What command(s) are you running?
>>
>> Doing "cls" in a Microsoft window, seems to be a built-in
>> and it also happens to clear the scrollback.
>>
>> That's not the same as Formfeed, which would not affect the scrollback.
>>
>> 014 12 0C FF '\f' (form feed)
>>
>> Since "cls" is a built-in, even if you used ProcMon, there would
>> be no trace of it (no trace of cls.exe loading).
>>
>> If the OP was using a .bat file, perhaps some clever
>> individual put a "cls" in there.
>
> No, I'll explain. I'm running XXCopy by Pixelab, Inc. It's a freeware
> command line program who's author is now passed away. I have shortcuts
> to the program, all for synchronizing different folders with similarly
> named folders on other internal hard drives. Here's an example of the
> Target line of one such shortcut:
>
> C:\WINDOWS\system32\cmd.exe /k C:\WINDOWS\system32\xxcopy.exe "C:\1\"
> "E:\1\" /clone /YY /k
>
> where C:\1 and E:\1 are just examples of source and destination folders.
>
> Sorry about the line wrapping. I'm still having fits with Thunderbird
> after I went from W7 to W10.
>
> When I run a shortcut like that, I can see the new files in the first
> folder scroll by in the command line window. However, once the program
> has run, it's as if I ran a CLS command which cleared the window. This
> is not what I want, because I want to be able to scroll upwards on the
> screen to see what changes were made to the destination folder. In
> Windows 7, this was easily possible. In Windows 10 though, that
> seemingly automatic CLS command gets run and I lose the information I need.
>
> Hope this helps you understand my dilemma.

Despite some 'cls' effect after running xxcopy, that doesn't mean you
must lose all of xxcopy's output. It writes to stdout, so just redirect
stdout to a file (already mentioned by me, and added upon by Paul):

xxcopy ... > log.txt
^
or |---- very easy to add to the command
V
xxcopy ... >> log.txt

A single greater-than overwrites (without prompt) the file if it
currently exists. A double greater-than appends to the file. If you
don't want the text file in the same folder where you run xxcopy, add a
path to it, like d:\temp\log.txt. Really simple. ANYTHING that xxcopy
outputs will go to the text file. Doesn't matter whether the shell's
window got cleared or closed. The stdout got captured in the text file
while xxcopy was running.

Besides the copy operation getting recorded, you could see if xxcopy
issued some error that might've caused the 'cls' effect.

Something goofy is happening with xxcopy, but the workaround is easy.
In fact, since you want to see the output, and using an editor lets you
more easily scroll and even search, you could have Notepad load the log
file, as in:

xxcopy ... > log.txt && notepad log.txt

While xxcopy.exe is an executable program, you don't really need cmd.exe
to load a shell in which to run xxcopy. The "cmd /c" or "cmd /k" isn't
needed. However, if any commands are internal to the command
interpreter (cmd.exe), yep, you need to call cmd.exe to run its args.

dir c:\ > log.txt && notepad log.txt && del log.txt

would result in an unknown command error, because there is no dir.exe
program to be found in the current directory nor in the PATH environment
variable. So, if using internal commands, use:

cmd /c dir c:\ > log.txt && notepad log.txt && del log.txt

Here I used /c instead of /k, because there is no need to keep the shell
window open. The intent is to see the stdout of the program, and by
using Notepad which is a lot easier than trying to scroll around inside
a shell window (and gets truncated if you don't define a big enough
buffer).

A single ampersand runs the next command if errorlevel was zero from the
prior command, but a double ampersand runs the next command regardless
of fail/succeed of the prior command. You don't even need to use
cmd.exe to load a shell to run xxcopy. Just run xxcopy, copy its stdout
into a file, and open that file in Notepad. If you don't want the file
lingering around after viewing in Notepad, use:

xxcopy ... > log.txt && notepad log.txt && del log.txt

All of those commands (xxcopy, notepad, and del) are in one command
line, so you could specify just one command line in the target field in
a shortcut.

On 4/8/2024 8:10 PM, VanguardLH wrote:
> "John C." <r9jmg0@yahoo.com> wrote:
>
>> Paul wrote:
>>> MikeS wrote:
>>>> John C. wrote:
>>>>>
>>>>> Whenever I run a command in a command prompt window, I can see what's
>>>>> happening as it does. However, upon completion it the window resets to
>>>>> basically a clear screen so that I'm unable to see what was done. Can
>>>>> anybody tell me how to stop it from doing this? I never had this problem
>>>>> in Windows 7.
>>>>>
>>>>> TIA
>>>>>
>>>> I have also never had that problem in Windows 8, 10 or 11.
>>>> What command(s) are you running?
>>>
>>> Doing "cls" in a Microsoft window, seems to be a built-in
>>> and it also happens to clear the scrollback.
>>>
>>> That's not the same as Formfeed, which would not affect the scrollback.
>>>
>>> 014 12 0C FF '\f' (form feed)
>>>
>>> Since "cls" is a built-in, even if you used ProcMon, there would
>>> be no trace of it (no trace of cls.exe loading).
>>>
>>> If the OP was using a .bat file, perhaps some clever
>>> individual put a "cls" in there.
>>
>> No, I'll explain. I'm running XXCopy by Pixelab, Inc. It's a freeware
>> command line program who's author is now passed away. I have shortcuts
>> to the program, all for synchronizing different folders with similarly
>> named folders on other internal hard drives. Here's an example of the
>> Target line of one such shortcut:
>>
>> C:\WINDOWS\system32\cmd.exe /k C:\WINDOWS\system32\xxcopy.exe "C:\1\"
>> "E:\1\" /clone /YY /k
>>
>> where C:\1 and E:\1 are just examples of source and destination folders.
>>
>> Sorry about the line wrapping. I'm still having fits with Thunderbird
>> after I went from W7 to W10.
>>
>> When I run a shortcut like that, I can see the new files in the first
>> folder scroll by in the command line window. However, once the program
>> has run, it's as if I ran a CLS command which cleared the window. This
>> is not what I want, because I want to be able to scroll upwards on the
>> screen to see what changes were made to the destination folder. In
>> Windows 7, this was easily possible. In Windows 10 though, that
>> seemingly automatic CLS command gets run and I lose the information I need.
>>
>> Hope this helps you understand my dilemma.
>
> Despite some 'cls' effect after running xxcopy, that doesn't mean you
> must lose all of xxcopy's output. It writes to stdout, so just redirect
> stdout to a file (already mentioned by me, and added upon by Paul):
>
> xxcopy ... > log.txt
> ^
> or |---- very easy to add to the command
> V
> xxcopy ... >> log.txt
>
> A single greater-than overwrites (without prompt) the file if it
> currently exists. A double greater-than appends to the file. If you
> don't want the text file in the same folder where you run xxcopy, add a
> path to it, like d:\temp\log.txt. Really simple. ANYTHING that xxcopy
> outputs will go to the text file. Doesn't matter whether the shell's
> window got cleared or closed. The stdout got captured in the text file
> while xxcopy was running.
>
> Besides the copy operation getting recorded, you could see if xxcopy
> issued some error that might've caused the 'cls' effect.
>
> Something goofy is happening with xxcopy, but the workaround is easy.
> In fact, since you want to see the output, and using an editor lets you
> more easily scroll and even search, you could have Notepad load the log
> file, as in:
>
> xxcopy ... > log.txt && notepad log.txt
>
> While xxcopy.exe is an executable program, you don't really need cmd.exe
> to load a shell in which to run xxcopy. The "cmd /c" or "cmd /k" isn't
> needed. However, if any commands are internal to the command
> interpreter (cmd.exe), yep, you need to call cmd.exe to run its args.
>
> dir c:\ > log.txt && notepad log.txt && del log.txt
>
> would result in an unknown command error, because there is no dir.exe
> program to be found in the current directory nor in the PATH environment
> variable. So, if using internal commands, use:
>
> cmd /c dir c:\ > log.txt && notepad log.txt && del log.txt
>
> Here I used /c instead of /k, because there is no need to keep the shell
> window open. The intent is to see the stdout of the program, and by
> using Notepad which is a lot easier than trying to scroll around inside
> a shell window (and gets truncated if you don't define a big enough
> buffer).
>
> A single ampersand runs the next command if errorlevel was zero from the
> prior command, but a double ampersand runs the next command regardless
> of fail/succeed of the prior command. You don't even need to use
> cmd.exe to load a shell to run xxcopy. Just run xxcopy, copy its stdout
> into a file, and open that file in Notepad. If you don't want the file
> lingering around after viewing in Notepad, use:
>
> xxcopy ... > log.txt && notepad log.txt && del log.txt
>
> All of those commands (xxcopy, notepad, and del) are in one command
> line, so you could specify just one command line in the target field in
> a shortcut.
>

I think you have & and && backwards:
&& executes this command only if previous command's errorlevel is 0 or
SUCCESSFUL