Hello Jorj,
 \|/  Subject:  orphaned descriptions
 /|\  On Thursday April 09 1998 at 12:02, 
      you wrote to Gerald Miller saying:
 GM>> %info is a variable name for the DESCRIPT.ION file (I do not wish to
 GM>> have the description for %trash deleted when I delete %trash because
 JS>  So if we use actual filenames (any reason not to? it's not like long
 JS>  variable names are saving all that much space in the batch file, and
 JS>  processing them probably adds a bit of time)
The only reason that I can think of for retaining a variable name for %trash 
could be that in the future there may be a requirement to relate %trash to 
more than one filename, but for the sake of this debate, let's call %trash 
what it is, ANTI-VIR.DAT...
 JS>  del /eqz /[!%info]       %trash              equates to
 JS>  del /eqz /[!descript.ion] anti-vir.dat
 JS>  or probably even '/[!*.ion]' if, as likely, you don't have any other
 JS>  files with that extension.
That is a possibility for _most_ directories except one - I have a program 
association executable file that goes by the name X-EXTENS.ION; so I think 
that /[!descript.ion] would be more appropriate.
 JS>  The only hard part is retaining anti-vir.dat's description.  I think
 JS>  the easiest way would be to turn description processing off before
 JS>  you delete anything (setdos /d0), do the deletion (either line
 JS>  above), turn descriptions on again (setdos /d1).  You now have a
 JS>  description file with descriptions for everything that was in the
 JS>  dir.  If, either before turning descriptions on again, or first thing
 JS>  after, you have TB recreate the files, the description for it should
 JS>  survive intact, I think, and expired descriptions cleared.
This is one of those apples versus oranges comparisons...  I suppose that 
"setdos /d0, setdos /d1" would work, but I chose to preclude any possibility 
of descript.ion updating by modification of the attribute, which **should** 
be close to being the same thing...
 JS>  attrib /q +r %info% ^ del /q/z %trash% ^ attrib /q -r %info%
 JS>  The above would not work, I'd think, since '/z' overrides '+r', at
 JS>  least in some quick tests I've just tried.
Uhmmm.  Very strange.  I did change the attribute of descript.ion to ReadOnly 
in seven different directories and "Zapped" three files in each of those 
directories, removed the ReadOnly attribute from descript.ion and listed the 
contents of descript.ion...  My conclusion was that the filenames and the 
descriptions for each were still there even if the files were not in the 
directory.  Of course, when I did a DIR listing and then viewed the 
descript.ion file afterwards, the filenames and descriptions were gone.  The 
same thing holds true if any action such as copying, moving, renaming or 
deleting other files is done...
 JS>  If you don't run TB right away you'll lose the description the next
 JS>  time you delete/move files in the directory. I see no way around that
 JS>  (short of keeping descriptions off until you *do* run TB).  For
 JS>  example, pulling out the description to a variable (set
 JS>  avd=%@descript[anti-vir.dat] and then echoing that back into the
 JS>  description file, will only keep it there until the next modification
 JS>  of that file. Orphaned descriptions don't persist.  You have to get
 JS>  the file they match back in there right away.
Ahhah!  I now see where the confusion may be creeping in.  I'll try to 
outline the process and hope it will be made clear.  I AM running TB as soon 
as possible...
Number one: Delete ALL the ANTI-VIR.DAT files on ALL drives, in ALL 
directories and subdirectories (without updating the description for this 
file in DESCRIPT.ION).
Number two: Run McAfee's SCAN program and use the /AV switch which will add 
validation code to all the executable files (except those files that are 
self-modifying and are listed in the filename - EXCLUDE.LST).
Number three: Run ThunderByte's TBSETUP program to re-establish a revised 
ANTI-VIR.DAT file (which should take into account that the values for some 
files have changed) into each directory.
So far, this process has worked flawlessly and I've not lost one ANTI-VIR.DAT 
description and as long as I run these three steps consecutively, there 
should not be a requirement for "set avd=%@descript[anti-vir.dat]".  The only 
time I can see a possible need for such a process would be to develop a 
routine to verify that ANTI-VIR.DAT is in a directory and if there is a 
DESCRIPT.ION file in that directory, to "read" DESCRIPT.ION to make a 
determination that ANTI-VIR.DAT is indeed, described; if not, then add a 
description: "Anti-virus information for this directory, used by 
ThunderByte's Anti-Virus utilities." How would one "read" the DESCRIPT.ION 
file and verfiy that ANTI-VIR.DAT is described only once?
And I thought this exercise was going to easy...  Well, I've been wrong 
before...  ;^))
              G'Day ... Gerald
--- GoldED/386 3.00.Beta2 UNREG
---------------