• Please review our updated Terms and Rules here

DOS batch file question - finding hidden files

N

NTEPB

Member
Joined
Nov 18, 2008
Messages
19
Location
Tucson, AZ
Hi everyone! I know it's been a LONG time since I've posted on this forum. I do have an interesting DOS question, however. Maybe some of you could help me out.

I'm working on a DOS batch file to archive my dad's old 5.25" floppy diskettes. The computers that will be reading the diskettes range from IBM 5150s (with 360KB drives) to Pentium-class machines (with 1.2MB drives). The machines will be running PC-DOS 3.30 to MS-DOS 7.x (from Win9x), depending on the CPU architecture.

What I'm needing to do is this: while running my batch file, I need the computer to determine if there are any files on each diskette with hidden or system attributes. If the computer does find hidden or system files, I need an ERRORLEVEL flag set so I can branch to another section of the batch file and run another command.

Obviously, DOS 3.30 can't use the DIR /A:HS command, and DIR (on any DOS version) will not generate an ERRORLEVEL code at all, due to DIR being an internal DOS command. I looked high and low on Google, and I did find 2 old DOS utilities (DH.EXE and FINDHID.EXE); however, those utilities don't generate ERRORLEVEL codes at all.

Does anyone know of a utility (or some batch-file workaround) that might work for my needs? Please keep in mind that this needs to work using DOS 3.30 and later.

Thanks in advance!

Jon
 
Jon,
While I am not sure exactly what are you trying to accomplish with the 5.25" floppies, might I suggest you create a DOS 6.x boot disk for each machine with just the DOS programs you need to do the job.

If the older DOS is an issue, you could temporarily upgrade the PC to a higher DOS by doing the following...

1. Create a boot disk using the current OS on each machine. You'll need this to restore the OS.
2. Create a DOS 6.x boot disk containing any programs from DOS 6.x you might need to do the job
3. Boot the PC to DOS 6.x, create a new directory on the HD and copy the DOS 6.x files there.
4. Do a sys C: (making the HD boot to DOS 6.x)
5. Modify the COMMAND and PATH statements to point to the DOS 6.x directory you created in step 3.
6. Do what you need to do after rebooting to DOS 6.x off the HD.
7. When done, boot to your old OS (from step 1), do a SYS C: and modify the COMMAND/PATH statements to point back to your old DOS directory.

This should allow you to do anything you want on each machine while under DOS 6.x. The only files you would be changing are the 2 or 3 files in the root directory used to boot the machine. Those can be easily flip-flopped using the SYS command.

Joe
 
What media are you going to be using for archiving these floppies? If you are going to be using floppies, DISKCOPY would be better for the system boot disks with hidden files on them. Or you could image them and store the image files. For all other floppies (which shouldn't contain any hidden files) it might be better and easier to ZIP them and store the ZIP files anywhere you like. Of course there are lots of different ways to go about doing this type of thing but a one batch file for all method doesn't seem like the best to me. It could conceivably take more time to get the batch file right than it might take to do all the archiving. :)
 
Do you need to save the state of the hidden or system files? If not, just use ATTRIB to clear the system and hidden bits and then copy all the files easily.
 
krebizfan said:
Do you need to save the state of the hidden or system files? If not, just use ATTRIB to clear the system and hidden bits and then copy all the files easily.
Click to expand...
Why would you alter a disk you were trying to archive? Doesn't archiving imply you want to preserve the disk as is? It certainly does to me. :)
 
Stone said:
Why would you alter a disk you were trying to archive? Doesn't archiving imply you want to preserve the disk as is? It certainly does to me. :)
Click to expand...

Different people mean different things by archiving. If the archive is going to files stored in a directory tree, having files retain attributes won't do much good and makes evaluation of hidden and system files harder. Preserving system and hidden attributes makes sense when imaging disks and indeed happens automatically.

Sometimes one can make a process simpler by figuring out what the true goals are.
 
Original program disks should be archived with at least ImageDisk.

For user data disks, individual files might be more useful. (Do both :p )

You might consider using PKZIP. You can set flags to include or exclude hidden/system files. And as a bonus, a zip file helps ensure bits don't flip once the file is in the zip. And naturally, your archives will be smaller.

But keep in mind that if hidden or system files exist, you are possibly dealing with a system disk, or a copy protected disk. Either way just copying files may not be sufficient.

