dale@amiga.UUCP (Dale Luck) (10/05/88)
I tried zoo out on the fish136 however it does not preserve the protection bits. Especially the 's' bit which is new in 1.3 the 's' bit means the file is a script. When extracting files with zoo the ewrd bits are all set. According to the doc's, Brian Waters did the port to the amiga. Can the protect bit saving be fixed in the next release? Dale
ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (10/06/88)
In article <2996@amiga.UUCP> dale@amiga.UUCP (Dale Luck) writes: > I tried zoo out on the fish136 however it does not preserve the >protection bits. [ ... ] Stupid idea: Why not, as a stopgap measure, include in the ZOO archive an EXECUTE.ME file which contains a bunch of Protect commands... _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab -- The Guy in The Cape INET: well!ewhac@ucbvax.Berkeley.EDU \_ -_ Recumbent Bikes: UUCP: pacbell > !{well,unicom}!ewhac O----^o The Only Way To Fly. hplabs / (pronounced "AE-wack") "Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctor
jbwaters@bsu-cs.UUCP (J. Brian Waters) (10/06/88)
In article <2996@amiga.UUCP>, dale@amiga.UUCP (Dale Luck) writes: > > I tried zoo out on the fish136 however it does not preserve the > protection bits. Especially the 's' bit which is new in 1.3 > the 's' bit means the file is a script. When extracting > files with zoo the ewrd bits are all set. If I remember correctly the version on fish136 is 1.71, the preservation of file attributes was added to 2.00 for the Unix version but not the Amiga version as the docs I have indicate that the only command that supports them is delete and that did not seem to warrent the code to preserve the bits. > According to the doc's, Brian Waters did the port to the amiga. > Can the protect bit saving be fixed in the next release? > Dale If it would be a useful feature it can be added to the next release. The next release is almost ready though (2.01). It so far is only bug fixes... no new features. Any idea on how long it would be till I could get 1.3 to be able to test the saving of the 's' bit and know which bit it is? Any other bits worth preserving? Or would it be best not to try and use zoo's portable attribute bit mask and just save and restore the raw mask. As I am getting ready to release 2.01 shortly, now would be a good time to send any suggestions, bug reports etc. that anyone would like to see in zoo on the Amiga. Please mail them to me as I am not always able to keep up with the Amiga news groups. -- Brian Waters <backbone>!{iuvax|pur-ee}!bsu-cs!jbwaters uunet!---/
thad@cup.portal.com (10/10/88)
Besides the DELETE program/command being cognizant of file protection bits, the COPY (and friends) are also indirectly affected (re: copying onto a file that is read- and execute-only).
kim@amdahl.uts.amdahl.com (Kim DeVaughn) (10/12/88)
In article <9920@cup.portal.com>, thad@cup.portal.com writes: > Besides the DELETE program/command being cognizant of file protection bits, > the COPY (and friends) are also indirectly affected (re: copying onto a file > that is read- and execute-only). In addition to preserving the "s" (script) bit, another one that Zoo (or any archiver program) should preserve is the "p" (pure) bit, which is used by the Resident command. It could be a problem, especially for inexperienced users, to figure out if this bit should be set, if it gets "lost". Granted, you don't *need* to make anything resident, but it can certainly improve the perceived performance of the system. Actually, my suggestion to Brian is to preserve *all* the protection bits in Zoo except for the "a" (archive) bit (on the presumption that when Zoo'd archive in unZoo'd, the embedded files anr now "new" to the system, and should be picked-up on the next backup run). /kim -- UUCP: kim@amdahl.amdahl.com or: {sun,decwrl,hplabs,pyramid,uunet,oliveb,ames}!amdahl!kim DDD: 408-746-8462 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 BIX: kdevaughn GEnie: K.DEVAUGHN CIS: 76535,25
dillon@CORY.BERKELEY.EDU (Matt Dillon) (10/13/88)
:In article <9920@cup.portal.com>, thad@cup.portal.com writes: :> Besides the DELETE program/command being cognizant of file protection bits, :> the COPY (and friends) are also indirectly affected (re: copying onto a file :> that is read- and execute-only). Kim (kim@amdahl.amdahl.com) Writes: :In addition to preserving the "s" (script) bit, another one that Zoo :(or any archiver program) should preserve is the "p" (pure) bit, which :is used by the Resident command. I say, preserve them all! Real simple... It's just a longword. -Matt
dhesi@bsu-cs.UUCP (Rahul Dhesi) (10/13/88)
In article <8810121728.AA14821@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > I say, preserve them all! Real simple... It's just a longword. This could cause trouble in the future. Most of the bits are currently undefined. Suppose you store some files in a zoo archive, and zoo stores all the attribute bits as it gets them from the OS, and one of them happens to have a random value of 1. Suppose a year from now, this bit has been defined by Commodore to mean "this is a temporary file that should be deleted as soon as it is closed". When you unzoo the files then, zoo will restore all the attribute bits, and all these files will get deleted as soon as zoo finishes creating them. Or, suppose zoo forces all the currently-undefined bits to zero before storing them. But suppose Commodore happens to later assign a strange meaning to the value 0 for one of these bits. You're in trouble again. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi
jbwaters@bsu-cs.UUCP (J. Brian Waters) (10/13/88)
In article <8810121728.AA14821@cory.Berkeley.EDU>, dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > : Kim (kim@amdahl.amdahl.com) Writes: > :In addition to preserving the "s" (script) bit, another one that Zoo > :(or any archiver program) should preserve is the "p" (pure) bit, which > :is used by the Resident command. > > I say, preserve them all! Real simple... It's just a longword. The problem is the zoo file format does not at present reserve 32 bits for file attributes. Given the current format I can preserve 22 bits which should last for at least a few more systems software upgrades. If a way can be found to preserve all 32 bits without breaking the ability to extract .zoo's created on the Amiga on other machines I will impliment it. If not I will at least save all that are currently defined as of 1.3. One bit that will be an excption to the above is the archive bit. Almost everyone that sent me mail said that it should not be saved, and those that did not say to not save it, did not say they wanted it saved. The other bit that is being debated is the 'h' hidden bit. Some people are telling me not to save it, as they do not want any automatically created hidden files on thier system, and some are saying to save it, to avoid any possable need for an execute.me file in a zoo archive. -- Brian Waters <backbone>!{iuvax|pur-ee}!bsu-cs!jbwaters uunet!---/
jbwaters@bsu-cs.UUCP (J. Brian Waters) (10/13/88)
> Suppose you store some files in a zoo archive, and zoo stores all the > attribute bits as it gets them from the OS, and one of them happens to > have a random value of 1. Suppose a year from now, this bit has been > defined by Commodore to mean "this is a temporary file that should be > deleted as soon as it is closed". When you unzoo the files then, zoo If I read the AmigaDOS docs correctly this is not a problem. The bits are undefined but have a forced value. I forget if it is 0 or 1 though. Then in the future if the bit gets a meaning it is the reverse of the default that activates the attribute. This would make it safe to store all 32 bits of a file. And also prevents a future version of the op sys from misinterpriting any files created prior to the release of the version that added the new bit. -- Brian Waters <backbone>!{iuvax|pur-ee}!bsu-cs!jbwaters uunet!---/
fnf@fishpond.UUCP (Fred Fish) (10/15/88)
In article <4305@bsu-cs.UUCP> jbwaters@bsu-cs.UUCP (J. Brian Waters) writes: >In article <8810121728.AA14821@cory.Berkeley.EDU>, dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: >> >> I say, preserve them all! Real simple... It's just a longword. > >The problem is the zoo file format does not at present reserve 32 bits for file >attributes. Given the current format I can preserve 22 bits which should last >for at least a few more systems software upgrades. I don't know anything about the zoo format, but if there are any spare (reserved) longwords laying around, you can do what I did when I ported bru: On archive creation: Translate the existing defined amiga specific attribute bits to the portable attribute bits, and save these as the portable attributes. Save a "true copy" of the amiga specific attribute bits in one of the formerly "reserved for future use" longwords. Set the appropriate bit that specifies that this archive was created on an Amiga so the "true copy" is valid. On extraction: Check the bit that specifies that this archive was created on an Amiga. If it was, restore the attributes from the "true copy" of the attributes, stored in the formerly reserved longword. If the archive was created on a non-Amiga machine, restore the attributes from the portable attributes, translating as necessary. Note some attributes may be lost, but that is life. Apply any user specified translations to the attributes of the file, such as explicitly setting or resetting the "file-archived" bit. If the zoo format definition doesn't have any "reserved for future use" fields, then I guess you are out of luck... -Fred -- # Fred Fish, 1346 West 10th Place, Tempe, AZ 85281, USA # noao!nud!fishpond!fnf (602) 921-1113
dhesi@bsu-cs.UUCP (Rahul Dhesi) (10/16/88)
In article <8810132228.AA01849@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > I think you are just confused a bit.-) These bits, all 32 of them, >already EXIST and can even be modified. They don't mean anything yet, but >they are fully supported and are all set to the filesystem's idea of false. Ok, I was confused a bit. (I'm an MS-DOS user.) Let's hope you all are right and it's safe to restore currently-unused attribute bits to zero even in the future. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi
dhesi@bsu-cs.UUCP (Rahul Dhesi) (10/16/88)
In article <135@fishpond.UUCP> fnf@fishpond.UUCP (Fred Fish) writes: >If the zoo format definition doesn't have any "reserved for future use" >fields, then I guess you are out of luck... Actually it does, and what's more, they are defined in such a way that zoo archives containing these additional fields will remain downward compatible in the future. However, zoo archives have been steadily growing in size since 1986. Each new field that is added enlarges the archive slightly. This makes a difference especially if you have an archive containing many small files. The main reason for avoiding defining too many additional fields is the complexity of the archive (bigger archives) and the complexity of the code (bigger executable zoo), less space left on your disk. The MS-DOS zoo version 1.0 was 29 kilobytes; version 2.01 is now up to 40 K and still growing. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi
gmg@hcx.uucp (Greg M. Garner) (01/21/89)
Does anyone out there know why zoo crashes when I try to unpack or list the contents of zoo files from my hardrive? I can unpack stuff fine on floppy, rad:, ram:, vd0:, but not supradrive! I am using a supra 5.01a software, and the ffs is mounted on both of my 30 meg partitions. I have a 512k hack, and 2 meg starboard. Zoo will guru the machine every timeI try to unpack something. Sometimes it will list the contents of a zoo file about halfway through, then crash. Thanks for any ideas! Greg Garner 501-442-4847 gmg@hcx.uucp USENET: ...!uunet!harris.cis.ksu.edu!hcx!gmg
limonce@pilot.njin.net (Tom Limoncelli) (01/21/89)
In article <1672@cveg.uucp> gmg@hcx.uucp (Greg M. Garner) writes: > Does anyone out there know why zoo crashes when I try to unpack or > list the contents of zoo files from my hardrive? I can unpack stuff > fine on floppy, rad:, ram:, vd0:, but not supradrive! I am using a > supra 5.01a software, and the ffs is mounted on both of my 30 meg > partitions. > Greg Garner > gmg@hcx.uucp USENET: ...!uunet!harris.cis.ksu.edu!hcx!gmg Do you have 1.3 and the FFS? The problem you describe sounds like you have a pre-release of 1.3's FFS which had a bug that showed up very well when running ZOO. Of course, there's no need to post that information since ONLY REGISTERED DEVELOPERS were supposed to have 1.3 and they all read about that bug in AmigaMail; and if your problem is caused by an out of date version of 1.3 then you are a developer and already know this... right? (Sorry for shouting... it also might be that you don't have your stack set large enough... :-) -Tom -- Tom Limoncelli -- tlimonce@drunivac.Bitnet -- limonce@pilot.njin.net Drew University -- Madison, NJ -- 201-408-5389 Standard ACM Regional Contest winner! See you at Disclaim the nationals in Louisville, KY on Feb 21-23! er.
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (01/23/89)
In <1672@cveg.uucp>, gmg@hcx.uucp (Greg M. Garner) writes: >Does anyone out there know why zoo crashes when I try to unpack or >list the contents of zoo files from my hardrive? I can unpack stuff >fine on floppy, rad:, ram:, vd0:, but not supradrive! I am using a >supra 5.01a software, and the ffs is mounted on both of my 30 meg >partitions. I have a 512k hack, and 2 meg starboard. Zoo will guru >the machine every timeI try to unpack something. Sometimes it will >list the contents of a zoo file about halfway through, then crash. >Thanks for any ideas! Sounds like you might be running a prerelease version of FFS. Zoo had some problems on early (beta/gamma/omega FFS's, but not on the release version. -larry -- Frisbeetarianism: The belief that when you die, your soul goes up on the roof and gets stuck. +----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca or uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 | +----------------------------------------------------------------------+
grwalter@watmath.waterloo.edu (Fred Walter) (01/25/89)
In article <2169@van-bc.UUCP> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: >In <1672@cveg.uucp>, gmg@hcx.uucp (Greg M. Garner) writes: >>Does anyone out there know why zoo crashes when I try to unpack or >>list the contents of zoo files from my hardrive? > >Sounds like you might be running a prerelease version of FFS. Zoo had some >problems on early (beta/gamma/omega FFS's, but not on the release version. Um... I'm running the release version of 1.3 and I have my stack set to 30000, and I occasionly get zoo seemingly just looping while trying to read a zoo archive. It doesn't crash (I can break it), but it is annoying to have to the zoo archive to ram: to look at it. I don't recall offhand what else I have running in the background that may effect things. fred