jv@mhres.mh.nl (Johan Vromans) (02/14/89)
The following strange thing happens when I use the recently
posted zoo program ("~ > " is the shell prompt):
~ > date
Mon Feb 13 19:49:19 MET 1989
~ > touch xxx.tmp
~ > zoo aP xxx.zoo xxx.tmp
Zoo: xxx.tmp -- ( 0%) added
~ > zoo l xxx.zoo
Archive xxx.zoo:
Length CF Size Now Date Time
-------- --- -------- --------- --------
0 0% 0 13 Feb 89 19:49:24+64 xxx.tmp
-------- --- -------- --------- --------
0 0% 0 1 file
~ > rm xxx.tmp
~ > zoo x xxx.zoo xxx.tmp
Zoo: xxx.tmp -- extracted
~ > ls -l xxx.tmp
-rw-rw-rw- 1 jv bsp 0 Feb 16 1989 xxx.tmp
As you can see, after extraction, the date of the file is a few
days ahead! (No, it doesn't make difference if the file is not empty).
Anyone else encountered this?
--
Johan Vromans jv@mh.nl via european backbone (mcvax)
Multihouse [A-Za-z ]* [NB]V uucp: ..!mcvax!mh.nl!jv
Gouda - The Netherlands phone: +31 1820 62944davidsen@steinmetz.ge.com (William E. Davidsen Jr) (02/14/89)
In article <2880@mhres.mh.nl> jv@mhres.mh.nl (Johan Vromans) writes: | As you can see, after extraction, the date of the file is a few | days ahead! (No, it doesn't make difference if the file is not empty). | | Anyone else encountered this? I haven't seen anything like that. I run zoo on Xenix, Ultrix, and SunOS and have not had a problem. I've recently been using it to move a package around between machines, and recompile the new parts with SCCS and make. If there were a date problem I would see it right away. Tell us a bit more about the machine on which you're running. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
dhesi@bsu-cs.UUCP (Rahul Dhesi) (02/15/89)
In article <2880@mhres.mh.nl> jv@mhres.mh.nl (Johan Vromans) writes: >Length CF Size Now Date Time >-------- --- -------- --------- -------- > 0 0% 0 13 Feb 89 19:49:24+64 xxx.tmp ^^^ The file is being stored in the archive with its timezone 64 hours west of where you are. At extraction time zoo adjusts the time for the timezone, yielding a wrong timestamp. (Since the zoo code was not designed to handle timezones larger than 24 hours away, this may cause other overflow problems somewhere.) EMERGENCY WORK-AROUND Undefine the GETTZ symbol with "#undef GETTZ" at the end of the file options.h, delete all object files, and recompile the whole thing. Zoo will no longer save, list, or restore timezones. Local times will be still fine, but an archive moved to a different timezone will still show the original local time. BUG FIX STRATEGY The code that stores the timezone into the archive is in function newdir() in file zooadd2.c: long gettz(); direntry->tz = (uchar) (gettz() / (15 * 60)); /* seconds => 15-min units */ The gettz() function, found in bsd.c and sysv.c, must return the timezone, in seconds west of GMT, as a long value. The above code scales this value to to 15-minute units, casts the result to unsigned char (which is typedef'd as uchar), and assigns it to direntry->tz. So I suggest: (a) confirm that gettz() is working on your system as implemented in bsd.c or sysv.c; (b) confirm that the value assigned to direntry->tz is your timezone, in 15-min units, west of GMT. If the above works, then the problem is in the extract/list code, which is incorrectly interpreting the stored timezone value. More about that in private email if necessary. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi ARPA: bsu-cs!dhesi@iuvax.cs.indiana.edu
bobmon@iuvax.cs.indiana.edu (RAMontante) (02/16/89)
dhesi@bsu-cs.UUCP (Rahul Dhesi) <5698@bsu-cs.UUCP> : -The file is being stored in the archive with its timezone 64 hours west -of where you are. At extraction time zoo adjusts the time for the -timezone, yielding a wrong timestamp. (Since the zoo code was not -designed to handle timezones larger than 24 hours away, this may cause -other overflow problems somewhere.) So zoo won't port to slowly-rotating planets, huh? (I didn't realize the Internet had such good connectivity :-)