ali@rocky.STANFORD.EDU (Ali Ozer) (12/08/87)
In article <1237@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: >In article <796@rocky.STANFORD.EDU>, I wrote: >> What's the correct way to change directories in a program without going >> back to the original directory at the end? > >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! >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? I'm not, because I do not want to connect back to my old directory! I got one message indicating that it seems to be OK to do an UnLock() on my ORIGINAL directory --- the one returned by CurrentDir(). In short: destdir = Lock ("whatever the new directory is", ACCESS_READ); UnLock (CurrentDir (destdir)); /*Error conditions, checks, etc, deleted for brevity*/ seems to work, but looks evil, goes against everything I've read and everything my parents told me. If I try to do what I've read, and I UnLock(destdir), well, the machine hangs on the first DOS operation after I quit --- mainly because I'm connected to a directory I have no lock on... So, the question is: Is the above OK for purposes of duplicating the functionality of "cd"? Ali ps. Oh, totally off the wall comment: Just yesterday I saw Amiga World on the news stands at Payless, right between MacWorld and two PC magazines. For the first time! They also had a few other computer magazines --- One for the C64, and for the Apple II.
jesup@pawl19.pawl.rpi.edu (Randell E. Jesup) (12/10/87)
In article <810@rocky.STANFORD.EDU> ali@rocky.UUCP (Ali Ozer) writes: ... > destdir = Lock ("whatever the new directory is", ACCESS_READ); > UnLock (CurrentDir (destdir)); > /*Error conditions, checks, etc, deleted for brevity*/ > >seems to work, but looks evil, goes against everything I've read and >everything my parents told me. If I try to do what I've read, and I >UnLock(destdir), well, the machine hangs on the first DOS operation after >I quit --- mainly because I'm connected to a directory I have no lock on... >So, the question is: Is the above OK for purposes of duplicating the >functionality of "cd"? Yes. In fact, the only way. I don't know WHO told you otherwise, but they were wrong. CurrentDir just replaces pr_currentdir with the lock you passed and returns you the old one. Note that the CD program also sets the cli_SetName field of the CLI structure. If you want to UnLock(destdir), do UnLock(CurrentDir(DupLock(destdir))). Then you can UnLock(destdir) :-) Another note: If your program is started from WB, you MUST save the original dir lock, and restore it before you exit, as WB remembers what things were set to, or some such. // Randell Jesup Lunge Software Development // Dedicated Amiga Programmer 13 Frear Ave, Troy, NY 12180 \\// lunge!jesup@beowulf.UUCP (518) 272-2942 \/ (uunet!steinmetz!beowulf!lunge!jesup)
ans@well.UUCP (Anne Schweizer) (12/12/87)
In article <796@rocky.STANFORD.EDU>, I wrote: > What's the correct way to change directories in a program without going > back to the original directory at the end? newdir = Lock(destdir,SHARED_LOCK; if(newdir) Unlock(CurrentDir(newdir)); This seems to be enough to prevent gurus. But especially in cases, where destdir isn't a static defined string, you should check if destir really is a dir !! It could also be a file !! mycd(destdir) char *destdir; { struct FileInfoBlock *finfo; struct FileLock *newdir; if(!Lock(destdir,HARED_LOCK)) return(FALSE): if(!AllocMem(sizeof(struct FileInfoBlock),MEMF_PUBLIC))) { UnLock(newdir); return(FALSE); /* Should return out of memory */ } if(!Examine(newdir,finfo)) { UnLock(newdir); FreeMem(finfo,sizeof(struct FileInfoBlock)); return(FALSE): /* Should return can't examine lock */ } if(finfo->fib_DirEntryType < 0 ) { UnLock(newdir); FreeMem(finfo,sizeof(struct FileInfoBLock)); return(FALSE): /* LOCK IS NOT A DIRECTORY !!!!!!!!!! */ } UnLock(CurrentDir(newdir)); FreeMem(finfo,sizeof(struct FileInfoBlock)); return(TRUE); /* Allright now ...... */ } -- Anne
peter@sugar.UUCP (Peter da Silva) (12/15/87)
In article <810@rocky.STANFORD.EDU>, ali@rocky.STANFORD.EDU (Ali Ozer) writes: > I'm not, because I do not want to connect back to my old directory! OK, that makes more sense now. > I got one message indicating that it seems to be OK to do an UnLock() > on my ORIGINAL directory --- the one returned by CurrentDir(). In short: > > destdir = Lock ("whatever the new directory is", ACCESS_READ); > UnLock (CurrentDir (destdir)); > /*Error conditions, checks, etc, deleted for brevity*/ This looks good to me. You're leaving exactly one directory lock open, which is the right thing to do. There was one lock open at the start (your original directory) and one at the end (the new current directory). All balances. If you close destdir, the first time you try to access your current directory you'll have an invalid lock. This is likely to guru you. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.