ctt31684@uxa.cso.uiuc.edu (06/10/90)
Try setting a very lark file buffer inside your C program when it is reading and writing the file. I'm not sure how to call an DOS command from C program, but I would guess you could try system(). Anyone have any other suggestions?
mms00786@uxa.cso.uiuc.edu (06/11/90)
If you don't mind machine dependent code, what do you think of the following: Find the entry for file A in the dir area. The entry, I believe, consists of the name + some junk + number of the first allocated cluster. Then, the byte corresponding to that cluster in the dir area has the number of the next cluster and so on, just like a linked list. So if you can traverse the entire linked list for file A, then make its last cluster byte point to the first cluster byte of file B, you will have concatenated the two. You will have to take care and delete file B, or else someone will run chkdsk and ... wamoose. This should be much faster, and I think you might be able to pull it off using bios calls, so at least your code should run on all PC's (sure...) Milan .
darcy@druid.uucp (D'Arcy J.M. Cain) (06/13/90)
In article <46500106@uxa.cso.uiuc.edu> mms00786@uxa.cso.uiuc.edu writes: > >If you don't mind machine dependent code, what do you think of the following: > [How to concatenate 2 files by fiddling with the FAT] Be careful as this only works with files that are exact multiples of your cluster size. Otherwise you will wind up with garbage between the two parts of the file. Of course it will never work across a network. -- D'Arcy J.M. Cain (darcy@druid) | Government: D'Arcy Cain Consulting | Organized crime with an attitude West Hill, Ontario, Canada | (416) 281-6094 |
bxw@ccadfa.adfa.oz.au (Brad Willcott) (06/13/90)
mms00786@uxa.cso.uiuc.edu writes: >If you don't mind machine dependent code, what do you think of the following: > Find the entry for file A in the dir area. The entry, I believe, consists > of the name + some junk + number of the first allocated cluster. Then, the > byte corresponding to that cluster in the dir area has the number of the > next cluster and so on, just like a linked list. So if you can traverse > the entire linked list for file A, then make its last cluster byte point > to the first cluster byte of file B, you will have concatenated the two. [...] Your suggestion Milan, seems like a good one, but it assumes that file "A's" data fills the last sector of the last cluster in its chain! Depending on the file type this is possible, however, one cannot easily find out. Therefore, the method that copies LARGE chunks of data at a time from the source file would be the simplest, safest and quickest method of file concatination. Nice idea, but MS-DOS wasn't designed for such simple solutions :-(. -- Brad Willcott, ACSnet: bxw@ccadfa.cc.adfa.oz Computing Services, Internet: bxw@ccadfa.cc.adfa.oz.au Australian Defence Force Academy, UUCP:!uunet!munnari.oz.au!ccadfa.oz!bxw Northcott Dr. Campbell ACT Australia 2600 +61 6 268 8584 +61 6 268 8150 (Fax)
dold@mitisft.Convergent.COM (Clarence Dold) (06/14/90)
in article <1633@ccadfa.adfa.oz.au>, bxw@ccadfa.adfa.oz.au (Brad Willcott) says: > Your suggestion Milan, seems like a good one, but it assumes that file "A's" > data fills the last sector of the last cluster in its chain! Depending on the > file type this is possible, however, one cannot easily find out. Therefore, I might have missed a link in this thread, but I didn't see anyone point out the "a+" or "a" flag to fopen. Someone gave a code snippet with "ab" in it, but noone pointed out the speed differential between reading every record in the first file till EOF, verses opening the file for append. I assume that MSDOS would lseek to the end of file. Is that not true? If our original poster is reading the entire file, as suggested by the great speed of "copy +" according to his comparison, then maybe all he needs is the "a" flag, again assuming that it works. -- --- Clarence A Dold - dold@tsmiti.Convergent.COM (408) 435-5293 ...pyramid!ctnews!tsmiti!dold FAX (408) 435-3105 P.O.Box 6685, San Jose, CA 95150-6685 MS#10-007