FB II Compiler
Empty the resource fork of a file
I'm not sure if I'm interpreting your question correctly, but I think what you're saying is this: You want to end up with a file which contains only a data fork, but you may be updating a file which already exists and which may have a resource fork. How do you make the resource fork go away?
Assuming you don't care what was in the data fork previously, probably the easiest thing to do is to simply delete the file if it already exists. This will get rid of both forks. You can use a function like FN FileExists (which is posted here occasionally and which may even be somewhere in the FB example files) to determine whether the file already exists.
I don't think there is any way to delete _only_ the resource fork, separately from the data fork. You can delete each of the individual _resources_, but then the "fork" itself still remains--that is, it still takes up space on disk. On the other hand, if you KILL the file and then re-create just the data part, then there literally is no resource fork.
You don't have to worry about that. When you create a new file, the resource fork is empty.
Not so, I find. Continuing...
Rick and David, I'm sorry I was not clear on my question as to the configuration and desires, but, here is the scenario...
A file already exists. It has a data fork and a resource fork. There are several resources in it that contain certain text data. Yes, data. This data is pertinent to the file during it's prior usage, but now the user is staring anew, using the standard FILES$ routine s/he opens a new file with the same name as the existing file. The system asks if you want to replace the existing file and you agree.
You continue into the program and add some records which get written to the data fork _and_ some items to a text resource. Close the application and thus the data file, fire up ResEdit and take a look and bingo there is the text data you just added in the Resource fork, but also, there is all the data that was in the file prior to you asking for it to be overwritten. The resource fork was not emptied when the new file was opened.
This surprised me and leaves me wondering what I can do to clear out this resource fork - not get rid of it, as we will need it, but it should never have previous stuff in it. That screws up everything.
Why wouldn't an offshoot of this work, it does for me?
resHndl& = FN NEWHANDLE _clear(2)
FN pGreplaceRes(resHndl&,_"STR#",_logListSTR," ")
I doubt if the resource fork of the original file was still open - it has been sitting around for days or weeks, untouched and the application closed a long time ago. Now the app is started - first time this day - and the user decides to create a new file - but he elects to use the same name as that old file. This is exactly the situation I'm alluding to - this old file's resources are all contained in the new file.
gFileName$ = FILES$ (_fSave, tmp$, "DB.Untitled", gFileVol%)
to open the new file - seems to work great except for this problem with trying to reuse an old files name - seems like the old file name brings along all its baggage. And I;m just not sure what I have to do to lighten the load - or empty the resource fork. I was betting like David said "When you create a new file, the resource fork is empty." Doesn't seem to be so.
Ah, now I see what you mean. Data forks and resource forks are structured differently: In a data fork, you have an "end-of-file" pointer that's part of the file's information, and which you can reset to point to any position in the file. To "wipe out" the data fork, all you need do is set the end-of-file to point to byte #0 in the file (that's what FB does when you do OPEN "O" for an existing data file).
But you can't do that in a resource fork (well, technically you _can_, but it screws up things like the Resource Map. And a resource fork without a proper resource map is useless.)
In your case, is it acceptable simply to get rid of certain old resources which have particular ID numbers? Or do you really need to make sure the fork is completely empty?
If the former, then FN pgReplaceRes should work. Before adding a resource of a certain type and ID number, the FN will first delete any existing resource which has that same type and ID number.
But if you must start with a completely empty resource fork, then I see two possible courses of action:
* You could delete & then re-create both forks. A single KILL command will delete both forks. However, you need two _separate_ commands to re-create both forks. The common way to create a data fork (in FB) is by the OPEN "O" statement (which both creates the data fork and opens it). To create a new resource fork, you need to use a Toolbox procedure such as CREATERESFILE, HCREATERESFILE, or FSPCREATERESFILE. Then you'd need to open it using a procedure such as OPENRESFILE, HOPENRESFILE, FSPOPENRESFILE or OPENRFPERM.
* You could individually delete all the resources from the fork. To do that, you'd probably have to: count all the resource types (COUNT1TYPES), index through all the types (GET1INDTYPE), and, for each type: count all the resources of that type (COUNT1RESOURCES), then index through all the resources of that type, getting a handle for each (GET1INDRESOURCE), then deleting the resource (RMVERESOURCE). If there's a possibility that a resource's "_resProtected" flag is set, then you'll also need to reset that flag before you can delete the resource. As always when indexing through things to delete them, it's probably safest to index _backwards_ (from "n" to 1, not from 1 to "n").
Ah ha - I thank you Rick for shining the light where the problem lies.
Perhaps what I will do is: as each new entry is made into this database we'll just test for the resource that should not be there yet, and if one is there, get rid of it with RMVERESOURCE.
I think I'm half way there, as I already test for the resource in order to change the icon of a button that summons the resource and its associated window.
Thanks again. This list is fantastic. Thanks to all who responded.
Creating a new file, from the _user's_ point of view, is not the same thing as creating a new file from the _machine's_ point of view. Files$ just lets the user enter a name and a save location for the file. That's all. It doesn't touch the original file. In fact, the only thing that FILES$ can do to modify the drive is to create a new folder.
If your next step is to open the file the user specifies, then yes - you are just going to be opening an existing file, and all its existing contents will be there. It is your program's job to replace the file; the OS won't do that for you.