Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!sun-barr!newstop!sun!amdcad!dgcad!dg-rtp!wgate!lanzo From: lanzo@wgate.UUCP (Mark Lanzo) Newsgroups: comp.sys.amiga.programmer Subject: Re: dos.library ACTION_SET_DATE question. Message-ID: <183@atesysv.UUCP> Date: 10 Apr 91 16:10:56 GMT References: <182@atesysv.UUCP> Reply-To: lanzo@atesysv.UUCP (Mark Lanzo) Organization: Wandel & Goltermann Technologies, Inc. Lines: 57 As Randall Jesup has already pointed out, the args for SET_DATE are: Arg1 = unused Arg2 = lock to parent dir (BPTR) Arg3 = name of file (BSTR) Arg4 = CPTR to date stamp Also, ben@epmooch.UUCP (Rev. Ben A. Mesander) writes: >>Also, try this: >> >> 3a. Get a lock on DF1: >> LOCATE_OBJECT: Arg1=NULL, Arg2=NULL, Arg3=Shared >> (assume pickpacket returns "FileLock 1"). >> 3b. Get a lock on DF1:ruru >> LOCATE_OBJECT: Arg1="FileLock 1", Arg2="ruru", Arg3=Shared >> (assume pickpacket returns "FileLock 2"). >> 3c. Now do the SET_DATE, using "FileLock 2". >Now that's strange - I thought that I had to put a lock on the parent >directory in the SET_DATE packet, not a lock on the file itself. Whooops. Brain fault. Cortex dumped. What I was *trying* to say here was that it was important to get a lock on DF1: as the parent of the file "ruru", and then use that lock + the filename for subsequent calls to routines which take both a lock and a name. The comment was triggered by a misconception I held for a while which really kept me confused for a long time while working on Pickpacket_2 -- namely, that a NULL for the parent lock meant "Root directory". The point I was originally trying to make was simply that you had to make sure you had a real lock on the root of the volume, rather than using NULL. NULL_Lock + "ruru" != Lock_on_DF1: + "ruru" The LOCATE_OBJECT packet seems to have the special-case that a NULL filelock represents the root directory for the volume, but other packets don't also have this behavior (unfortunately, IMHO). Also, the 3 steps shown above were based on the premise that the original article was correct in its description of the args -- that Arg1 was a filelock, and Arg2 was the DateStamp. >>If this is due to a bug in pickpacket 1.0, then the solution is to wait >>until I finish with pickpacket 2.0! >Yeah, except I'd like to get it done ASAP! :-) Sigh. Me too. 1/2 :-) [ or is that 1/2 :-( ? ] Back to work I guess, --Mark-- ( slinking off with proverbial tail between the legs :-) )