Hello folks - I'm new here...

I'm using XXCOPY to update a backup held on a network disk (connected
to a Linksys an NSLU2) and it's not doing what I expected.

I want to update changed files, and copy new files, so I used:

XXCOPY S:*.* T: /BN /S

And it did one of three things with each file:

- Copied it
- said "Same Time"
- asked "Overwrite (Y/N/A)?"

It's the third one that I wasn't expecting - all the files it asked
about were present on the backup and had the same size/date/time, so
should have been skipped with "Same Time".

As this is going from NTFS to whatever a network disk looks like, I
added the /FF time to give it some leeway on the time matching, but
the result was the same.

The annoying thing is that there is no "No to all" option on the
prompt itself, or on any parameter that I could find - it's as if the
authors really want to make sure you don't miss anything!  :-)  I can
understand it slightly, in that the main selection process should
eliminate files that aren't needed, but it's failing to do so, and I
can't find a way to get that right.

Is this a bug, or is there some other subtle aspect that I've missed?

If you want to learn about Effective Software Testing? How do we
measure `Effectiveness' of Software Testing? Steps to Effective
Software Testing. Following URL help you a lot!!

http://top-itarticles.com/softtest/softtest08.asp

I've been able to get SP3 for my Windows XP(don't ask how!)
My problem is that XXCOPY generates an operating system incompatible
error message and waits 2 minutes before continuing, because it sees I
have SP3 installed.
My question is how can I make XXCOPY skip the service pack version check.
I've tried the latest xxcopy version and used /wv0 with no change.

Please read this message carefully before responding. Thanks Stu

--- In xxcopy@yahoogroups.com, "stubriggs" <stubriggs@...> wrote:
>
> I've been able to get SP3 for my Windows XP(don't ask how!)
> My problem is that XXCOPY generates an operating system
> incompatible error message and waits 2 minutes before continuing,
> because it sees I have SP3 installed.
> My question is how can I make XXCOPY skip the service pack version
> check. I've tried the latest xxcopy version and used /wv0 with no
> change.
>
> Please read this message carefully before responding. Thanks Stu

You don't say but I assume you are using the Freeware version 2.95.3.
There is a later beta version 2.95.4 available at
http://www.xxcopy.com/betatest/ but I suspect that won't solve
your problem. Worth a try though.

Possible solutions are:

- get the Pro version. /wv0 works with that.
- wait for the next version of xxcopy. If the compilation date
of xxcopy is newer than the timestamps of user32.dll and
kernel32.dll, xxcopy doesn't issue the warning.
- backdate the 2 files user32.dll and kernel32.dll to a date
earlier than xxcopy.exe's date. You'll need to do this in DOS or
some other OS such as Bart PE since you won't be able to change
the date of these files while XP is running. You could also try
sysinternals.com MOVEFILE to replace the files at boot time with
the backdated versions but I haven't tried this myself.
- use a debugger to bypass xxcopy's OS check code. There's been
some posts on this previously but the specific changes are
dependent on the xxcopy version so you'll need to find the
bytes to change. These Yahoo posts refer:
http://tech.groups.yahoo.com/group/xxcopy/message/9665
http://tech.groups.yahoo.com/group/xxcopy/message/12742

Garry

--- In xxcopy@yahoogroups.com, "hdrw54" <HDRW_Yahoo@...> wrote:
>
> Hello folks - I'm new here...
>
> I'm using XXCOPY to update a backup held on a network disk
> (connected to a Linksys an NSLU2) and it's not doing what I
> expected.
>
> I want to update changed files, and copy new files, so I used:
>
> XXCOPY S:*.* T: /BN /S
>
> And it did one of three things with each file:
>
> - Copied it
> - said "Same Time"
> - asked "Overwrite (Y/N/A)?"
>
> It's the third one that I wasn't expecting - all the files
> it asked about were present on the backup and had the same
> size/date/time, so should have been skipped with "Same Time".
>
> As this is going from NTFS to whatever a network disk looks
> like, I added the /FF time to give it some leeway on the time
> matching, but the result was the same.
>
> The annoying thing is that there is no "No to all" option on
> the prompt itself, or on any parameter that I could find -
> it's as if the authors really want to make sure you don't
> miss anything!  :-)  I can understand it slightly, in that
> the main selection process should eliminate files that aren't
> needed, but it's failing to do so, and I can't find a way to
> get that right.
>
> Is this a bug, or is there some other subtle aspect that
> I've missed?

You're right that you normally use the selection switches to
exclude files that you don't want to overwrite and you're also
right that /FF should have done the trick if the network drive
is FAT and therefore has minor differences in the timestamps.

I suspect that the problem may be with the network drive. I've
had weird problems with these drives before and I think it may
relate to how the OS/network API's are implemented by the drive.

I can only suggest narrowing down the problem to one or a small
number of files and confirm that xxcopy is really copying
files that are the same size/time. You could try copying a file
in both directions e.g. copy from the local drive to the network
drive then copy it back to see if xxcopy skips it. You could also
try experimenting with similar xxcopy switches to see whether
xxcopy will skip these files. Some things to try:

- use /d instead of /bn. /d will copy newer files but doesn't
look at the file size like /bn does.
- use /bz instead of /bn. This will skip files that have the
same size.
- try using a wider /FF range. It could be that the network
drive is not implementing time zone standards and UTC correctly.
You could also try the /fu and /fL switches to see it that makes
a difference.

Beyond that I'm stumped. In my case, I simply gave up on using
the network drive for the purpose I had in mind.

Garry

Hi Lester-

The line you use...

xxcopy "c:\my digital copies\"  "e:\my digital copies\" /BI/E/Y/FF

seems similar to just using the switches /Clone and /FF.  Maybe this
has changed recently, but /Clone at least used to be the equivalent of
all the separate switches you mentioned (neglecting /FF for NTFS,
etc.), along with a few more which seem pretty useful and harmless
(see below)).  As far as I can tell, the most significant addition is
/ZY, the switch which gets rid of any files or folders on the target
which are not on the source.  If you leave out that function, you can
amass many extra files and folders if you do much renaming (like I do).

I hope this little chart below prints properly on this forum....

John

-----

/CLONE = all following switches:

/KS /H /E /R /Q /Y /BI /ZY /ZE /oD0.
  |   |  |  |  |  |  |   |   |   |
  |   |  |  |  |  |  |   |   |   Deleted-file list = 0
  |   |  |  |  |  |  |   |   Disables Env Variables use for XXCopy
  |   |  |  |  |  |  |   Deletes extra files/subdirs in destination
  |   |  |  |  |  |  |   with no confirmation prompts
  |   |  |  |  |  |  Backs up incrementally, different (time/size)
  |   |  |  |  |  |   files only
  |   |  |  |  |  Overwrites existing files without prompt
  |   |  |  |  Does not display files which are skipped
  |   |  |  Allows overwrite/delete read-only files
  |   |  Copies directories & subdirectories, including empty ones
  |   Copies hidden a/o system files also
  Keeps source attributes whose RDONLY bit is normally reset

















--- In xxcopy@yahoogroups.com, "Lester A. Pfeffer" <lespfeffer@...> wrote:
>
> John (whatever #) ... I understand what you are saying, and in general,
> I completely agree with you about the complexity of the switches.
> However, I do not try to use any of the exotic switches --I just use
> XXCOPY (very effectively, I must say) for simple backup of my files.  I
> use the following line for backing up whatever I may have changed, for
> example, in the directory "my digital copies" on the c: drive (i.e., my
> PC), to the e: drive, which is a backup drive, or maybe a DVD:
>
> ***
> xxcopy "c:\my digital copies\"  "e:\my digital copies\" /BI/E/Y/FF
> ***
>
> The upper -lower case usage is my preference.  But the usage of the
> quotation marks as shown, is of course, essential, where there are
> spaces in the title of the directory, or a file name.  They may also be
> necessary where the title is more than eight characters.  The "BI" is
> for incremental backups -- it checks for both the file size and file
> date.  "BU" is intended for (the first) full backup, but I have used
> "BI" for the original full backup with no problems.  The original XCOPY
> (in the old DOS days) only checked for the archive bit, and reset
it, so
> you could only use it once.  I use XXCOPY to backup to both my set of
> DVDs, and to an external hard drive.  And I also backup to another hard
> drive every month or so, which I keep away from mp PC.
>
> Hope this helps -- Lester A. Pfeffer -- OnlyMeters1932
>
>
> jdhite1 wrote:
> >
> > John-
> >
> > I understand. XXcopy already has an impressive (if not overwhelming)
> > number of switches and options. It makes you wonder how anyone can
> > keep track of them all, not to mention the interactions between them.
> >
> > John (#1?)
> >
> > --- In xxcopy@yahoogroups.com <mailto:xxcopy%40yahoogroups.com>,
"John
> > Zeman" <john041650@> wrote:
> > >
> > > --- In xxcopy@yahoogroups.com <mailto:xxcopy%40yahoogroups.com>,
> > "jdhite1" <jdhite1@> wrote:
> > > > But if so, I wonder why it doesn't do the same
> > > > thing when used with /clone?
> > >
> > >
> > > Because as you suggested in your first post here, exclusions only
> > > apply to the source.
> > >
> > > On the surface it would appear to make sense to also apply
exclusions
> > > (and other options) to the destination. However when you factor in
> > > all of the other options xxcopy has, and how all of those
options have
> > > to work together in different combinations, you can see how quickly
> > > things could become a nightmare if very many options applied to both
> > > the source and destination (example: Approximately 250 source
options
> > > x 250 destination options = approximately 62,500 possible
scenarios).
> > > Because of this potential technical coding problem the destination
> > > has only a few options that apply, by design the vast majority of
> > > options apply only to the source.
> > >
> > > John #2
> > >
> >
> >
>
>
> [Non-text portions of this message have been removed]
>

You gave me 4 options:
1)Get Pro version and use wv0 - Results Failed
2)Wait for newer version -
3)Backdate Win files user32.dll and kernel32.dll - Too much trouble
4)Change hex code in xxcopy.exe - Did not work for me in v2.95.3
Thanks for your great suggestions, but I guess I'm going to have just
to choose #2 for a newer version. Thanks Stu





--- In xxcopy@yahoogroups.com, "Garry Deane" <garrydeane@...> wrote:
>
> --- In xxcopy@yahoogroups.com, "stubriggs" <stubriggs@> wrote:
> >
> > I've been able to get SP3 for my Windows XP(don't ask how!)
> > My problem is that XXCOPY generates an operating system
> > incompatible error message and waits 2 minutes before continuing,
> > because it sees I have SP3 installed.
> > My question is how can I make XXCOPY skip the service pack version
> > check. I've tried the latest xxcopy version and used /wv0 with no
> > change.
> >
> > Please read this message carefully before responding. Thanks Stu
>
> You don't say but I assume you are using the Freeware version 2.95.3.
> There is a later beta version 2.95.4 available at
> http://www.xxcopy.com/betatest/ but I suspect that won't solve
> your problem. Worth a try though.
>
> Possible solutions are:
>
> - get the Pro version. /wv0 works with that.
> - wait for the next version of xxcopy. If the compilation date
> of xxcopy is newer than the timestamps of user32.dll and
> kernel32.dll, xxcopy doesn't issue the warning.
> - backdate the 2 files user32.dll and kernel32.dll to a date
> earlier than xxcopy.exe's date. You'll need to do this in DOS or
> some other OS such as Bart PE since you won't be able to change
> the date of these files while XP is running. You could also try
> sysinternals.com MOVEFILE to replace the files at boot time with
> the backdated versions but I haven't tried this myself.
> - use a debugger to bypass xxcopy's OS check code. There's been
> some posts on this previously but the specific changes are
> dependent on the xxcopy version so you'll need to find the
> bytes to change. These Yahoo posts refer:
> http://tech.groups.yahoo.com/group/xxcopy/message/9665
> http://tech.groups.yahoo.com/group/xxcopy/message/12742
>
> Garry
>

--- In xxcopy@yahoogroups.com, "stubriggs" <stubriggs@...> wrote:
>
> You gave me 4 options:
> 1)Get Pro version and use wv0 - Results Failed
> 2)Wait for newer version -
> 3)Backdate Win files user32.dll and kernel32.dll - Too much trouble
> 4)Change hex code in xxcopy.exe - Did not work for me in v2.95.3
> Thanks for your great suggestions, but I guess I'm going to have
> just to choose #2 for a newer version. Thanks Stu
>

I take it from your reply that you are using the Pro version. I
thought that /wv0 still worked on the Pro version but apparently
that is no longer the case.

As I understand it, the Pro version uses a different checking
mechanism to the Free version in that it checks the Service Pack
number stored at HKLM\Software\Microsoft\Windows NT\CurrentVersion\
CSDVersion.

I've no idea whether this will work or whether it might have other
consequences but you could try changing the Service Pack string
stored at HKLM\Software\Microsoft\Windows NT\CurrentVersion\
CSDVersion back to Service Pack 2.

Garry

Changing the Windows reg file did work, but it was only a temporary
fix, as soon as the computer is rebooted the registry resets back to
the original Service Pack 3 text string, but at least we found a solution.
Thank You for all your suggestions, you've been a really big help.
If you come up with any more suggestions I'd be glad to try them.


--- In xxcopy@yahoogroups.com, "Garry Deane" <garrydeane@...> wrote:
>
> I take it from your reply that you are using the Pro version. I
> thought that /wv0 still worked on the Pro version but apparently
> that is no longer the case.
>
> As I understand it, the Pro version uses a different checking
> mechanism to the Free version in that it checks the Service Pack
> number stored at HKLM\Software\Microsoft\Windows NT\CurrentVersion\
> CSDVersion.
>
> I've no idea whether this will work or whether it might have other
> consequences but you could try changing the Service Pack string
> stored at HKLM\Software\Microsoft\Windows NT\CurrentVersion\
> CSDVersion back to Service Pack 2.
>
> Garry
>

--- In xxcopy@yahoogroups.com, "stubriggs" <stubriggs@...> wrote:
>
> Changing the Windows reg file did work, but it was only a
> temporary fix, as soon as the computer is rebooted the registry
> resets back to the original Service Pack 3 text string, but at
> least we found a solution.
> Thank You for all your suggestions, you've been a really big
> help. If you come up with any more suggestions I'd be glad to
> try them.

OK, that's good to know. As a stop-gap until Kan updates xxcopy
for XP-SP3, you could automate the registry change as part of
your xxcopy batch file(s) using either REG or REGEDIT.

If you are confident that the registry change isn't affecting
anything else on the system, you could make the change as part
of your startup commands so it would be set at boot time. If
you are less confident, you could change the registry value
before xxcopy runs then restore it after xxcopy finishes.

Garry

Good idea, I'll run an automated reg change for a while and watch for
any problems. Do I need to inform Kan of this problem or will he pick
it up from this forum? Thanks Stu

--- In xxcopy@yahoogroups.com, "Garry Deane" <garrydeane@...> wrote:

>
> OK, that's good to know. As a stop-gap until Kan updates xxcopy
> for XP-SP3, you could automate the registry change as part of
> your xxcopy batch file(s) using either REG or REGEDIT.
>
> If you are confident that the registry change isn't affecting
> anything else on the system, you could make the change as part
> of your startup commands so it would be set at boot time. If
> you are less confident, you could change the registry value
> before xxcopy runs then restore it after xxcopy finishes.
>
> Garry
>

--- In xxcopy@yahoogroups.com, "stubriggs" <stubriggs@...> wrote:
>
>
> Good idea, I'll run an automated reg change for a while and
> watch for any problems. Do I need to inform Kan of this problem
> or will he pick it up from this forum? Thanks Stu
>
Probably better to let Kan know directly. I don't know how regularly
he drops in on this forum. Since SP3 isn't an official release yet,
I don't know whether he would be able or prepared to issue an update
to support it without testing.

Garry

Hi,

My Pro version reports:
XXCOPY ver 2.93.1   2007-08-24 07:42:39   Windows Ver 5.2.3790
  Command Line  = XXCopy \\Max2k\Webdocs\ "D:\Web Documents\" /CLONE /YY /WV0 /FF
/oAD:\Scripts\Copy-WebDocs2Vijl.LOG /oF2 /oD2 /oE2 /Xfotos\pasfoto*.*
[....]
  Source base directory = "\\Max2k\Webdocs\"
  Destination directory = "D:\Web Documents\"
  File name template    = "*"
Invalid OS environment for this XXCOPY

So it seems it does not work even in an older 2.93 version.


Met vriendelijke groet,
Bonno Bloksma
hoofd systeembeheer



tio hogeschool hotelmanagement en toerisme
begijnenhof 8-12 / 5611 el eindhoven
t 040 296 28 28 / f 040 237 35 20
b.bloksma@...  / www.tio.nl
   ----- Original Message -----
   From: Garry Deane
   To: xxcopy@yahoogroups.com
   Sent: Friday, August 24, 2007 4:29 AM
   Subject: [xxcopy] Re: 2.95.4 version, when?


   --- In xxcopy@yahoogroups.com, "Bonno Bloksma" <b.bloksma@...> wrote:
   >
   > Hi,
   >
   > As I'm getting these "nice" 2min wait screens now on my Win2k3Sp2
   > server I'd like to upgrade but.... The 2.95.3 version has the
   > timeinfo bug. The 2.95.4 version is still in beta. :-(
   >
   > The 2.95.4 version has been in beta now for almost 2 months,
   > anybody found any problems? Have there been different beta
   > versions or has the 2.95.4 version not seen any change after
   > it's release?
   >
   > Can I use it to overwrite my pro version or should I wait? I
   > just downloaded the latest pro version but it's still 2.95.3 :-(
   >
   >
   > Met vriendelijke groet,
   > Bonno Bloksma
   > hoofd systeembeheer

   I've been using 2.95.4 for a while now and haven't seen any
   problems. I find that it's usually safe to use the beta version
   if no bugs have been reported within a few weeks or when the
   changes noted in the Revision History at:
   http://www.xxcopy.com/betatest/xxcopy99.htm
   are of a minor nature.

   Also, if you are using the Pro version, I believe that you can
   still use the /WV0 switch to suppress the version warning. It's
   now undocumented and doesn't work in the free version but it
   still worked some time ago when I had a need for it.

   Garry




   Yahoo! Groups Links





[Non-text portions of this message have been removed]

Hi, All.

This is our first official release of XXCOPY that conforms
to the Windows Vista environment.

Since we were also new to the Vista UAC scheme like, it took
a lot longer (more than a year) than usual for this release.

We just uploaded a new version of XXCOPY (ver 2.96.0).

     http://www.xxcopy.com/betatest

The download package for this version for this version is much
bigger than any previous version (about three times larger than
before).

It contains the following new files.

     xxcopysu.exe     // standard user version
     xxconsole.exe    // Super Console Generator (a new tool)
     xxcopy.chm       // John Zeman's help file

The XXCOPY.EXE file is still the main program file that is good
for all occasions.  It has an embedded manifest which declares
the requirement for the administrator privileges that is used
for the UAC elevation procedure.

The XXCOPYSU.EXE file is identical to XXCOPY.EXE except that
the embedded manifest specifies the "asInvoker" execution.
You may use this version when you log-in as a standard (i.e.,
non-administrator) user on Windows Vista and you do not want
to elevate the UAC privilege to the administrator level.
In such a case, XXCOPYSU's attempt to perform a operation that
requires the administrator privilege (e.g., copying a file
into the root directory) will fail due to the lack of privileges.

If you plan to launch XXCOPY repeatedly from a console window
(DOS Box), you should open the DOS Box with the elevated UAC
in the first place so that the UAC-related prompt can be
dismissed once for all at the beginning.  It is especially true
when you run a batch file which contains multiple invocations
of programs that require the admin privilege.

For details on the UAC-related issues, we prepared a new
technical bulletin (XXTB #42)

    http://www.xxcopy.com/betatest/xxcopy42.htm

To make your life easier in the Vista environment, at the
installation time, XXCOPY will create a "Super Console" shortcut
on the Desktop which will facilitate the creation of the
Administrator DOS Box.  As a bonus feature, we created
a new stand-alone tool called XXConsole with which you can
create a customized DOS Box with or without the administrator
privilege.

    http://www.xxcopy.com/betatest/xxcopy43.htm

For the time being, we will take a closer look at this
forum for user feedback.  You may also send us (tech @ xxcopy.com)
questions or Emails.

Kan Yabumoto

Hello,

since more then three years I made my backups on a WinME system with xxcopy with
no problems.

Now, since 3 month I am working with WinXP. With the Freeware-Version of xxclone
I make a bootable backup and I can boot from this
backup.

But the freeware of xxclone can't do incrementally backups, so my question is:

Makes the newest Version from xxcopy in WinXP Prof. the same good works as in
WinMe?

In the Technical Bulletin I can't find anyone, that xxcopy now works more exacly
in WinXP as in the past. I know that in the past
xxcopy had importend problems with WinXP and therefore was created xxclone.

maneich

maneich  wrote:

<snip>

  > But the freeware of xxclone can't do incrementally backups, so my
  > question is:
  > Makes the newest Version from xxcopy in WinXP Prof. the same good
  > works as in WinMe?

The Win 9X/ME disks were essentially the same as the DOS disks
which did not require any special operations on the disk to make
the disk self-bootable.  It was not difficult to create a bootable
disk using common file-copy tools.  (But, to do it right, the SFN-LFN
relationship must be properly preserved (XXCOPY was one such tool).)

The detail was described in XXTB #10:

     http://www.xxcopy.com/xxcopy10.htm

However, the same trick of simply copying all the files would not
create a bootable disk in the Win NT/2K/XP.  Simply put, the job
is beyond the scope of XXCOPY.  Please remember that XXCOPY has
never been written as a tool to make a bootable system disk.
It has been (and will remain) a versatile file management tool
to cover a very wide range of file operations.  One of the reasons
why XXCOPY can't make a bootable clone of the system disk is
that we program XXCOPY using only the standard file/directory
I/O Win32 API functions.  We deliberately do not use any low-level
disk access functions in XXCOPY.  This makes XXCOPY a
"well-behaving", "device-independent" program.  The benefit is
that we can safely proclaim that XXCOPY cannot turn a healthy
disk volume into a corrupted volume (if that ever happens, the
blame would be placed on the code for the file system driver
--- typically provided by Microsoft).  Also, XXCOPY is not capable
of accessing the system registry files in the NT/2K/XP environment.
Since a good backup copy of the system volume need the latest
copy of the system registry, XXCOPY just cannot be a good tool
to make a bootable system backup.

Anyway, to make the long story short, we introduced XXCLONE
which does not refrain from accessing disk sectors using the
low-level device I/O techniques (of course, we are extremely
conservative in determining whether the partition's characteristics
are sufficiently safe to modify without the risk of corrupting
a healthy volume).

The reason why the freeware can't perform the incremental backup is
not for technical reasons.  We just can't give away everything.
We have to maintain a delicate balance so that the paid customers
will feel that the enhanced features in the Pro version justify
the price.

Kan Yabumoto

I haven't felt the need to do incremental xxclone backups (yet).  Once
I created the clone on my second internal hard drive and successfully
booted from it I felt that incremental backups were only needed for
data, which XXcopy handles just fine on XP.

In addition, one of the worries for me with doing frequent backup of
the system, which overwrite the old one, is that if my system is
becoming faulty in some way that I haven't yet realized, the backup
will also be faulty.

When my original main drive failed I found that booting to the backup
which hadn't been updated with xxclone since it was created, with all
the data up to date, was a painless operation.  Then I simply cloned
from the backup to a new drive and things were rosy.

Virg

Virg wrote:

  > I haven't felt the need to do incremental xxclone backups (yet).
  > Once I created the clone on my second internal hard drive and
  > successfully booted from it I felt that incremental backups
  > were only needed for data, which XXcopy handles just fine on XP.

The /HyperSync incremental backup in XXCLONE runs much faster
than XXCOPY's /BACKUP or /CLONE when you do it frequently.
That's because the /HyperSync scheme skips the whole directory
which has not been accessed/modified since the previous backup.
When the number of files/directories increases, the benefit of
/HyperSync becomes significant.

We plan to implement the same thing with XXCOPY in the near future.
But, due to the very large number of variations in the way
backup operations are made, it is very hard to do it right....

  > In addition, one of the worries for me with doing frequent backup of
  > the system, which overwrite the old one, is that if my system is
  > becoming faulty in some way that I haven't yet realized, the backup
  > will also be faulty.

It is true.  That is why XXCLONE has an elaborate mechanism to
restore the system registry to specific date/week/month/year.
If you perform system backup every day using XXCLONE, you will have
plenty of choice in the restore points to revert to.  Even the default
settings will give you a reasonable set of restore points.

Saving a series of archived system registry files is one of the
things XXCLONE can do well but XXCOPY can't do (XXCOPY used to do
this well in Win9X environments).

As to the regular files, we always recommend multiple backup copies
(daily backup volume and weekly backup volume) for either XXCLONE
or XXCOPY.

Kan Yabumoto

I'm working on a synchronization routine that works pretty well,
except empty folder keep getting deleted.  It's a multi pass routine
using different XXCopy switches.  I sure could use some help with
why my one command lines isn't working right.

This is this first pass, and it deletes all data in a LIST FOLDER
that exists in the DESKTOP folder by way of the /RS command.  My
problem is it deletes the empty folders when I need them to stay
unless they've been removed from the DESKTOP.  So what I'm trying to
achieve with this first pass is this.  I use the list folder to
determine what gets deleted from the backup server.  This process
runs and deletes all data in the list folder that exist in the
destination folder, which is really my local Desktop folder.  That
way if before this proess ran, had I deleted a file off my desktop,
it would be left in the LIST FOLDER after this first pass.  Then on
the second pass it uses what's left in the list folder to delete
what's on the BACKUP SERVER.  Then any new or newer data is copied
down from the backup server to the local desktop in the next pass.
The steps are listed below.  The problem is, when the first command
line runs, it'n not leaving an empty folder in the LIST FOLDER if
I've deleted from the Desktop folder.  Hopefully your not lost now
by reading this, but it's pretty simple.  I just can't figure out
why the empty folders get deleted when they shouldn't.  I've tried
numerous variation of this string with other switches.

xxcopy source dest  /RS /BS /E /ED1 /YY

/RS  Removes files in src which qualify (no copying).
/E  Copies directories and subdirectories, including empty ones.
/ED1 Preserves root directory from being deleted.
/BS  Selects exactly the same files (this is useful with /RS).
/YY  Suppresses ALL prompts unconditionally (good in a batch script).

Below is how the six passes work.  The list folder is created before
it gets to these routines.

1. Deletes all data in the LIST FOLDER that exists in the Local
destination folder by way of the /RS command
2. Removes all data in the BACKUP FOLDER that exists in the LIST
FOLDER.
3. Copies all new or newer data from the BACKUP FOLDER to the local
destination folder.
4. Removes all data in the Desktop FOLDER that exists in the LIST
FOLDER. (Can't remember why I had this routine here, buts it's not
the issue right now.)
5. Copies all new or newer data from the DESKTOP FOLDER to the USHARE
6. Creates a fresh file reference list.

Thanks for any help, Ken.

Sorry, the command line is:
xxcopy source dest /RS /U /E /ED1 /H /R /YY
not
xxcopy source dest /RS /BS /E /ED1 /H /R /YY

--- In xxcopy@yahoogroups.com, "kenxxcopy" <kenxxcopy@...> wrote:
>
> I'm working on a synchronization routine that works pretty well,
> except empty folder keep getting deleted.  It's a multi pass
routine
> using different XXCopy switches.  I sure could use some help with
> why my one command lines isn't working right.
>
> This is this first pass, and it deletes all data in a LIST FOLDER
> that exists in the DESKTOP folder by way of the /RS command.  My
> problem is it deletes the empty folders when I need them to stay
> unless they've been removed from the DESKTOP.  So what I'm trying
to
> achieve with this first pass is this.  I use the list folder to
> determine what gets deleted from the backup server.  This process
> runs and deletes all data in the list folder that exist in the
> destination folder, which is really my local Desktop folder.  That
> way if before this proess ran, had I deleted a file off my
desktop,
> it would be left in the LIST FOLDER after this first pass.  Then
on
> the second pass it uses what's left in the list folder to delete
> what's on the BACKUP SERVER.  Then any new or newer data is copied
> down from the backup server to the local desktop in the next
pass.
> The steps are listed below.  The problem is, when the first
command
> line runs, it'n not leaving an empty folder in the LIST FOLDER if
> I've deleted from the Desktop folder.  Hopefully your not lost now
> by reading this, but it's pretty simple.  I just can't figure out
> why the empty folders get deleted when they shouldn't.  I've tried
> numerous variation of this string with other switches.
>
> xxcopy source dest  /RS /BS /E /ED1 /YY
>
> /RS  Removes files in src which qualify (no copying).
> /E  Copies directories and subdirectories, including empty ones.
> /ED1 Preserves root directory from being deleted.
> /BS  Selects exactly the same files (this is useful with /RS).
> /YY  Suppresses ALL prompts unconditionally (good in a batch
script).
>
> Below is how the six passes work.  The list folder is created
before
> it gets to these routines.
>
> 1. Deletes all data in the LIST FOLDER that exists in the Local
> destination folder by way of the /RS command
> 2. Removes all data in the BACKUP FOLDER that exists in the LIST
> FOLDER.
> 3. Copies all new or newer data from the BACKUP FOLDER to the
local
> destination folder.
> 4. Removes all data in the Desktop FOLDER that exists in the LIST
> FOLDER. (Can't remember why I had this routine here, buts it's not
> the issue right now.)
> 5. Copies all new or newer data from the DESKTOP FOLDER to the
USHARE
> 6. Creates a fresh file reference list.
>
> Thanks for any help, Ken.
>

--- In xxcopy@yahoogroups.com, "kenxxcopy" <kenxxcopy@...> wrote:
>
> Sorry, the command line is:
> xxcopy source dest /RS /U /E /ED1 /H /R /YY
> not
> xxcopy source dest /RS /BS /E /ED1 /H /R /YY
>
> --- In xxcopy@yahoogroups.com, "kenxxcopy" <kenxxcopy@> wrote:
>>
>> I'm working on a synchronization routine that works pretty well,
>> except empty folder keep getting deleted.  It's a multi pass
>> routine using different XXCopy switches.  I sure could use some
> help with why my one command lines isn't working right.
<snip>

It's not clear what you are specifying as the source directory
relative to where the list directory is located.

As you've rightly pointed out, /ED1 only preserves the top level
(base) directory and will delete all lower level directories. If
you specify say c:\test\ as the source base path, then
c:\test\list\ will be deleted if it's empty. If you use wildcards
such as c:\*\list\ for the source, the base path is c:\ and
c:\test\ and all lower levels will be deleted if they're empty.

Perhaps you want /ED so that all empty directories are preserved?

Garry

I'll try to explain this again more clearly.  It can be confusing
even when I try to remember the logic behind it.

I'm backing up data from workstations and laptops to a server store.
It's a multi pass process to similute synchronization.
Three locations are involved.
1. The source (Users Desktop Folder)
2. The DEKSTOP LIST FOLDER - I use this to keep track of what should
be deleted off the server.(c:\vspsyncxp\list\username\desktop)
3. The destination (\\server\shares\usersname\desktop)

When the program starts a master DESKTOP LIST FOLDER of zero byte
files is created.  This list is used to determin what should be
deletd off the server.

xxcopy DESKTP LISTFOLDER /KS /BX /H /E /R /Q /Y /ZY /TR0 /CCY /N0 /yy

So lets say on my DESKTOP I have files named LOCAL.TXT and LOCAL2.TXT
In the DESKTOP LIST FOLDER there will be zero byte copies of
LOCAL.TXT and LOCAL2.TXT that was created when the backup program
starts.

If I delete LOCAL.TXT off my desktop, the next time the sync process
runs the following steps occur:

1. Deletes all data in the DEKSTOP LIST FOLDER that exists in the
usres DESKTOP folder by way of the /RS /U command.  By doing this
the only data that should be in the DESKTOP LIST FOLDER is what has
been deleted from the DESKTOP folder. So because I deleted LOCAL.TXT
from my DESKTOP, the zero byte copy will remain in the DESKTOP LIST
FOLDER due to the /RS /U switchs.  Now I have a record of what
should be deleted off the SERVER.

XXCOPY LISTFOLDER DESKTOP /RS /U /ED1 /E /H /R /YY


2. Removes all data in the SERVER FOLDER that exists in the DESKTOP
LIST FOLDER due to the /RS /U switchs. So now everything I've delete
off my DESKTOP (LOCAL.TXT) has been delete off the SERVER.

XXCOPY SERVER LISTFOLDER /RS /U /H /ED1 /E /R /YY


3. Next the program copies all new or newer data (/DA) from the
SERVER FOLDER to the local DESKTOP folder. So, if they had logged
into another computer and had newer data on the server, it would be
copied down to this pc.

XXCOPY SERVER DESKTOP /E /S /I /H /R /DA /N0 /YY


4. Backup all data from the DESKTOP FOLDER to the SERVER. At this
point the DESKTOP and SERVER have identical data.

XXCOPY DESKTOP SERVER /BU /CK0 /OD2 /OE2 /OF2 /NI /N0 /YY


5. Creates a new zero byte DESKTOP LIST FOLDER with all the DESKTOP
data in it.  This is what will be used next time the process run to
determine what should be deleted off the server.

xxcopy DESKTP LISTFOLDER /KS /BX /H /E /R /Q /Y /ZY /TR0 /CCY /N0 /yy

Problem is, when I do what I just explained with an EMPTY desktop
folder, the EMPTY folder won't stay in the DESKTOP LIST FOLDER
during the first backup pass.  It needs to stay there so it can be
deleted off the SERVER in the second pass.  But because it doesn't
get deleted in the second pass, it copies back down to the DESKTOP
from the SERVER in the third pass.

This process works great except with empty folders.

Note: if I don't user the /ED1 switch during the removal process,
the DESKTOP folder, DESKTOP LISTFOLDER, and the SERVER desktop
folder will be delted if there is no data on the DESKTOP.  If I use
just /ED then no empty folders are ever deleted.

--- In xxcopy@yahoogroups.com, "Garry Deane" <garrydeane@...> wrote:
>
> --- In xxcopy@yahoogroups.com, "kenxxcopy" <kenxxcopy@> wrote:
> >
> > Sorry, the command line is:
> > xxcopy source dest /RS /U /E /ED1 /H /R /YY
> > not
> > xxcopy source dest /RS /BS /E /ED1 /H /R /YY
> >
> > --- In xxcopy@yahoogroups.com, "kenxxcopy" <kenxxcopy@> wrote:
> >>
> >> I'm working on a synchronization routine that works pretty
well,
> >> except empty folder keep getting deleted.  It's a multi pass
> >> routine using different XXCopy switches.  I sure could use some
> > help with why my one command lines isn't working right.
> <snip>
>
> It's not clear what you are specifying as the source directory
> relative to where the list directory is located.
>
> As you've rightly pointed out, /ED1 only preserves the top level
> (base) directory and will delete all lower level directories. If
> you specify say c:\test\ as the source base path, then
> c:\test\list\ will be deleted if it's empty. If you use wildcards
> such as c:\*\list\ for the source, the base path is c:\ and
> c:\test\ and all lower levels will be deleted if they're empty.
>
> Perhaps you want /ED so that all empty directories are preserved?
>
> Garry
>

--- In xxcopy@yahoogroups.com, "kenxxcopy" <kenxxcopy@...> wrote:
>
> I'll try to explain this again more clearly.  It can be confusing
> even when I try to remember the logic behind it.
>
> I'm backing up data from workstations and laptops to a server
> store. It's a multi pass process to similute synchronization.
> Three locations are involved.
> 1. The source (Users Desktop Folder)
> 2. The DEKSTOP LIST FOLDER - I use this to keep track of what
> should be deleted off the server.
>(c:\vspsyncxp\list\username\desktop)
> 3. The destination (\\server\shares\usersname\desktop)
>
> When the program starts a master DESKTOP LIST FOLDER of zero byte
> files is created.  This list is used to determin what should be
> deletd off the server.
>
> xxcopy DESKTP LISTFOLDER
> /KS /BX /H /E /R /Q /Y /ZY /TR0 /CCY /N0 /yy
>
> So lets say on my DESKTOP I have files named LOCAL.TXT and
> LOCAL2.TXT
> In the DESKTOP LIST FOLDER there will be zero byte copies of
> LOCAL.TXT and LOCAL2.TXT that was created when the backup program
> starts.
>
> If I delete LOCAL.TXT off my desktop, the next time the sync
> process runs the following steps occur:
>
> 1. Deletes all data in the DEKSTOP LIST FOLDER that exists in the
> usres DESKTOP folder by way of the /RS /U command.  By doing this
> the only data that should be in the DESKTOP LIST FOLDER is what has
> been deleted from the DESKTOP folder. So because I deleted
> LOCAL.TXT from my DESKTOP, the zero byte copy will remain in the
> DESKTOP LIST FOLDER due to the /RS /U switchs.  Now I have a
> record of what should be deleted off the SERVER.
>
> XXCOPY LISTFOLDER DESKTOP /RS /U /ED1 /E /H /R /YY
>
>
> 2. Removes all data in the SERVER FOLDER that exists in the DESKTOP
> LIST FOLDER due to the /RS /U switchs. So now everything I've
> delete off my DESKTOP (LOCAL.TXT) has been delete off the SERVER.
>
> XXCOPY SERVER LISTFOLDER /RS /U /H /ED1 /E /R /YY
>
<snip>
>
> Problem is, when I do what I just explained with an EMPTY desktop
> folder, the EMPTY folder won't stay in the DESKTOP LIST FOLDER
> during the first backup pass.  It needs to stay there so it can be
> deleted off the SERVER in the second pass.  But because it doesn't
> get deleted in the second pass, it copies back down to the DESKTOP
> from the SERVER in the third pass.
>
> This process works great except with empty folders.
>
> Note: if I don't user the /ED1 switch during the removal process,
> the DESKTOP folder, DESKTOP LISTFOLDER, and the SERVER desktop
> folder will be delted if there is no data on the DESKTOP.  If I use
> just /ED then no empty folders are ever deleted.

I didn't try to duplicate all the steps you have listed but I
mimicked your first steps of creating a LISTFOLDER directory then
ran your first /RS/U/ED1 command.

In all cases it left the LISTFOLDER directory in place whether the
DESKTOP directory was empty or not. The /ED1 command worked
exactly as expected.

Sorry, I can't see why your command is not working as expected.

Garry

I finally had a little free time to play with this new XXConsole Kan,
it does seem to make command line scripts much more user friendly on
Vista.  However I noticed that I only seem to be able to use the super
console while it's placed on the Vista desktop.  If I copy or move it
to any other folder it does not seem to function, is that to be expected?

On my Vista desktop I have successfully configured a few super console
icons which successfully run both CMD and 4NT scripts.

Many thanks for this little gem of a tool.

John

John  wrote:
  >
  > I finally had a little free time to play with this new XXConsole
  > Kan, it does seem to make command line scripts much more user
  > friendly on Vista. However I noticed that I only seem to be able
  > to use the super console while it's placed on the Vista desktop.
  > If I copy or move it to any other folder it does not seem to
  > function, is that to be expected?
  >
  > On my Vista desktop I have successfully configured a few super
  > console icons which successfully run both CMD and 4NT scripts.

John:

Can you clarify what did you move (and how)?

   http://www.xxcopy.com/img/xconicon.jpg

This page shows the icon images embedded inside the XXCONSOLE.EXE
file.  The first one with the yellow frame is meant to represent
the XXCONSOLE.EXE program as opposed to the remaining icon images
that are for the CMD.EXE console shortcuts.  Did you move the
XXCONSOLE.EXE program file from the "rightly place"
(XXCOPY installs the program at \windows\system32\ directory
with its shortcut created in the \user\public\desktop\).

   ----------------------------------------------------------------
    Among other things, Windows often shows some "dumb downed"
    version of things that impede operations of both novices
    and professionals.  Here, when I say \users\public\desktop\
    and try to view the directory contents using the Windows
    Explorer, the "desktop" directory a subdirectory inside
    the  \users\public\ directory always appear as "Public Desktop"
    rather than its true name "desktop".  (I still do not
    understand why the file size is shown in KB. And even
    a 1-byte file is shown as 1KB.)
   -----------------------------------------------------------------

The most likely scenario in this case is that the XXCONSOLE.EXE
program has a bug.  Please send me the troublesome shortcut file
(created by XXCONSOLE.EXE on the desktop) in the .ZIP format.
If you create a few variations in the way you move the XXCONSOLE.EXE
program and the end result (you may keep the numeric variation
without change (e.g., XXConsole(1).lnk,  XXConsonsole(2).lnk, etc.).

Here are other possibilities that I can think of...

I assume you copied the XXCONSOLE.EXE program file into another
directory.  At that time, are you sure that you were not fooled
by the "virtualized" object (that looks like it's there)?

For example, if you use an old version of XXCOPY on Vista and copy
files, the system may let you "copy" the files into the "restricted"
destination such as the root directory (or somewhere in
\program files\).  This may possibly cause problems with XXConsole.

When the new version of the XXCOPY (v.2.96.0) package is installed,
it creates a shortcut for the XXCONSOLE.EXE program as well as
the super console shortcut.

    -----------------------------------------------------------------
     One frustrating fact is that the icons displayed on the Desktop
     are heavily cached (buffered) in such a way that you may not
     immediately see the xxconsole-related shortcuts created when
     XXCOPY is installed.

     You may need to press <F5> or perform right-click > Refresh.
     Even with such a sequence, the XXCONSOLE.EXE shortcut does not
     show the proper icon unless an "icon change" is performed via
     the property sheet without any change --- I suspect that it's
     Vista's bug.
   ------------------------------------------------------------------

The XXCONSOLE.EXE shortcut should be displayed with the first
embedded icon (icon #0) within the XXCONSOLE.EXE program
(with the yellow outline).  The yellow outline is meant to
distinguish the XXCONSOLE.EXE program (the super console
generator program) from the end product (the CMD.EXE shortcut)
which should be represented by any of the remaining icons
(without the yellow outline) provided within the program.

Under normal circumstances, there is no reason to move the
XXCONSOLE.EXE once it is installed by XXCOPY.  When you move
the shortcut file that represents XXCONSOLE.EXE (i.e.,
the XXCONSOLE.EXE.LNK file in the desktop), the actual
location of the XXCONSOLE.EXE file remains the same and
should not cause problems.

On the other hand, we do provide the XXCONSOLE.EXE program as
in a freeware (http://www.xxcopy.com/download/xxconsole.zip).
When you invoke this program for the first time in an
arbitrary directory, it will behave like a "self-installing"
program (by creating an entry in the system registry for
the uninstall purpose).  Once you move the XXCONSOLE.EXE
program from the original location, the shortcuts that were
created by the XXCONSOLE.EXE program will continue to point
to the original XXCONSOLE.EXE location for its icon image.
Therefore, the icon image will be substituted by a generic
one) --- a missing icon image is a common problem which
explains why Windows handles the icons on the Desktop in
bizarre ways.

Kan Yabumoto

Hi, all:

Here's the overall rational for the creation of XXConsole.

When you start using Windows Vista, the first thing you notice
especially in a regular DOS Box (the CMD.EXE console) is the
UAC-prompts.  It is there whether or not you use XXCOPY.
At first, the frustration level seems unbearable.

    -----------------------------------------------------
     I even suggest that you operate the Vista with UAC
     disabled for a while.  You will realize that Vista
     without UAC is very much like Windows XP.  But,
     once you re-enable UAC, then, you need to deal with
     the UAC-prompts.  Until you learn exactly when the
     prompt appears, you may be never get used to the
     life with UAC under Vista.  That is why I wrote
     XXTB #42 (http://www.xxcopy.com/xxcopy42.htm)
    ------------------------------------------------------

We quickly realized that typical XXCOPY users need unrestricted
access to any directories.  That is, in a UAC-enabled environment,
the only practical way to run XXCOPY or a batch file that
contains a XXCOPY command is to open the DOS Box (CMD.EXE)
with the elevated Admin privilege. (The only reasonable
alternative is to disable the UAC-setting that pretty much
defeats much of the Vista advantage.  Let us know if you
find another trick to deal with UAC-enabled Vista.)

So, our advice to XXCOPY users (and IT professionals who are
responsible in system upkeep) is to run the command processor
(CMD.EXE) with the Admin privilege.  For the sake of convenience,
let us call it "Super Console" (with this name, we need not
be apologetic with the "DOS Box" which we know is a misnomer).

In the past, we never gave an official advice on how to
create a DOS Box (CMD.EXE console).  Some people create it
from Start Menu > Run... and type cmd.exe.  Others probably
create a shortcut icon of CMD.EXE on the Desktop.

In Vista, the Start Menu does not come with the "Run..."
choice (You need to "Customize" it from Start Menu Properties
in order to have the "Run..." entry in the Start Menu.
Alas, even after you create the "Run..." entry in the menu,
it won't allow you to run with the Admin privilege.

So, the answer is to create a shortcut of CMD.EXE on the Desktop.

    http://www.xxcopy.com/img/runasadm.jpg

Once you have a CMD.EXE shortcut, then, you can right-click
for a floating menu where the option for "Run as administrator"
is available.  But then, you may forget this and open a regular
(non-admin) console by a regular double-click of the left button.

Ultimately, it is best that the CMD.EXE shortcut be permanently
initialized with the "Run as administrator" setting by
Properties > Shortcut > Advanced > [v]Run as administrator.

First, we tried to write a technical bulletin to explain the
steps (to set up a CMD.EXE shortcut with Admin privilege).
After some futile efforts, it became painfully obvious that
providing a "Super Console Generator" program is much easier
(and trouble-free) than an instruction in English text.

That's how we created a humble program called "XXConsole.exe".
The main function of the program is to create the CMD.EXE
shortcut in the Desktop with the Admin privilege.  Since
the CMD.EXE shortcut is meant to be frequently executed, we
added the dialog page with preference settings.

   ---------------------------------------------------------------
    The only advantage using the XXCONSOLE.EXE program to create
    a Super Console (CMD.EXE shortcut with Admin privilege) is
    that the XXCONSOLE.EXE file has embedded icon images which
    will give a distinctive look for the console with the Admin
    privilege.
   ---------------------------------------------------------------

The user should not be confused about the nature of the
CMD.EXE shortcut created by the XXCONSOLE.EXE program.
Even though the shortcut is labeled "XXConsole" by default
(and its icon image points to an embedded image in the
XXCONSOLE.EXE file), the shortcut itself is not a special
program or utility.  It is merely an ordinary shortcut
which can be manually created without the help of the
XXCONSOLE.EXE program.  As a matter of fact, once a shortcut
is created by XXCONSOLE.EXE, any of the characteristics
of the shortcut can be altered only via its property sheets.

If you want to learn a little bit more about the XXCONSOLE
program itself, read the following article:

    http://www.xxcopy.com/xxcopy43.htm


Earlier, we received the first feedback on XXConsole from
John Zeman (one of our regular members here).  I'm wondering
whether or not we should publicize XXConsole as a generic
freeware package for the general public.  From our perspective,
it helps XXCOPY users in Vista by having the Suer Console handy.
It also helps suppress the UAC-prompt (e.g., run RegEdit from
a Super Console command line).  For me personally, unless
I have a Super Console handy, Vista with UAC is quite
difficult to tolerate.

I'm wondering how many people discover the Super Console
technique for the first time with the XXCOPY installation
as opposed to "Yes, I had already been doing exactly like
that before encountering XXConsole".

Kan Yabumoto

Kan first off I need to clarify that I am pretty
much a newbie with Vista.  I recently had a need
to purchase a new laptop which came with Vista
Home Premium and I'm still getting it configured
the way I want.

That said, here is what I did with XXConsole
yesterday.

I left the program in its default installed
location (Windows\System32) and simply double
clicked on the XXConsole.exe program file.  Each
time I double clicked it, a new XXConsole icon
with an incrementing number was placed on my
desktop.  I found if I right clicked one of those
desktop icons, choosing PROPERTIES and changed the
target on the SHORTCUT tab of the dialog to the
batch file I wanted to launch, all works as
expected.  For 4NT scripts I also have to include
the path to the 4NT executable i.e.

"C:\Program Files\JPSoft\4NT8\4nt.exe" c:\mine\cmd\test.btm

About the XXConsole shortcuts being in other
locations.  Since yesterday I have discovered if I
use the Vista Explorer to launch my moved to
another location XXConsole shortcuts, then
the super console still functions as it should.
Yesterday I was using my GUI file manager
(Directory Opus) to double-click on the moved
shortcuts and that is when the console failed to
function correctly.  So I suspect that problem is
on the Opus side of things, I'll be glad to report
it to the Opus authors if you'd like me to.

I'm still experimenting here, I have much to learn
about both Vista and how xxcopy will work on it,
but I'm making slow progress.

John




--- In xxcopy@yahoogroups.com, Kan Yabumoto <tech@...> wrote:
>
>
> John  wrote:
>  >
>  > I finally had a little free time to play with this new XXConsole
>  > Kan, it does seem to make command line scripts much more user
>  > friendly on Vista. However I noticed that I only seem to be able
>  > to use the super console while it's placed on the Vista desktop.
>  > If I copy or move it to any other folder it does not seem to
>  > function, is that to be expected?
>  >
>  > On my Vista desktop I have successfully configured a few super
>  > console icons which successfully run both CMD and 4NT scripts.
>
> John:
>
> Can you clarify what did you move (and how)?
>
>   http://www.xxcopy.com/img/xconicon.jpg
>
> This page shows the icon images embedded inside the XXCONSOLE.EXE
> file.  The first one with the yellow frame is meant to represent
> the XXCONSOLE.EXE program as opposed to the remaining icon images
> that are for the CMD.EXE console shortcuts.  Did you move the
> XXCONSOLE.EXE program file from the "rightly place"
> (XXCOPY installs the program at \windows\system32\ directory
> with its shortcut created in the \user\public\desktop\).
>
>   ----------------------------------------------------------------
>    Among other things, Windows often shows some "dumb downed"
>    version of things that impede operations of both novices
>    and professionals.  Here, when I say \users\public\desktop\
>    and try to view the directory contents using the Windows
>    Explorer, the "desktop" directory a subdirectory inside
>    the  \users\public\ directory always appear as "Public Desktop"
>    rather than its true name "desktop".  (I still do not
>    understand why the file size is shown in KB. And even
>    a 1-byte file is shown as 1KB.)
>   -----------------------------------------------------------------
>
> The most likely scenario in this case is that the XXCONSOLE.EXE
> program has a bug.  Please send me the troublesome shortcut file
> (created by XXCONSOLE.EXE on the desktop) in the .ZIP format.
> If you create a few variations in the way you move the XXCONSOLE.EXE
> program and the end result (you may keep the numeric variation
> without change (e.g., XXConsole(1).lnk,  XXConsonsole(2).lnk, etc.).
>
> Here are other possibilities that I can think of...
>
> I assume you copied the XXCONSOLE.EXE program file into another
> directory.  At that time, are you sure that you were not fooled
> by the "virtualized" object (that looks like it's there)?
>
> For example, if you use an old version of XXCOPY on Vista and copy
> files, the system may let you "copy" the files into the "restricted"
> destination such as the root directory (or somewhere in
> \program files\).  This may possibly cause problems with XXConsole.
>
> When the new version of the XXCOPY (v.2.96.0) package is installed,
> it creates a shortcut for the XXCONSOLE.EXE program as well as
> the super console shortcut.
>
>    -----------------------------------------------------------------
>     One frustrating fact is that the icons displayed on the Desktop
>     are heavily cached (buffered) in such a way that you may not
>     immediately see the xxconsole-related shortcuts created when
>     XXCOPY is installed.
>
>     You may need to press <F5> or perform right-click > Refresh.
>     Even with such a sequence, the XXCONSOLE.EXE shortcut does not
>     show the proper icon unless an "icon change" is performed via
>     the property sheet without any change --- I suspect that it's
>     Vista's bug.
>   ------------------------------------------------------------------
>
> The XXCONSOLE.EXE shortcut should be displayed with the first
> embedded icon (icon #0) within the XXCONSOLE.EXE program
> (with the yellow outline).  The yellow outline is meant to
> distinguish the XXCONSOLE.EXE program (the super console
> generator program) from the end product (the CMD.EXE shortcut)
> which should be represented by any of the remaining icons
> (without the yellow outline) provided within the program.
>
> Under normal circumstances, there is no reason to move the
> XXCONSOLE.EXE once it is installed by XXCOPY.  When you move
> the shortcut file that represents XXCONSOLE.EXE (i.e.,
> the XXCONSOLE.EXE.LNK file in the desktop), the actual
> location of the XXCONSOLE.EXE file remains the same and
> should not cause problems.
>
> On the other hand, we do provide the XXCONSOLE.EXE program as
> in a freeware (http://www.xxcopy.com/download/xxconsole.zip).
> When you invoke this program for the first time in an
> arbitrary directory, it will behave like a "self-installing"
> program (by creating an entry in the system registry for
> the uninstall purpose).  Once you move the XXCONSOLE.EXE
> program from the original location, the shortcuts that were
> created by the XXCONSOLE.EXE program will continue to point
> to the original XXCONSOLE.EXE location for its icon image.
> Therefore, the icon image will be substituted by a generic
> one) --- a missing icon image is a common problem which
> explains why Windows handles the icons on the Desktop in
> bizarre ways.
>
> Kan Yabumoto
>

[I just renamed the subject of this thread]

John wrote:
  >
  > Kan first off I need to clarify that I am pretty
  > much a newbie with Vista. I recently had a need
  > to purchase a new laptop which came with Vista
  > Home Premium and I'm still getting it configured
  > the way I want.

I wrote the XXTB #42 article as an introduction to
Vista operations with UAC with a relatively little
experience in the environment.

    http://www.xxcopy.com/xxcopy42.htm

Like everyone else, I had a rough time getting used to the
Vista environment.  (I still remain in a XP machine for much of
my work and use the Vista machine as a test bed.)

  > That said, here is what I did with XXConsole yesterday.
  > I left the program in its default installed location
  > (Windows\System32) and simply double clicked on the
  > XXConsole.exe program file. Each time I double clicked it,
  > a new XXConsole icon with an incrementing number was
  > placed on my desktop.

OK.  The XXConsole.EXE program's job is complete once it
creates a shortcut for the CMD.EXE program.

As I have emphasized in my previous post, the XXConsole program
(XXCONSOLE.EXE) is a tool whose operation can be performed
manually without any specialized tool.  Because the manual
procedure to create a CMD.EXE shortcut with the "Run-as-Admin"
setting enabled is somewhat complicated to describe, we supplied
the XXConsole.EXE program to do so.

  > I found if I right clicked one of those desktop icons,
  > choosing PROPERTIES and changed the target on the SHORTCUT
  > tab of the dialog to the batch file I wanted to launch,
  > all works as expected.

Any further customization is beyond the scope of the XXConsole.EXE
program.  That does not mean the XXConsole shortcut must be used
without changes.  Rather, we encourage such usages.  The point is
that the nature (behavior) of the modified shortcut (which should
no longer be called XXConsole in the strictest sense).

---- I now believe that I should add a tip for customization of
the XXConsole shortcut via the property sheets in XXTB #43.

For example you may want to launch a batch file (which should
be run with the Admin privilege) you may change the "Target"
string of the shortcut via its property sheet.

Say, you specify the full path of the batch file as the target of
the shortcut.  In that case, the invocation of the shortcut
(the batch file) will implicitly launch the CMD.EXE because of
the fairly complicated rules of invocation (and the file-association
rule).

   -----------------------------------------------------------
    Here, I found it a little odd that the .BAT and .CMD
    extensions are *NOT* registered in the file-type
    registration in either XP or Vista.  On the other hand,
    the environment variable, PATHEXT lists common extensions
    like .BAT and .CMD.  This list probably determines the
    default handling of such file types.  In the case of
    Vista (Control Panel > Default Programs > Associate a file...)
    .BAT and .CMD extensions are classified as "Unknown application"
    and should not be modified to CMD.EXE.
   ------------------------------------------------------------

Although specifying the bare path name of a batch file in the
target of the XXConsole shortcut, the invocation of the batch
file will automatically close the console window.  However,
it is often desirable to examine the console output after the
execution of the batch file.  In such a case, you should specify
the following string:

    c:\windows\system32\cmd.exe  /k "batch_invocation_string"

where "batch_invocation_string" is the full path of the batch
file plus optional command arguments.

(Alternatively, the last line of the batch file should be
a "pause" command.)

  >  For 4NT scripts I also have to include the path to the
  > 4NT executable i.e.

<snip>

  > So I suspect that problem is on the Opus side of things
  > I'll be glad to report it to the Opus authors if you'd
  > like me to.

As I stated above, the problem is nothing to do with XXConsole.
Rather, its the behavior of the shortcut with a given invocation
string/environment.  That is, to simulate the behavior of
a manual invocation of a command line from a DOS Box, you
should first experiment the behavior using the "CMD.EXE /K"
option followed by your command line string.

Kan Yabumoto

I'm getting
## The destination full filename exceeds the pathname limit (skipped).
##
What value is the limit?

Can it be increased?

Is there any way around this?

Calvin

Calvin  wrote:
  >
  > I'm getting
  > ## The destination full filename exceeds the pathname limit
  > (skipped). ##
  >
  > What value is the limit?
  >
  > Can it be increased?
  >
  > Is there any way around this?

XXCOPY supports the standard file pathname limit of 255 characters.
With the current version of XXCOPY, the only way to get around is to
reduce the overall length.

Kan Yabumoto