hue@netcom.UUCP (Johathan Hue) (01/09/90)
I never saw tar on the Amiga so I ported John Gilmore's tar (the one gnu-tar is based on). There are a few Amiga specific features I'd like to add, so if anyone has any suggestions, I'm listening. 1) I would like to preserve the pure, script, delete, and archive bits. I was thinking that I could add an option that when creating an archive would cause them to be stored in the group and other bits, and when extracting would use the group and other bits to set the p,s,d, and a bits. This brings up another question, what should go in the group and other bits otherwise? I envision moving tar files between Amigas and UNIX boxes, right now I'm just replicating the owner's bits in the group and other fields. Does storing 0's make more sense? 2) I think it would be better to store the file with UNIX style names, i.e. leading / gets stored as ../, null string translates to ./, etc. That way you could extract it on a UNIX box with no problems. Extraction on the Amiga would convert back to Amiga style paths. Any objections? 3) Would tar be of any use as an incremental backup utility? I could add an option which would set (or unset, whatever the correct logic is) the archived bit of any file it archives. Replies by e-mail, please. -Jonathan
fnf@estinc.UUCP (Fred Fish) (01/10/90)
In article <5493@netcom.UUCP> hue@netcom.UUCP (Johathan Hue) writes: >1) I would like to preserve the pure, script, delete, and archive bits. I >was thinking that I could add an option that when creating an archive would >cause them to be stored in the group and other bits, and when extracting >would use the group and other bits to set the p,s,d, and a bits. This brings >up another question, what should go in the group and other bits otherwise? >I envision moving tar files between Amigas and UNIX boxes, right now I'm >just replicating the owner's bits in the group and other fields. Does storing >0's make more sense? I had to face the same questions when porting BRU to the Amiga. The BRU format started off as a clone of the tar format, but compatibility was later dropped in favor of enhancements to make the format, and utilities that manipulate it, more reliable. So I have some experience with this specific problem. First of all, it is a VERY strong plus to keep the formats compatible between Amiga and Unix. I regularly move stuff back and forth between the two on streaming tape with no problems at all. Thus stuffing "foreign bit patterns" into the mode word is probably the wrong solution. For BRU, I picked an area in the format that was reserved for future expansion (clever huh? :-) and stashed the real Amiga mode bits there. However, I still build a "fake Unix mode" on the Amiga by masking off the RWE bits and turning propagating them into the owner and group bits of the mode seen by UNIX. When importing archives from Unix, the owner RWX bits are turned into Amiga RWE bits and the deletable bit is set. Thus the conversions are: For archives created on Amiga: unix mode = amiga(RWE) << 6 | amiga(RWE) << 3 | amiga(RWE) amiga mode = image of mode bits For archives extracted on Amiga that were created on Unix: amiga mode = ((unix(mode) >> 5) & 0xF) | 1 For archives extracted on Amiga that were created on Amiga: amiga mode = mode bits from special amiga storage location I don't claim this is optimal (it took all of 15 minutes to design) but it works for me and I haven't had any complaints yet from any beta testers. >2) I think it would be better to store the file with UNIX style names, >i.e. leading / gets stored as ../, null string translates to ./, etc. >That way you could extract it on a UNIX box with no problems. Extraction >on the Amiga would convert back to Amiga style paths. Any objections? I don't do any filename translations at all. I can see both sides of this coin, and I'm not convinced that either way is particularly better. I'm open to being converted though... :-) >3) Would tar be of any use as an incremental backup utility? I could add >an option which would set (or unset, whatever the correct logic is) the >archived bit of any file it archives. BRU is, so I guess tar would be too. It sounds like you've started with the "right base", GNU tar is probably the best version of tar currently available. It's been interesting watching it pick up features over the years that BRU has had since 1983. Guess it's getting close to time to pull a few more rabbits out of my hat... :-) P.S. I've posted this rather than sending direct email since I think the issues are important to a wide audience, and I wouldn't mind getting some additional input. P.P.S I'd like a copy when you're done. :-) -Fred -- # Fred Fish, 1835 E. Belmont Drive, Tempe, AZ 85284, USA # 1-602-491-0048 asuvax!{nud,mcdphx}!estinc!fnf