WKF2298@RITVAX.ISC.RIT.EDU (Wonko the Sane) (01/13/91)
Wow! I know, I keep coming up with more questions! Well, I'm still working with the same project, and I've hit another stubling block. All I want to do is to be able to delete forked files from ProDOS 8 BASIC. How? Any suggestions? William K. Fry
toddpw@nntp-server.caltech.edu (Todd P. Whitesel) (01/13/91)
WKF2298@RITVAX.ISC.RIT.EDU (Wonko the Sane) writes: > Wow! I know, I keep coming up with more questions! Well, I'm still >working with the same project, and I've hit another stubling block. All I >want to do is to be able to delete forked files from ProDOS 8 BASIC. How? No existing utility that I know of will do this. If you don't mind doing a little block patching, you can do it yourself, but it requires some assembly and some MLI calls: 1. CREATE a temporary file to hold the resource fork. 2. Use some cheap block reading/parsing to find the directory entries for both the temporary file and the file you want to delete. 3. Use the info quoted below to modify those two directory entries so that one becomes the data fork and the other becomes the resource fork. 4. DELETE both files, and remove the 'extended key block' from the volume free space bit map. If this is too yucky, mail me and I can send you code examples. Todd Whitesel toddpw @ tybalt.caltech.edu The following is quoted from ProDOS technical note #25. ------------------------------------------------------- Storage type $5 is used by the ProDOS FST in GS/OS to store extended files. The key block of the file points to an extended key block entry. The extended key block entry contains mini-directory entries for both the data fork and resource fork of the file. The mini-entry for the data fork is at offset +000 of the extended key block, and the mini-entry for the resource fork is at offset +$100 (+256 decimal). The format for mini-entries is as follows: storage_type (+000) Byte The standard ProDOS storage type for this fork of the file. Note that for regular directory entries, the storage type is the high nibble of a byte that contains the length of the filename as the low nibble. In mini-entries, the high nibble is reserved and must be zero, and the storage type is contained in the low nibble. key_block (+001) Word The block number of the key block of this fork. This value and the value of storage_type combine to determine how to find the data in the file, as documented in the ProDOS 8 Technical Reference Manual. blocks_used (+003) Word The number of blocks used by this fork of the file. EOF (+005) 3 Bytes Three-byte value (least significant byte stored first) representing the end-of-file value for this fork of the file. All remaining bytes in the extended key block are reserved and must be zero.
jeffb@world.std.com (Jeffrey T Berntsen) (01/17/91)
JWANKERL@UTCVM.BITNET ("Josef W. Wankerl") writes: [Stuff deleted....] >ever slapped into the ProDOS file system. Normal ProDOS programs >can't use them, so why bother? It'd have been much better to just >write an entirely new FST and call it "IIGS/OS/FS" or something >stupid like that. At the last KansasFest, I talked with Greg >Branche and Jim Luther about such a beastie. They seemed rather >keen on the idea at the time. Maybe for System Disk 6.0? Even >then the ProDOS idea has been scarred beyond belief. Not really. What Apple needs to do is modify ProDOS-8 so that forked files can be handled in a reasonable manner. Here's what I think should be done: Modify the OPEN call so that it opens the data portion of a forked file. Modify the DELETE call so that it will delete both the data and resource forks of a forked file. Add a separate OPEN call to open the resource fork of a forked file similar to the call that exists for Appleshare. ProDOS shouldn't try to interpret this data in any way, just allow the normal READ and WRITE commands that already exist to read and write bytes of data. This would allow forked files to be copied or allow the copying of just a data or resource fork to its own non-forked file. >-- >===> Josef W. Wankerl, Contributing Editor/Programmer for GS+ Magazine > BITNET: JWANKERL@UTCVM.BITNET | America Online: JWankerl > ProLine: jwankerl@pro-gsplus |-------------------------------- >Internet: jwankerl@pro-gsplus.cts.com | "I am a Viking" -Y. Malmsteen ----------------------------------------------------------------------------- Jeffrey T Berntsen | Looking for a good .sig jeffb@world.std.com | -----------------------------------------------------------------------------
cwilson@NISC.SRI.COM (Chan Wilson [Animal]) (01/22/91)
jeffb@world.std.com (Jeffrey T Berntsen) writes: >JWANKERL@UTCVM.BITNET ("Josef W. Wankerl") writes: >[Stuff deleted....] >>[more stuff deleted...] >Not really. What Apple needs to do is modify ProDOS-8 so that >forked files can be handled in a reasonable manner. Here's what >I think should be done: >Modify the OPEN call so that it opens the data portion of a forked file. >Modify the DELETE call so that it will delete both the data and resource >forks of a forked file. >Add a separate OPEN call to open the resource fork of a forked file similar >to the call that exists for Appleshare. ProDOS shouldn't try to interpret >this data in any way, just allow the normal READ and WRITE commands that >already exist to read and write bytes of data. This would allow forked files >to be copied or allow the copying of just a data or resource fork to its own >non-forked file. Hm, good idea.. I seem to recall bouncing this idea off someone at Apple at the SF fest in 89, and the general reply I got was that there just wasn't any more room to add anything. Could be true, you know. It's not like it's got unlimited amounts of space to grow into... --Chan ................ Chan Wilson -- cwilson@nisc.sri.com <!> I don't speak for SRI. Janitor/Architect of comp.binaries.apple2 archive on wuarchive.wustl.edu "a2fx it!" ................