resnick@lees.cogsci.uiuc.edu (Pete Resnick) (07/24/90)
Hopefully an easy question..... I am writing a driver that will be called with the dNeedTime mechanism (accRun control call) by the system every so often. This driver gets input from a text file that I open in my control routine if certain conditions are satisfied. The problem is that I may not be able to read all of the information during one call of the routine, so (as it is written now) I leave the file open and hang on to its RefNum for the next call. 1. Is this a problem as is? Will my file stay open between calls with the file mark in the right place? I would prefer not to close it if I don't have to (if nothing else to save the time of closing, re-opening and setting the file mark each time). 2. I have the file open as fsRdPerm (read-only). If someone goes and changes the file while I am in it and the file gets shorter, am I in big trouble (i.e. will this crash the Mac), will the file just get eof immediately, or will the buffer that I am working on remain the same? pr -- Pete Resnick (...so what is a mojo, and why would one be rising?) Graduate assistant - Philosophy Department, Gregory Hall, UIUC System manager - Cognitive Science Group, Beckman Institute, UIUC Internet/ARPAnet/EDUnet : resnick@kant.cogsci.uiuc.edu BITNET (if no other way) : FREE0285@UIUCVMD
russotto@eng.umd.edu (Matthew T. Russotto) (07/24/90)
In article <1990Jul23.201524.13849@ux1.cso.uiuc.edu> resnick@lees.cogsci.uiuc.edu (Pete Resnick) writes: >Hopefully an easy question..... > >1. Is this a problem as is? Will my file stay open between calls with >the file mark in the right place? I would prefer not to close it if >I don't have to (if nothing else to save the time of closing, re-opening >and setting the file mark each time). No problem. Files remain open unless explicityly closed. -- Matthew T. Russotto russotto@eng.umd.edu russotto@wam.umd.edu ][, ][+, ///, ///+, //e, //c, IIGS, //c+ --- Any questions? Hey! Bush has NO LIPS!
urlichs@smurf.sub.org (Matthias Urlichs) (07/26/90)
In comp.sys.mac.programmer, article <1990Jul24.133617.8305@eng.umd.edu>, russotto@eng.umd.edu (Matthew T. Russotto) writes: < In article <1990Jul23.201524.13849@ux1.cso.uiuc.edu> resnick@lees.cogsci.uiuc.edu (Pete Resnick) writes: < > < >1. Is this a problem as is? Will my file stay open between calls with < >the file mark in the right place? [...] < No problem. Files remain open unless explicitly closed. With one important exception: If the application which (according to MultiFinder) opened the file quits, the file is automagically closed. (This is only true for data forks; resource forks are assumed to get closed by the resource manager.) This does matter if you open a file from a VBL task (or from a driver, or from a desk accessory's accRun routine) and the then-running application quits. The MacDTS-approved solution is to have an INIT which gets the trap address of _Open, and to call that instead of the normal Open trap. (Difficulty: you have to make sure that that Open does get called with the right trap (_Hopen, async) which involves setting one data register, it's not documented which one, to some magic value.) My "solution", which I use in my SingleShare server which runs in interrupt mode and doesn't neeeed an INIT, and therefore can't get at the original trap address (ignoring the difficulty re: data registers), is to find out where MultiFinder remembers the appropriate values, and to poke at them immediately after the _Open succeeds. This has the major disadvantage that I'll need a new revision for each new MultiFinder. It has the advantage that, since MultiFinder's data structures are tagged with its signature and version number, the scheme can't break except by realizing that the workaround isn't available. It has also the major disadvantage that System 7.0 prohibits _Open from being called asynchronously, which IMHO is a very bad idea. That misfeature was introduced because the file table size is going to be dynamic. It would be better to resize the table in the synchronous case, and to return an error in the async case. This parallels what happens if a volume is off-line (eg. ejected). -- Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49+721+621127(Voice)/621227(PEP)
russotto@eng.umd.edu (Matthew T. Russotto) (07/26/90)
In article <q=$re2.1]1@smurf.sub.org> urlichs@smurf.sub.org (Matthias Urlichs) writes: >In comp.sys.mac.programmer, article <1990Jul24.133617.8305@eng.umd.edu>, > russotto@eng.umd.edu (Matthew T. Russotto) writes: >< In article <1990Jul23.201524.13849@ux1.cso.uiuc.edu> resnick@lees.cogsci.uiuc.edu (Pete Resnick) writes: >< > >< >1. Is this a problem as is? Will my file stay open between calls with >< >the file mark in the right place? [...] >< No problem. Files remain open unless explicitly closed. > >With one important exception: If the application which (according to >MultiFinder) opened the file quits, the file is automagically closed. >(This is only true for data forks; resource forks are assumed to get closed by >the resource manager.) >My "solution", which I use in my SingleShare server which runs in interrupt >mode and doesn't neeeed an INIT, and therefore can't get at the original trap >address (ignoring the difficulty re: data registers), is to find out where >MultiFinder remembers the appropriate values, and to poke at them immediately >after the _Open succeeds. Why not simply mess with $910? Or does MultiFinder worry about the heap and not the CurApName? Seems to me that Apple should make some way of opening the file and having it stay open-- like a constant to be added to ioPermssn, or something. Apple, are you listening? Apple? -- Matthew T. Russotto russotto@eng.umd.edu russotto@wam.umd.edu ][, ][+, ///, ///+, //e, //c, IIGS, //c+ --- Any questions? Hey! Bush has NO LIPS!
urlichs@smurf.sub.org (Matthias Urlichs) (07/27/90)
In comp.sys.mac.programmer, article <1990Jul26.134700.16427@eng.umd.edu>, russotto@eng.umd.edu (Matthew T. Russotto) writes: < In article <q=$re2.1]1@smurf.sub.org> urlichs@smurf.sub.org (Matthias Urlichs) writes: < > < >[...] If the application which (according to < >MultiFinder) opened the file quits, the file is automagically closed. < < Why not simply mess with $910? Or does MultiFinder worry about the heap and < not the CurApName? < MultiFinder worries about its internal process ID. So, that's not it, unfortunately. < Seems to me that Apple should make some way of opening the file and having it < stay open-- like a constant to be added to ioPermssn, or something. Good idea. < Apple, are you listening? Apple? -- Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49+721+621127(Voice)/621227(PEP)