ali@rocky.STANFORD.EDU (Ali Ozer) (12/03/87)
---
Ok, two questions...
What's the correct way to change directories in a program without going
back to the original directory at the end? You first obtain a lock, with
ACCESS_READ, then you examine it to make sure it is a directory, then you
do a CurrentDir(). That's where the program ends. Now, do you need an
UnLock() on the original lock you obtained? Without the UnLock(), everything
seems to work fine, even after the program is done. With an UnLock(),
the program exists fine, except the first dos operation you do ("dir," for
instance), the machine hangs. Everything I read says to do an UnLock()
on every lock obtained, though, so what's wrong? This is with Manx 3.40a.
Second question: A friend's Amiga 1000 will not read/write from the floppy
drives unless the right mouse button is held down. I haven't seen this, but
he says it's been this way for a while. The machine won't even read kickstart
or workbench. He's probably going to take it in some day, but, in the meantime,
has anyone else experienced this? Any suggestions?
Ali Ozer, ali@rocky.stanford.edupeter@sugar.UUCP (Peter da Silva) (12/07/87)
In article <796@rocky.STANFORD.EDU>, ali@rocky.STANFORD.EDU (Ali Ozer) writes: > What's the correct way to change directories in a program without going > back to the original directory at the end? You first obtain a lock, with > ACCESS_READ, then you examine it to make sure it is a directory, then you > do a CurrentDir(). That's where the program ends. Now, do you need an > UnLock() on the original lock you obtained? Without the UnLock(), everything > seems to work fine, even after the program is done. With an UnLock(), > the program exists fine, except the first dos operation you do ("dir," for > instance), the machine hangs. Everything I read says to do an UnLock() > on every lock obtained, though, so what's wrong? This is with Manx 3.40a. You UnLock() any lock *you* obtain (==Lock()). Your original directory wasn't Lock()ed by you, so you better not UnLock it. Otherwise either CLI will be trying to work without a valid lock (accessed next time you do a dir), or Workbench will be UnLocking an UnLocked lock, or maybe even using it! I am not sure if you're doing this or not. Let's parse that message again. When you do a CurrentDir(), you also need to keep that lock around as long as you're in that directory. When you finish, CurrentDir() back to your original directory's lock (returned from CurrentDir()). THEN you can trash the new lock. You doing that? -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.
schaub@sugar.UUCP (Markus Schaub) (12/07/87)
In article <1237@sugar.UUCP>, peter@sugar.UUCP (Peter da Silva) writes: > In article <796@rocky.STANFORD.EDU>, ali@rocky.STANFORD.EDU (Ali Ozer) writes: > > What's the correct way to change directories in a program without going > > back to the original directory at the end? You first obtain a lock, with > > You UnLock() any lock *you* obtain (==Lock()). Your original directory wasn't > Lock()ed by you, so you better not UnLock it. Otherwise either CLI will be To my knowledge CurrentDir just replaces the process's currentDir lock. To write a cd program you - lock the new directory - call CurrentDir() - unlock the returned old lock So Peter, here I think you have to unlock something you did not lock yourself and leave something locked you locked. The only problems I had were the locks for Workbench arguments. Where am I starting, etc. There I decided to leave all locks locked and I assume WB does the unlocking. -- // Markus Schaub uunet!nuchat!sugar!schaub (713) 523 8422 // M2Amiga Developer trying to get back the money I paid for my \\ // Amiga by selling a few M2Amiga. \X/ c/o Interface Technologies Corp, 3336 Richmond #323, Houston Tx 77098
bryce@hoser.berkeley.edu (Bryce Nesbitt) (12/09/87)
In article <1245@sugar.UUCP> schaub@sugar.UUCP (Markus Schaub) writes: > >The only problems I had were the locks for Workbench arguments. Where am I >starting, etc. There I decided to leave all locks locked and I assume WB >does the unlocking. *Please* there is no need to assume! Lots of ways to check: Run the program multiple times, see if it eats memory. Check for undeleteable directories. Use AmigaMonitor and check directly for resource hogging. One of the early Fish AmigaMonitors has a bug under V1.2 in that category, so get the right version. |\ /| . Ack! (NAK, SOH, EOT) {o O} . bryce@hoser.berkeley.EDU -or- ucbvax!hoser!bryce (") U WARNING: hoser's spool directory eats a *lot* of mail. :-(