Jump to content
IGNORED

Recursive Copy for MyDOS


Shawn Jefferson

Recommended Posts

There's some discussion of a recursive copy utility for MyDOS, and it seems the only one is the Copy Files and Folders by Mirko Sobe, which is nice, but written in Turbo Basic. Does another one exist, not written in BASIC?

 

If not, I was thinking of writing one, but I don't want to bother if one already exists.

 

Anyone know of one?

Link to comment
Share on other sites

There's some discussion of a recursive copy utility for MyDOS, and it seems the only one is the Copy Files and Folders by Mirko Sobe, which is nice, but written in Turbo Basic. Does another one exist, not written in BASIC?

 

If not, I was thinking of writing one, but I don't want to bother if one already exists.

 

Anyone know of one?

 

Could you define a "recursive copier" -- one that only copies certain types of files (.com, .bas, etc.)? Or something else?

 

-Larry

Link to comment
Share on other sites

Could you define a "recursive copier" -- one that only copies certain types of files (.com, .bas, etc.)? Or something else?

 

Larry, recursive copier is a program/utility, that is able to copy directories with all their contents (including other directories with the contents and so on). Like "COPY /R" in the latest SpartaDOS X.

Link to comment
Share on other sites

Well,

the program is called "Profesional Copy" by FoX/Taquart. Think I have two versions in my collection, a version 1.4 and a version 2.0 - but I merely use version 2.0 which requires min. 128k RAM.

 

Ok, just tried to copy a folder (complete subdir with all files) under MyDOS, therefore I created two test folders (named TEST1.DIR and TEST2.DIR) which had one file each (named Procopy20.COM)...

 

Test 1: done with Prof. Copy 2.0 by FoX/Taquart: Did not work. When I tried to copy a folder / subdir Error 168 appeared.

Test 2: done with Bestcopy by Tight, shows an Error again (Error 165 this time).

Test 3: done with Toms Navigator by M. Kurcewicz, well it does not copy a folder, instead it always reads its contents and displays it.

 