Also keep in mind that copying just files can lose certain kinds of "metadata". For example copying subdirectories usually loses any directory date stamps. Some programs can depend on the file order. For example a setup program that lists available video driver files might have intentionally had "VGA" first. Also, in some cases a vendor might have carefully ordered the files in order to optimize load time.
 
Wow! Thanks for the replies, everyone! Now that I have a 4-day weekend here, let me (hopefully) clarify some of the stuff on this thread a bit more.

Here's what I'm able to accomplish with my dad's floppy diskette archival so far. The section in bold is the part I'm looking for.

From a shared directory on my network server, the batch file will:
- run an AV scan (I already have the programs for this)
- XCOPY all the files on each floppy diskette to its own directory on my network sever (I'm using XXCOPY for this; it's a bit more versatile than XCOPY, and it copies all file attributes on the older DOS systems)
- check to see if any hidden/system files exist on the diskette
- if there are any hidden/system files, run SAVEDSKF to make an image of the diskette
- if there aren't any hidden/system files, skip this step​
- run PKZIP to package the files to another directory on my network server (preserving all file attributes)

As you can see, I have almost every base covered with the steps listed. I already wrote the 8KB batch file 6 years ago, and it works great on my systems (from PC-DOS 3.30 to Windows 98). The only program I'm needing is the one that checks each diskette to see if there are any hidden/system files. That way, I can skip imaging certain diskettes when it's not needed.

For those of you wondering why I'm using SAVEDSKF for the images, it's so my father can view/write disk images using WinImage. He & I noticed that WinImage will easily open/manipulate disk images created using SAVEDSKF. So unfortunately, that leaves out DISKCOPY, IMD, ImageDisk, and the others. Sorry. I know there are pros and cons to each imaging program, but SAVEDSKF just flat-out works for what he wants to do.

Now for the individual replies:

Grandcheapskate: Joe, thanks for the advice, but there is one thing I forgot to mention. Two of the older computers I'll be using to archive the diskettes are a PC and a PCjr. There are no hard drives in those things, and getting DOS 6.x to work on a PCjr takes some patching, which is why I'm trying to use DOS 3.30.
Stone: I think you're the person with the closest idea to what I'm trying to do here. However, I'm trying to avoid having to image every single diskette when it's not needed.
Chuck(G): Fortunately, these diskettes in question do not have any form of copy protection nor any weird FAT filename entries.
krebizfan: I thought long & hard about using ATTRIB to strip out the attributes. Doing what you suggested would require me to write to each diskette. And as we all know, using a 1.2MB floppy drive to write to a 360KB diskette is a bad idea.
SomeGuy: PKZIP actually does preserve the file dates & times. Go figure! Also, since a lot of these diskettes were created on my dad's PCjr, we didn't really have much need for subdirectories on floppies back then.

Once I get the final piece to this puzzle solved, I'll be glad to post the entire batch file and steps on my website.

Again, many thanks for the replies. In the meantime, does anyone know of an old DOS utility that will search diskettes for hidden files and generate an ERRORLEVEL code? Thanks again!

Jon
 
Okay. I think I found a workaround for my little problem here. It takes a few steps, but it seems to work well.

As we all know, using DIR on PC-DOS 3.30 doesn't allow you to look at hidden files (unlike DOS 5+). And the ATTRIB command doesn't allow you to change settings on hidden files, nor list all the files/attributes on the disk (again, this comes in later versions of DOS).

However, the latest version of ATTRIB included with FreeDOS does allow you to list all the files on a diskette and show the file attributes, including subdirectories. And the best part: it works on DOS 3.30! Even works on XP, too.

Now I can do the following:
- run ATTRIB A: /S
- output the result to a text file
- open that file in my tiny BASIC-compiled program to parse the data
- this is to determine if there are any hidden or system files listed in the text file​
- if there are any hidden or system files, my program will write a new file on the network share called FOUND
- if there aren't any hidden files, my program will simply skip writing any new files on the network share​

Once that's done, I can use the IF EXIST batch command to determine if FOUND is on the network share.
- if the FOUND file exists, then the batch file will continue with the SAVEDSKF procedure
- if the FOUND file doesn't exist, then the batch file skips imaging the diskette and continues with the next step
- regardless of the results listed above, the batch file will automatically erase the FOUND and text output files on the network share (to prevent confusion later)

I know it's a bit more work to do something like this, but again, this works very well for my needs.

Again, thank you everyone for reading and replying. Hopefully this helps someone else down the road with an oddball project such as this.

Jon
 
You must log in or register to reply here.
Back
Top