Thus, three times no luck - but maybe Acopy 1.81 (which has support for SIO2SD in this version) will do that, I don`t know. Attached you will find some filecopiers, test them if you like...

 

Final note: Found a program named "Folder-Copy" by Rick Detlefsen on his homepage, the original program was written in Atari Basic, but he also created a compiled (*.COM) version with the MMG compiler - maybe this is just what you need... I did not try this program...

 

greetings, Andreas Koch.

 

P.S.: The program Folder-Copy is on the image HDtools2.ATR... (SpartaDOS format, so you may have to use Bewe or Sparta DOS and the menu program to copy it back onto a DOS 2.x or MyDOS disk)...

Link to comment
Share on other sites

I'm looking for a recursive copier too. Now, I have to use the PC to do all of the work, or copy a whole partition at a time to get all the files and dirs. It seems like most people don't use MyDos anymore. That's ALL I use, becuase I mainly use a my-ide cartridge for launching proggies. Sparta is quite impressive -- but overkill for my purposes.

 

I once wrote a recursive copier in compiled vbdos for ms-dos that worked great on PC machines, but I have no idea how to do something like that on an 8-bit Atari (outside of compiled Atari Basic).

Link to comment
Share on other sites

CC65 is a great tool. The C libraries you are used to ( stdio.h and friends ) are all there. The directory calls I am not sure about, but the fopen() stuff all works. The standard C library io stuff has kind of a big memory footprint though, and I tend to avoid it. But it's very easy to call the underlying OS functions anyways, there's built in support for a lot of it and it's also very easy to embed assembler. Speed is very good if you are careful, there's a few coding quirks to adopt for maximum speed but nothing too bizarre. For instance, I have a interrupt-driven mouse routine and a multitasking routine both in about 99% straight C.

 

About the recursive copier...would it just be for Mydos? What other DOS's need it ( that don't have it already? ).

Edited by danwinslow
Link to comment
Share on other sites

CC65 is a great tool. The C libraries you are used to ( stdio.h and friends ) are all there. The directory calls I am not sure about, but the fopen() stuff all works. The standard C library io stuff has kind of a big memory footprint though, and I tend to avoid it. But it's very easy to call the underlying OS functions anyways, there's built in support for a lot of it and it's also very easy to embed assembler. Speed is very good if you are careful, there's a few coding quirks to adopt for maximum speed but nothing too bizarre. For instance, I have a interrupt-driven mouse routine and a multitasking routine both in about 99% straight C.

 

About the recursive copier...would it just be for Mydos? What other DOS's need it ( that don't have it already? ).

 

I wouldn't mind taking a crack at this myself....if just for the learning experience...more of a Java guy on the PC, but I've always wanted to be better on the Atari (where I haven't coded anything for 10+years)....RCOPY is available for Spartados....and X I think has a /R switch for the Copy Command, so its really only needed for MyDos as a utility....I'd be willing to collaborate with someone who has more experience with this....I'd do the grunt work if someone wants to troubleshoot...lol...

Link to comment
Share on other sites

Sure, I'll work with ya. You should go ahead and download CC65 from www.cc65.org, get it set up and working, and also get an emulator set up if you don't have one already. PM me if you need help getting CC65 working. For the first thing to do I'd probably work on getting a directory listing function working...just have it take in a canned directory name and print the contents to the screen. Thats the building block of a recursive copy.

Link to comment
Share on other sites

Sure, I'll work with ya. You should go ahead and download CC65 from www.cc65.org, get it set up and working, and also get an emulator set up if you don't have one already. PM me if you need help getting CC65 working. For the first thing to do I'd probably work on getting a directory listing function working...just have it take in a canned directory name and print the contents to the screen. Thats the building block of a recursive copy.

I have a CC65 library including Getfirst/Getnext functions which I could adapt for use with other DOSes. If I can find it and modify it in the next day or two, I'll post it here. :)

Link to comment
Share on other sites

I'd like to see that, flash. I'm writing/collecting a library of useful stuff, and if you don't mind maybe I could add your routines, with attribution of course.

Absolutely - I'd love to see the LIB files included there. I wrote the CC65 library about 15 years ago and it offers a Microsoft/Borland C MS-DOS style I/O function library for SpartaDOS. Most of it's written in RA65 assembler. I'll see if I can dig it out (and the source code).

Link to comment
Share on other sites

Its basically a dos program, so it will work fine under almost any windows version. You'll need an editor, and you'll need to know how to make simple dos batch files. What I do is to have Atari800win up and set the hard drive option on it to the folder I have my output executables in, that way I can just ty[pe H:test.com or whatever in atari dos and it comes right up.

Link to comment
Share on other sites

How would you guys attack this? I thought about it a little, and I was thinking of actually using a recursive function. MyDOS can have 64 files or directories per directory... and AFAIK there is no real limit on the number of directories (maybe a limit of the command line for specifying a directory?).

 

What I came up with, and I don't know if this would work or not:

 

Open IOCB#1 for reading the directory.

Read an entry from the directory

If it's a file, copy it.

If it's a dir:

close IOCB #1

save the filename we're currently at in the directory

call the routine recursively

open the directory again

read entries until we get to the saved filename

Loop to reading the entry

 

I'm sure there's a better way to do it... but I was thinking how we are going to get around the fact that there is only 16 IOCBs for reading, and there could be quite a few directory and subdirectory levels.

Link to comment
Share on other sites

Well, when dealing with recursion normally you think about a stack structure. I bet there would be a way to screw with the IOCB data such that you could push the entire state of the IOCB onto a stack, then close it, recurse, and process the next level down using the same IOCB. Then, upon popping back up, you'd restore the IOCB from the pushed data and carry on. So some kind of struct, part of whose data would be the IOCB restore data, could be either a local function variable or ( better ) part of an external stack-style array. If its not possible to manipulate IOCB's that way then the stack would be maybe just a file name as you mention, and we'd have to suffer with the re-scan to pick up back where we left off. Actually...I suppose each level could build it's own level entire scan tree first in a local list, and only afterwards process down through it. That way when we popped back up we wouldnt have to actually rescan the disk, we could just use the list entry we were on when we recursed. Thats probably the way to do it.

 

Along that last line of thought, another way to do it would be to just build the entire tree first, a big ass list of all file/dir names, and then just process down through it sequentially. If you think that would maybe be too big you could write it to disk as a temp data file and process it that way.

Edited by danwinslow
Link to comment
Share on other sites

Along that last line of thought, another way to do it would be to just build the entire tree first, a big ass list of all file/dir names, and then just process down through it sequentially. If you think that would maybe be too big you could write it to disk as a temp data file and process it that way.

 

I like this idea... to me with my limited programming knowledge, this looks easy!

Link to comment
Share on other sites

Well, when dealing with recursion normally you think about a stack structure. I bet there would be a way to screw with the IOCB data such that you could push the entire state of the IOCB onto a stack, then close it, recurse, and process the next level down using the same IOCB.

 

The IOCB is 16 bytes... you might not need all of it of course. A filename is only 11 bytes. You may not have to do the additional reading of the directory every time your recursive routine gets entered again though.

 

Actually...I suppose each level could build it's own level entire scan tree first in a local list, and only afterwards process down through it. That way when we popped back up we wouldnt have to actually rescan the disk, we could just use the list entry we were on when we recursed. Thats probably the way to do it.

 

I thought about that... but it may take a lot of memory. 64 x 11 = 704 bytes, and that's only one directory... times that by 10 or 20... and where are you going to store it? The stack will fill up way too quick if you store it there. It may just get really complicated to manage. I don't know how many levels deep a MyDOS disk can go. The documentation doesn't seem to specify a limit (that I saw anyway).

 

Maybe it would work fine.. I was thinking of the fringe cases where somone created directories 64 levels deep or something. ;) You could use your recursive function to build your list of directories, and then just process that list in a linear way later on. That way you don't need to bother storing the regular filenames.

 

Along that last line of thought, another way to do it would be to just build the entire tree first, a big ass list of all file/dir names, and then just process down through it sequentially. If you think that would maybe be too big you could write it to disk as a temp data file and process it that way.

 

Sure, that is one way to do it I guess, but a utility like this writing to disk isn't very elegant. :)

 

I wonder how the SpartaDOS copy /r is implemented?

Link to comment
Share on other sites

Actually, there's only 8 IOCBs.

 

CIO would work with the push/pull IOCB concept, but DOS probably wouldn't.

It keeps it's own drive and file buffers, so you'd quickly hit the wall there.

 

Maybe the best idea would be a system that uses a temporary file - write the list of what has to be copied there.

Then read the file back and do the copy operation based on that.

Link to comment
Share on other sites

I wonder how the SpartaDOS copy /r is implemented?

 

Less or more as in your original idea. There is software stack, 128 bytes of size, which holds positions (dir offsets) of the entered directory entries. Except that, the program works in a loop, i.e. iteratively, it does not call itself recursively.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...