steve@violet.berkeley.edu (Steve Goldfield) (05/10/89)
I agree that the description of 7.0 sounds like Apple is addressing most of the complaints/suggestions/etc. for improving the Mac system. I have a question to which somebody may know the answer. The document states that to use virtual memory, I could install the PMMU chip in my Mac II. I phoned our campus distributor, and all they know about is the 68030 board which sells for about $1,600. They said it would probably take about three weeks for information from Apple to trickle down to them. The Apple release says that the 68851 PMMU chip is "currently available." Does anyone have a ballpark figure on what such a chip costs/will cost? Steve Goldfield
kateley@Apple.COM (Jim Kateley) (05/10/89)
In article <24216@agate.BERKELEY.EDU> steve@violet.berkeley.edu (Steve Goldfield) writes: >I have a question to which somebody may know the answer. >The document states that to use virtual memory, I could >install the PMMU chip in my Mac II. I phoned our campus >distributor, and all they know about is the 68030 board >which sells for about $1,600. They said it would probably >take about three weeks for information from Apple to >trickle down to them. The Apple release says that the >68851 PMMU chip is "currently available." Does anyone >have a ballpark figure on what such a chip costs/will cost? > The 68851 PMMU is available from Apple as a finished goods product. It's part number is M0221, and has a SRP of $499.00, which includes dealer installation (which is required). It has been on the retail finished goods price pages for quite awhile, under the A/UX products section. Jim Kateley UUCP: {sun, voder, nsc, mtxinu, dual}!apple!kateley S,P,HnS! DOMAIN: kateley@apple.COM Applelink: kateley1 Disclaimer: What I say, think, or smell does not reflect any policy or stray thought by Apple Computer, Inc.
labc-3dc@e260-3f.berkeley.edu (Andy McFadden) (05/10/89)
Discussions about the Macintosh do not belong in comp.sys.apple; please edit your "Newsgroups:" lines so that you don't cross-post to an Apple II only group. Thank you. -- fadden@cory.berkeley.edu (Andy McFadden) ...!ucbvax!cory!fadden labc-3dc@widow.berkeley.edu
dcw@athena.mit.edu (David C. Whitney) (05/11/89)
I don't mean to get ugly, but... WHAT HAS THIS GOT TO DO WITH THE APPLE //? Who originally posted this stuff to comp.sys.apple? Comp.sys.apple is exclusively Apple // talk, and practically all of us have little or no interest in reading about Mac system upgrades. Now, if somebody inside Apple is anxious to spout off about new system software, then where were you when GS/OS 5.0 was in the works? Granted, I was pleasantly surprised when I watched the demo at AppleFest, but if you are going to write GOBS of stuff about Mac system stuff, I think we Apple // folks can expect to hear about GS/OS stuff when appropriate. Dave Whitney A junior in Computer Science at MIT dcw@athena.mit.edu ...!bloom-beacon!athena.mit.edu!dcw dcw@goldilocks.mit.edu I wrote Z-Link & BinSCII. Send me bug reports. I use a //GS. Send me Tech Info. "This is MIT. Collect and 3rd party calls will not be accepted at this number."
brian@natinst.com (Brian H. Powell) (05/11/89)
In article <30398@apple.Apple.COM>, kateley@Apple.COM (Jim Kateley) writes: > The 68851 PMMU is available from Apple as a finished goods product. > It's part number is M0221, and has a SRP of $499.00, which includes > dealer installation (which is required). Of course, you may be able to get a cheaper price somewhere else. And it's not hard to install the chip if you've had any previous experience installing chips. Of course also, I'm not suggesting that you make any unauthorized modifications to your "open" mac. Especially if it's under warranty. Brian
cramer@athens.iex.com (Bill Cramer) (05/11/89)
In article <30398@apple.Apple.COM> kateley@Apple.COM (Jim Kateley) writes: >The 68851 PMMU is available from Apple as a finished goods product. >It's part number is M0221, and has a SRP of $499.00, which includes >dealer installation (which is required). It has been on the retail >finished goods price pages for quite awhile, under the A/UX products >section. Is there some magic involved in the upgrade or is it as simple as dropping the chip into the empty socket? ($499 seems like a reasonable price for the average Mac user, but being a Mac abuser, I'd like to have the opportunity to bend a few pins for myself :-) Bill Cramer IEX Corporation Plano, Texas {uunet,killer,convex}!iex!cramer
mfi@beach.cis.ufl.edu (Mark Interrante) (05/12/89)
In the release there was mention that All the system will be 32bit clean. Does thins mean that the finder and other *interesting* parts of the macos will be ported to AUX? Will it soon be able to run macos under AUX? Inquiring minds want to know... ----------------------------------------------------------------------------- Mark Interrante Software Engineering Research Center mfi@beach.cis.ufl.edu CIS Department, University of Florida 32611 ----------------------------------------------------------------------------- "X is just raster-op on wheels" - Bill Joy, January 1987
prl3546@tahoma.UUCP (Philip R. Lindberg) (05/13/89)
From article <24216@agate.BERKELEY.EDU>, by steve@violet.berkeley.edu (Steve Goldfield): > I agree that the description of 7.0 sounds like Apple is > addressing most of the complaints/suggestions/etc. for > improving the Mac system. ^^^^^^^ > > Steve Goldfield Hey! What is this doing here?!?!?
ra_robert@gsbacd.uchicago.edu (05/15/89)
In article <SARREL.89May14224531@galley.cis.ohio-state.edu>, sarrel@galley.cis.ohio-state.edu (Marc Sarrel) writes... [smithw@yvax.byu.edu talks about getting VM on his 8 MB IIx] >Sorry to burst your bubble, but the maximum amount of RAM (real + >virtual) is still 8Meg. Since the applications share a single address >space and the ROMs (in your machine, not Pluses) are addressed >starting at 8Meg (and going up), the only space for RAM is below 8Meg. Hm...in the 7.0 Release, it said: "32-Bit Addressing allows Macintosh computers to extend their memory capacities beyond 8 megabytes to 128 MB of physical RAM and up to 4 Gigabytes of virtual address space." What's the straight dope here? Is this large address space just planned for future machines (with current machines being limited to 8 MB RAM/VM)? Robert ------ ra_robert@gsbacd.uchicago.edu ------ generic disclaimer: all my opinions are mine ------ MOFO knows!
FTWILSON@pucc.Princeton.EDU (Frederick Todd Wilson) (05/15/89)
In article <3234@tank.uchicago.edu>, ra_robert@gsbacd.uchicago.edu writes: >In article <SARREL.89May14224531@galley.cis.ohio-state.edu>, sarrel@galley.cis.ohio-state.edu (Marc Sarrel) writes... >[smithw@yvax.byu.edu talks about getting VM on his 8 MB IIx] > >>[SARREL@GALLEY.CIS asserts that 7.0 will not allow memory addressing ab meg] >Hm...in the 7.0 Release, it said: > >"32-Bit Addressing allows Macintosh computers to extend their >memory capacities beyond 8 megabytes to 128 MB of physical RAM and >up to 4 Gigabytes of virtual address space." While this is by no means a researched and official response, I must agree: all info that I have read on 7.0 indicates that 32-bit addressing will allow Macs ('020 and '030, I believe) to extend their memory access well beyond the current limit of 8 meg. F. Todd Wilson Apple Student Rep, Princeton University AppleLink: ST0161 "My opinions are my own. Who else would want 'em anyway?!" >------
shap@polya.Stanford.EDU (Jonathan S. Shapiro) (05/16/89)
In article <3234@tank.uchicago.edu> ra_robert@gsbacd.uchicago.edu writes: >In article <SARREL.89May14224531@galley.cis.ohio-state.edu>, sarrel@galley.cis.ohio-state.edu (Marc Sarrel) writes... >Hm...in the 7.0 Release, it said: > >"32-Bit Addressing allows Macintosh computers to extend their >memory capacities beyond 8 megabytes to 128 MB of physical RAM and >up to 4 Gigabytes of virtual address space." > > >What's the straight dope here? Is this large address space just planned for >future machines (with current machines being limited to 8 MB RAM/VM)? If you actually look at the low memory pointer to the rom, you will discover that the rom lives at address 0x40800000. This means that in a 32 bit system, there is plenty of room for it. The NuBus card addresses can already be mapped into higher memory without error (I have done it). The killer is tht the current ROM is not 32 bit clean. In particular, the current ROM doesn't like to have the MMU turned on in 32 bit mode, and the memory manager gets most unhappy. Point is that a new set of ROMS should indeed make it possible to put in up to 128K of real memory. Why you would want to isn't clear, as the system is intrinsically pretty slow. Jon
shebanow@apple.com (Andrew Shebanow) (05/16/89)
The System 7.0 Virtual Memory system allows up to 14 Megs of virtual address space in 24 Bit Mode. It does so by using 1 Megabyte from each UNOCCUPIED NuBus slot as heap space. (6 slots * 1 Meg/Slot) + 8 Megs = 14 Megs When newer, 32 Bit ROMs are released (either for old machines or for new machines, but don't ask me which ones...), you will be able to access disgustingly large virtual address spaces, assuming that you have the disk space available... Andrew Shebanow MacDTS - All Opinions Are Mine, and Mine Alone - "Wanna see something REALLY scary?"
amanda@intercon.UUCP (Amanda Walker) (05/16/89)
In article <9210@polya.Stanford.EDU>, shap@polya.Stanford.EDU (Jonathan S. Shapiro) writes: > The killer is tht the current ROM is not 32 bit clean. > In particular, the current ROM doesn't like to have the MMU turned on > in 32 bit mode, and the memory manager gets most unhappy. Actually, an awful lot of the II & IIx ROMs actually are 32-bit clean-- witness the A/UX toolbox. The biggest piece seems to be the memory manager, as I remember, but most of that can be handled by making master pointers 8 bytes (a second longword for the flags)... -- Amanda Walker <amanda@intercon.UUCP> InterCon Systems Corporation
stores@unix.SRI.COM (Matt Mora) (05/16/89)
In article <599smithw@yvax.byu.edu> smithw@yvax.byu.edu writes: >Hooray for VM. Those who enjoy the MacOS environment but use memory >intensive software (mathematica, maple, etc.) have been praying for >something like this to come. I have a IIx with 8MB ram and am constantly >running out of memory. Now all I want to know is when can I get my >greedy little hands on a beta version.... WOW! 8megs of real ram must be nice. I am testing the virtual init from connectix and have 8 megs of VMem. This raises two questions. 1) what is the virtual memory limit of 7.0, is it 8megs also or is it limited to disk space. 2) What's going to happen to connectix? Did Apple just obsolete them? >Bill Smith >(smithw@yvax.byu.edu) >My opinions are my own.... so are mine... -- ___________________________________________________________ Matthew Mora SRI International stores@unix.sri.com ___________________________________________________________
werner@molokai.sw.mcc.com (Werner Uhrig) (05/17/89)
In article <1887@internal.Apple.COM>, shebanow@apple.com (Andrew Shebanow) writes: > The System 7.0 Virtual Memory system allows up to 14 Megs of virtual > address space in 24 Bit Mode. It does so by using 1 Megabyte from each > UNOCCUPIED NuBus slot as heap space. > > (6 slots * 1 Meg/Slot) + 8 Megs = 14 Megs > "Wanna see something REALLY scary?" RATS! or does this mean I can also add 6 Megs for the non-existing, unoccupied NuBus slots in the SE-30? I guess, I finally found a reason why I should have waited the 12 weeks delivery time quoted by Apple for a Developer's IIcx ... -- --------------------------> please send REPLIES to <------------------------ INTERNET: uhrig@mcc.com (if unavailable: werner@rascal.ics.utexas.edu) UUCP: ...<well-connected-site>!milano!werner ALTERNATIVE: werner@astro.as.utexas.edu OR werner@utastro.UUCP
goldman@apple.com (Phil Goldman) (05/18/89)
In article <2362@molokai.sw.mcc.com> werner@molokai.sw.mcc.com (Werner Uhrig) writes: > > (6 slots * 1 Meg/Slot) + 8 Megs = 14 Megs > > "Wanna see something REALLY scary?" > > RATS! or does this mean I can also add 6 Megs for the non-existing, > unoccupied NuBus slots in the SE-30? Yes, except that on the SE/30 one of the "fake" slots is taken up by the video, so you can only get 13Meg. This is true on most MacIIs too, w/ an actual video card, unless they are run as file servers w/out video. -Phil Goldman Apple Computer
paul@taniwha.UUCP (Paul Campbell) (05/18/89)
In article <2362@molokai.sw.mcc.com> werner@molokai.sw.mcc.com (Werner Uhrig) writes: >> (6 slots * 1 Meg/Slot) + 8 Megs = 14 Megs > > RATS! or does this mean I can also add 6 Megs for the non-existing, > unoccupied NuBus slots in the SE-30? > Yes it does - what they really mean is 'the unused virtual addresses where the slots turn up in 24-bit mode' (the SE-30 does have the concept of fake NuBus slots which can be used by board developers who want to port their ROMs with as few changes as possible) so on an SE30 you should get all that virtual address space Paul -- Paul Campbell Taniwha Systems Design UUCP: ..!mtxinu!taniwha!paul Oakland CA AppleLink: D3213 Achtung! Ve are from ze Interface Police! Ve vant to look und feel!
holland@m2.csc.ti.com (Fred Hollander) (05/18/89)
In article <30672@sri-unix.SRI.COM> stores@unix.sri.com (Matt Mora) writes: >WOW! 8megs of real ram must be nice. I am testing the virtual init from >connectix and have 8 megs of VMem. This raises two questions. >1) what is the virtual memory limit of 7.0, is it 8megs also > or is it limited to disk space. 4 Gig (in other words, yes, limited by disk space) > >2) What's going to happen to connectix? Did Apple just obsolete them? Sure seems that way, but, it's not like we didn't know (or beg for) Apple would implement virtual memory. I'm still waiting for word on the lawsuit. Connectix said they have a patent on the only method of virtual memory for the Mac. "As far as I know, there's only one way to do virtual memory on the Mac, and I've filed a patent application on it." -- Jonathan Garber, president, Connectix (MacWeek, 1/31/89) Did anyone else get the feeling that Connectix was just drilling Darin Adler at the Developers' Conference during the Q&A at the OS session. Fred Hollander Computer Science Center Texas Instruments, Inc. hollander@ti.com The above statements are my own and not representative of Texas Instruments.
ra_robert@gsbacd.uchicago.edu (05/19/89)
In article <78153@ti-csl.csc.ti.com>, holland@m2.csc.ti.com (Fred Hollander) writes... [...] >>2) What's going to happen to connectix? Did Apple just obsolete them? > >Sure seems that way, but, it's not like we didn't know (or beg for) >Apple would implement virtual memory. I'm still waiting for word on >the lawsuit. Connectix said they have a patent on the only method of >virtual memory for the Mac. "As far as I know, there's only one way >to do virtual memory on the Mac, and I've filed a patent application >on it." -- Jonathan Garber, president, Connectix (MacWeek, 1/31/89) Just as a side note: I think it's kinda interesting that the people who normally bash Apple for it's profit motivation have left Connectix pretty much alone. I mean, Apple is going to give us VM _for free_ and Connectix is suing to make us pay for it! Hey, I have nothing against Connectix, but personally I'd prefer to get my VM for free, and have the process supported by the company that makes the system software in the first place. [And I personally doubt Connectix' suit will get very far; I reckon Apple's been working on Mac VM for years]. Just my 3 cents worth. Robert ------ ra_robert@gsbacd.uchicago.edu ------ generic disclaimer: all my opinions are mine ------ MOFO knows!
ra_robert@gsbacd.uchicago.edu (05/20/89)
In article <5558@cs.utexas.edu>, jyen@cs.utexas.edu (John Yen) writes... >> In article <78153@ti-csl.csc.ti.com> holland@m2.UUCP (Fred Hollander) writes: >>I'm still waiting for word on >>the lawsuit. Connectix said they have a patent on the only method of >>virtual memory for the Mac. "As far as I know, there's only one way >>to do virtual memory on the Mac, and I've filed a patent application >>on it." -- Jonathan Garber, president, Connectix (MacWeek, 1/31/89) > > Granted that reality doesn't always interface with the law very well, but the >last time I studied all the techniques collectively called virtual memory, I >didn't see just one solution. Does anyone know exactly what Connectix >is filing a patent application on? Sorry about that last note: I tried to cancel my send and it sent it anyway. I'm curious about this too. I'm not patent lawyer, and I think much of the activity regarding software patents is getting really odd, but this would seem to me to be the oddest move of all: an outside party patenting a part of a computer manufacturer's system software? If some other company had filed a patent application on a MultiFinder equivalent before Apple released MF (operative word here is released), Apple couldn't release MF? Ridiculous. Anyway, wouldn't VM on the Mac have to make use of system software (like the Memory Manager)? It seems to me somewhat odd to file a patent which relies on another person's software. And wasn't there some talk on the net awhile ago saying that if a VM scheme used the MMU from Motorola, it wasn't patentable. To paraphrase a slogan I saw once on the net: Connectix, keep your lawyers off our VM! :-> Anyway, just my $0.01 worth. Robert ------ ra_robert@gsbacd.uchicago.edu ------ generic disclaimer: all my opinions are mine ------ MOFO knows!
Greg_Mark_Finnegan@cup.portal.com (05/22/89)
Jonathan Garber's quote ("...there's only one way to do virtual memory...")
bothers me a bit. The Connectix VM scheme limits you to 8Meg period. Apple's
method lets you go to 14Meg by mucking with NuBus (in 24 bit mode) and gobs
more in 32 bit mode.
Sounds like 2 ways to do virtual memory to me (and probably a judge).
Greg.hodas@eniac.seas.upenn.edu (Josh Hodas) (05/23/89)
In article <18660@cup.portal.com> Greg_Mark_Finnegan@cup.portal.com writes: >Jonathan Garber's quote ("...there's only one way to do virtual memory...") >bothers me a bit. The Connectix VM scheme limits you to 8Meg period. Apple's >method lets you go to 14Meg by mucking with NuBus (in 24 bit mode) and gobs >more in 32 bit mode. > >Sounds like 2 ways to do virtual memory to me (and probably a judge). > >Greg. No, No, No, No, No. You are confusing 2 issues. Apples VM scheme allows the full Operating system's Memory range to be handled, as does Virtual's. It's just that at the moment the OS allows only 8 Megs. If apple had VM now it would have the same constraints as Connectix's. It's just that Apple is wait- ing to do VM until thay also support full Memory Range. Connectix said all along that as soon as the OS supports more than 8 Megs they will release a version of virtual that does. Note that this has nothing to do with the merits of Garber's statement (that is my point) and I have little opinion on that matter. I suspect that the key to the truth of that statement lies in what someone recently quoted Garber as saying, that there is only one way "without a full OS rewrite"; which is exact- ly what Apple is doing. Josh ------------------------- Josh Hodas (hodas@eniac.seas.upenn.edu) 4223 Pine Street Philadelphia, PA 19104 (215) 222-7112 (home) (215) 898-5423 (school office)
mha@batcomputer.tn.cornell.edu (Mark H. Anbinder) (05/23/89)
In article <18660@cup.portal.com> Greg_Mark_Finnegan@cup.portal.com writes: >Jonathan Garber's quote ("...there's only one way to do virtual memory...") >bothers me a bit. The Connectix VM scheme limits you to 8Meg period. Apple's >method lets you go to 14Meg by mucking with NuBus (in 24 bit mode) and gobs >more in 32 bit mode. > >Sounds like 2 ways to do virtual memory to me (and probably a judge). I'd have to disagree with you and the judge. :-) In 24-bit mode, Apple is giving users up to 14 megs by allowing their virtual memory program to access the one megabyte of addressable memory that is allotted to each NuBus slot (NOT one meg IN each slot; it's just using the address space), using the space that isn't being used by unused slots. In 32-bit mode, the computer can address gobs more memory, so they let the virtual memory program do so, if you've got the SCSI disk space! (Lucky you, if you do! :-). They may be using EXACTLY the same method of implementing virtual memory as Connectix, the same way of swapping memory pages, whatever, despite the additional space their version will be able to access (I don't know whether the mechanisms each company is using truly are the same). If the VM algorithm itself is substantially the same, THAT is what any putative future court case would consider, NOT whether one or the other implementation has additional features. -- Mark H. Anbinder ** MHA@TCGould.tn.cornell.edu NG33 MVR Hall, Media Services Dept. ** THCY@CRNLVAX5.BITNET Cornell University H: (607) 257-7587 ******** Ithaca, NY 14853 W: (607) 255-1566 ******* "It's not safe out here." Q
amanda@intercon.UUCP (Amanda Walker) (05/23/89)
In article <18660@cup.portal.com>, Greg_Mark_Finnegan@cup.portal.com writes: > Jonathan Garber's quote ("...there's only one way to do virtual memory...") > bothers me a bit. The Connectix VM scheme limits you to 8Meg period. Apple's > method lets you go to 14Meg by mucking with NuBus (in 24 bit mode) and gobs > more in 32 bit mode. > > Sounds like 2 ways to do virtual memory to me (and probably a judge). First of all, the approaches will be similar in many respects simply because they both use the same hardware, i.e., a Motorola PMMU in a Macintosh. That's not what's patentable. From everything I've seen on both of these schemes (which isn't any more than most of the rest of the group :-)), there seem to be some major differences in how they are implemented. I think these differences are simply the result of Connectix being a third-party developer, and Apple being, well, Apple... From the descriptions that have appeared here and in the trade rags, Virtual is a marvelously clever piece of software, but it looks like the authors have attempted to do as little messing about as possible with the lower levels of the system, which means that the pager sits (more or less) between the application and the toolbox. Since they are using the standard SCSI manager, they can't handle page faults during I/O operations. They get around this by preflighting disk accesses in order to insure that all of the buffers are paged in before the operation starts. This does in fact seem to work, although it causes problems for scanners and other devices that talk to the SCSI manager directly instead of via the file manager. I'll call this method "second guessing the applications," and I suspect that this is what the patent application covers. Apple seems to be taking another approach, namely rewriting the SCSI manager to be reentrant, so that page faults can be serviced even when other SCSI operations are pending. This localizes most of the patching to one area, but it's something I think only Apple can do effectively, since they are in control of what the standard system software consists of, and I don't see how it would infringe on Virtual's stuff, since it removes the need for most of the cleverness involved in using the current SCSI manager. Both schemes involve tradeoffs: Virtual involves lots of little patches all over the I/O system, while Apple's VM involves completely replacing one OS manager and leaving the rest of the I/O system more or less alone. Apple's scheme involves a fair amount of cleverness, too, with the idea of remapping the NuBus to make room for more memory in a 24-bit addressed system. Once you see it, it seems obvious, but I still think it was pretty ingenious on the part of whoever thought it up in the first place. -- Amanda Walker <amanda@intercon.UUCP> InterCon Systems Corporation
jpd00964@uxa.cso.uiuc.edu (08/15/89)
If I had only a Mac plus, what does system 7.0 do for me? Michael Rutman
wb1j+@andrew.cmu.edu (William M. Bumgarner) (08/16/89)
lots... Outline Fonts InterProcess Comunications AppleEvents NewFinder b.bum wb1j+@andrew.cmu.edu
kent@sunfs3.camex.uucp (Kent Borg) (08/16/89)
In article <227700026@uxa.cso.uiuc.edu> jpd00964@uxa.cso.uiuc.edu writes: > >If I had only a Mac plus, what does system 7.0 do for me? The only new feature that a Plus won't get is the virtual memory. The rest will be there. Realize that you still will not have Color QuickDraw, a big screen, etc. Kent Borg kent@lloyd.uucp or ...!husc6!lloyd!kent
markham@phi.cs.unc.edu (Andrew Markham) (08/17/89)
In article <483@sunfs3.camex.uucp>, kent@sunfs3.camex.uucp (Kent Borg) writes: > In article <227700026@uxa.cso.uiuc.edu> jpd00964@uxa.cso.uiuc.edu writes: > > > >If I had only a Mac plus, what does system 7.0 do for me? > > The only new feature that a Plus won't get is the virtual memory. The > rest will be there. Realize that you still will not have Color > QuickDraw, a big screen, etc. > > Kent Borg > kent@lloyd.uucp > or > ...!husc6!lloyd!kent Well; close, but no cigar. Unless your Mac plus has 2MB of main memory, you won't even be able to run 7.0. 7.0 will include the following: Virtual Memory and 32-bit Addressing (this you will not have because you only have a 68000 cpu that is unable to support a PMMU) InterApplication Communication Architecture - IAC Outline Fonts Layout Manager New Print Architecture Database Access New Finder(symbolic lincs, modifiable Views, a more intuitive "Find File" located as a menu option (I believe), configurable apple menu,etc) I think Apple really duped a lot of people when they laid down the 2MB memory requirement. This should work on 1M machines since I am sure that > 50% of the machines out there have 1M (although I have a 2.5 MB SE). Andrew W. Markham <markham@sunmail.cs.unc.edu> Computer Science Department UNC-CH "Nobody in the world can cover my main man Michael Jordan. No, No, Nooobody." -Mars Blackmon
pwp@shamash.cdc.com ( HOUFAC) (08/18/89)
In article <9173@thorin.cs.unc.edu> markham@phi.cs.unc.edu (Andrew Markham) writes: >Well; close, but no cigar. Unless your Mac plus has 2MB of main memory, >you won't even be able to run 7.0. > >7.0 will include the following: . . . . . . . . . > New Finder(symbolic lincs, modifiable Views, a more intuitive "Find > File" located as a menu option (I believe), configurable > apple menu,etc) Surely Symbolic Links are a feature of the file system, not the finder! I've seen several attempts for a user interface to maintain an image of the file system that doesn't match the underlying structure. It never works very well. (One example, the Finder before HFS.) --Pete Poorman Control Data Corporation pwp@shamash.cdc.com
kent@sunfs3.camex.uucp (Kent Borg) (08/21/89)
In article <13784@shamash.cdc.com> pwp@shamash.UUCP (Pete Poorman) writes: >In article <9173@thorin.cs.unc.edu> markham@phi.cs.unc.edu (Andrew Markham) writes: >> New Finder(symbolic lincs, modifiable Views, a more intuitive "Find >> File" located as a menu option (I believe), configurable >> apple menu,etc) > >Surely Symbolic Links are a feature of the file system, not the finder! > >I've seen several attempts for a user interface to maintain an image of >the file system that doesn't match the underlying structure. It never works >very well. (One example, the Finder before HFS.) > >--Pete Poorman > Control Data Corporation > pwp@shamash.cdc.com Nope. `Aliases', as they are calling them, are implemented as a little file which has the volume name and file id (itself a new 7.0 feature) of the actual file. It is the Finder (which will always be there starting with 7.0) and the standard file dialogs which implement the symbolic link. This means that programs which don't use the standard file dialogs will not know about the aliases. (MPW is the program programmers think of first.) With MFS folders the problems were not that the file system didn't know about them, the problem was that no one knew about them except the Finder, and the lack of real folders made the file system slow. Aliases shouldn't have these problems. They will probably have their own set. Related note: Apple said at the devl. conf. that standard file dialogs will eventually go away. Not with 7.0, but some point later. Kent Borg kent@lloyd.uucp or ...!husc6!lloyd!kent
tim@hoptoad.uucp (Tim Maroney) (08/23/89)
In article <490@sunfs3.camex.uucp> kent@sunfs3.UUCP (Kent Borg) writes: >Nope. `Aliases', as they are calling them, are implemented as a >little file which has the volume name and file id (itself a new 7.0 >feature) of the actual file. > >It is the Finder (which will always be there starting with 7.0) and >the standard file dialogs which implement the symbolic link. This >means that programs which don't use the standard file dialogs will not >know about the aliases. (MPW is the program programmers think of >first.) Actually, any program ought to be able to use them if it wants. But I wonder why the trivial changes to the file system weren't done that would allow transparent access to symbolic links. None of the disk data structures have to change; the PBOpen, PBOpenRF, PBHOpen, and PBHOpenRF routines (not to mention PBHGetFInfo etc.) just need to be patched to recognize links. If a third part could do it with an INIT, I wonder why Apple didn't. Of course, features haven't been frozen yet, so all claims about how links will work in the released version should be taken with a grain of salt. >Related note: Apple said at the devl. conf. that standard file dialogs >will eventually go away. Not with 7.0, but some point later. This is the first I've heard of it, though I'll grant you I didn't shell out the bucks for the conference. That would be a pretty major incompatibility, but it does make sense. Right now, there are two views of the file system, a modal name-list view (standard file) and a modeless variable view (Finder). No doubt Apple decided it would be best to unify these. But it's going to break practically every serious program that's been released. You *have* to hack standard file to some extent for a distribution program. On a semi-related note, what is this file id crap? How are network file system implementors supposed to implement yet another Mac-file-system-only feature on servers on other operating systems? Is Apple expecting all the other operating systems to just give up eventually and implement Mac file systems, throwing away their own? This seems like a bloody stupid decision and a feature of very limited utility. We've all had enough problems with directory ids, now this. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "The above opinions and suggestions have absolutely nothing to do with the little, fat man putting crisp, $100 bills in my pocket." -- Alan Vymetalik
unocc07@zeus.unl.edu (Dave Caplinger) (08/24/89)
In article <8368@hoptoad.uucp>, tim@hoptoad.uucp (Tim Maroney) writes: > > On a semi-related note, what is this file id crap? How are network > file system implementors supposed to implement yet another > Mac-file-system-only feature on servers on other operating systems? > Is Apple expecting all the other operating systems to just give up > eventually and implement Mac file systems, throwing away their own? > This seems like a bloody stupid decision and a feature of very limited > utility. We've all had enough problems with directory ids, now this. > -- > Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com Isn't the file-id information just taken straight out of AppleShare? (the new format for the Desktop file(s)) If so, it's not really "yet another" different thing in the Mac file system. (That, and the "file-id" that AppleShare uses is limited to 8 characters and an 3 character extension (with some character replacing to make the filenames unique) specificaly for MS-DOS compatibility. (At least, I hope that this is what they mean by file-id's!) -/ Dave Caplinger /------------------+----------------------------------- Microcomputer Specialist | Internet: unocc07@zeus.unl.edu "Computing and Data Communications" | UUCP: uunet!btni!unocss!dent University of Nebraska at Omaha | Bitnet: UNOCC07@UNOMA1 Omaha, NE 68182 | or dc3a+@andrew.cmu.edu
amanda@intercon.uu.net (Amanda Walker) (08/24/89)
In article <3214@zeus.unl.edu>, unocc07@zeus.unl.edu (Dave Caplinger) writes: > In article <8368@hoptoad.uucp>, tim@hoptoad.uucp (Tim Maroney) writes: > > On a semi-related note, what is this file id crap? How are network > > file system implementors supposed to implement yet another > > Mac-file-system-only feature on servers on other operating systems? > > Isn't the file-id information just taken straight out of AppleShare? > (the new format for the Desktop file(s)) If so, it's not really "yet > another" different thing in the Mac file system. AppleShare & the new desktop interface don't use file IDs; it's something new, and something which I think can only encourage bad programming... As for Tim's note, I'm afraid the people working on the Mac file system simply don't care. It fits into Apple's general attitude towards other machines doing things that "could be done with Macs": "Why would you want to do that?" They even take this stand towards some of their own products, annoyingly enough :-(. Grumble. -- Amanda Walker InterCon Systems Corporation amanda@intercon.uu.net | ...!uunet!intercon!amanda
tim@hoptoad.uucp (Tim Maroney) (08/24/89)
In article <8368@hoptoad.uucp>, tim@hoptoad.uucp (Tim Maroney) writes: > On a semi-related note, what is this file id crap? How are network > file system implementors supposed to implement yet another > Mac-file-system-only feature on servers on other operating systems? In article <3214@zeus.unl.edu>, unocc07@zeus.unl.edu (Dave Caplinger) writes: > Isn't the file-id information just taken straight out of AppleShare? > (the new format for the Desktop file(s)) If so, it's not really "yet > another" different thing in the Mac file system. In article <1394@intercon.UUCP> amanda@intercon.uu.net (Amanda Walker) writes: >AppleShare & the new desktop interface don't use file IDs; it's something >new, and something which I think can only encourage bad programming... I didn't want to hear this -- I saw your message and thought, "Oh boy, Amanda will have the answer, it's not as bad as I think." I guess it really is. You seem to be reasonably well connected, and if you don't know of any Apple answer to the network file system issue here, I'm willing to bet that they haven't even bothered to think about it. David Oster had a good point about the programming implications. You now must save your documents by overwriting the old file. Never mind that most people either delete the old file before creating a new one, or write the new one while the old one is still around for an extra layer of failureproofing. Never mind that overwriting the old file preserves fragmentation even when the disk is capable of laying out the file in a smarter fashion. This is a very questionable new feature in terms of what it delivers (users can rename preferences files for new applications that use the feature) versus the overhead it imposes on programmers. Network programmers are the worst off, but everyone winds up paying one way or another. (And for anyone who may think that file ids are required for the new symbolic link feature, which *is* useful -- think again. All you need to store is what UNIX stores, the full path name.) >As for Tim's note, I'm afraid the people working on the Mac file system >simply don't care. It fits into Apple's general attitude towards other >machines doing things that "could be done with Macs": "Why would you want >to do that?" They even take this stand towards some of their own products, >annoyingly enough :-(. They've gone beyond "not invented here" to "not purchased here", I guess. Is there any sort of "internal RFC" mechanism at Apple so that the different OS teams can avoid stepping on each other's toes? Or do they already have a solution for Appleshare and they're just hoping that no one else can solve it in time? The word (unconfirmed, but from sources with no concrete interests either way) is that TOPS outsells Appleshare by a factor of five or more, so I wouldn't be surprised if they played a little dirty pool to try to close the gap. >Grumble. Welcome to the club.... -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "Something was badly amiss with the spiritual life of the planet, thought Gibreel Farishta. Too many demons inside people claiming to believe in God." -- Salman Rushdie, THE SATANIC VERSES
amanda@intercon.uu.net (Amanda Walker) (08/24/89)
In article <8381@hoptoad.uucp>, tim@hoptoad.uucp (Tim Maroney) writes: > I didn't want to hear this -- I saw your message and thought, "Oh boy, > Amanda will have the answer, it's not as bad as I think." Well, I'm flattered; sorry I can't be more positive... > I guess it > really is. You seem to be reasonably well connected, and if you don't > know of any Apple answer to the network file system issue here, I'm > willing to bet that they haven't even bothered to think about it. Well, I haven't spoken to any file system people recently, so I can't be completely certain, but that's how it looks. One thing, though, is that file IDs are *not* mandatory. For one thing, they don't work on MFS volumes. > David Oster had a good point about the programming implications. You > now must save your documents by overwriting the old file. Actually, this isn't true. Apple wasn't entirely asleep when they came up with this idea :-). There's a routine called "PBHExchangeFiles" that exchanges the contents of two files (sort of like a mutual rename that keeps the file ID attached to the name, not the file contents). Grody, but at least it's there (at least, as of the Dev. Conf. :-)). Sigh. This is part of my love-hate relationship with Apple. They do great stuff, but they are off in their own world, and they are very convinced that "being Apple" is all they need to do. There's only so long you can say "I am The Great And Powerful Oz", though, before people start wondering what's behind the curtain. The more Macs they sell, and the bigger they get, the more they will have to coexist with the rest of the world. I hope they figure this out at some point ... -- Amanda Walker InterCon Systems Corporation amanda@intercon.uu.net | ...!uunet!intercon!amanda
amanda@intercon.uu.net (Amanda Walker) (08/24/89)
In article <8381@hoptoad.uucp>, tim@hoptoad.uucp (Tim Maroney) writes: > I didn't want to hear this -- I saw your message and thought, "Oh boy, > Amanda will have the answer, it's not as bad as I think." Well, I'm flattered; sorry I can't be more positive... > I guess it > really is. You seem to be reasonably well connected, and if you don't > know of any Apple answer to the network file system issue here, I'm > willing to bet that they haven't even bothered to think about it. Well, I haven't spoken to any file system people recently, so I can't be completely certain, but that's how it looks. One thing, though, is that file IDs are *not* mandatory. For one thing, they don't work on MFS volumes. > David Oster had a good point about the programming implications. You > now must save your documents by overwriting the old file. Actually, this isn't true. Apple wasn't entirely asleep when they came up with this idea :-). There's a routine called "PBHExchangeFiles" that exchanges the contents of two files (sort of like a mutual rename that keeps the file ID attached to the name, not the file contents). Grody, but at least it's there (at least, as of the Dev. Conf. :-)). Sigh. This is part of my love-hate relationship with Apple. They do great stuff, but they are off in their own world, and they are very convinced that "being Apple" is all they need to do. There's only so long you can say "I am The Great And Powerful Oz", though, before people start wondering what's behind the curtain. The more Macs they sell, and the bigger they get, the more they will have to coexist with the rest of the world. I hope they figure this out at some point ... Ah, well. At least the External File System interface will be cleaned up a whole lot. -- Amanda Walker InterCon Systems Corporation amanda@intercon.uu.net | ...!uunet!intercon!amanda
hiebert@mdivax1.uucp (Graeme Hiebert) (08/25/89)
In article <8381@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: > ... > [a bunch of stuff deleted, most of which is truly valid, such as the > complaining about having to overwrite files] > ... > (And for anyone who may think that file ids are required for the new > symbolic link feature, which *is* useful -- think again. All you need > to store is what UNIX stores, the full path name.) > (By the way, for what little difference it makes, UNIX stores the relative path name.) An advantage of file id's that I can see is that you can move a file to a different folder and still have no trouble finding it. For example, the "Set Paths" DA always knows where to look for the paths you specify, even if you rename them or move them. This saves a fair amount of work when you reorganize your hard drive as much as I do. Instead of having to overwrite a file, there should be a way to say to the OS, "OK, I want to change this file but keep a backup, so change this file's ID and open a new file for me with its current ID." I don't know what the ramifications of this are, but it would both solve the "write over" problem and allow symbolic links which aren't subject to renaming/moving problems. I can, however, see your point about incompatibility across file systems. > ... > -- > Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com > > "Something was badly amiss with the spiritual life of the planet, thought > Gibreel Farishta. Too many demons inside people claiming to believe in > God." -- Salman Rushdie, THE SATANIC VERSES -g P.S. Tomorrow is my last day of both this job and usenet access, so I leave this as my last (sob :-( ) posting to the net. I can say, these discussions will be sadly missed. -- Graeme E. Hiebert | So many of us seek pleasures to acquire hiebert@mdivax1.uucp | happiness, yet so few of us are happy ...!ubc-cs!van-bc!mdivax1!hiebert | with the pleasures we find. ---------------------------------------------------------------------------
chewy@apple.com (Paul Snively) (08/25/89)
In article <1394@intercon.UUCP> amanda@intercon.uu.net (Amanda Walker) writes: > AppleShare & the new desktop interface don't use file IDs; it's something > new, and something which I think can only encourage bad programming... > > As for Tim's note, I'm afraid the people working on the Mac file system > simply don't care. It fits into Apple's general attitude towards other > machines doing things that "could be done with Macs": "Why would you want > to do that?" They even take this stand towards some of their own products, > annoyingly enough :-(. > > Grumble. I really must take exception to this, because it simply isn't true at all. The rationale around providing fileIDs is actually to correct a glaring deficiency in all existing Macintosh file systems, namely that the only way to uniquely identify a file right now is--guess how?--the file name! And guess what? The user can change file names anytime s/he wants to! So if your program keeps track of where a file is the "right way" (Volume name/dirID/file name), you're screwed if the user changes the name of the volume or the name of the file, and you have to "locate" the "lost" file, even though the thing may not have moved so much as a pixel in its Finder window. [sigh]. As for implementation on other platforms, actually, we're quite pleased when someone implements an AFP server on another platform, such as CAP or the Gator Box from Caymen systems (even if it is slow; YOU try doing NFS/AFP protocol translations on the fly sometime). ___________________________________________________________________________ chewy@apple.com Just because I work for Apple Computer, Inc. doesn't mean that they believe what I believe or vice-versa. ___________________________________________________________________________
amanda@intercon.uu.net (Amanda Walker) (08/25/89)
In article <3908@internal.Apple.COM>, chewy@apple.com (Paul Snively) writes: > The rationale around providing fileIDs is actually to correct a glaring > deficiency in all existing Macintosh file systems, namely that the only > way to uniquely identify a file right now is--guess how?--the file name! Which is how the rest of the world does it, by and large... So? > And guess what? The user can change file names anytime s/he wants to! So > if your program keeps track of where a file is the "right way" (Volume > name/dirID/file name), you're screwed if the user changes the name of the > volume or the name of the file, and you have to "locate" the "lost" file, > even though the thing may not have moved so much as a pixel in its Finder > window. [sigh]. So we attach magic cookies so that it's the file's *history* that counts, not it's name or location? Bad magic, kemosabe. I doubt I'm the only one who temporarily renames files (usually settings files, which are prime candidates for File IDs) to "move them out of the way" for a bit. With File IDs, I'll have to duplicate the file and throw out the old copy, and then ... what happens when I want to put it back [:-)/2]? > As for implementation on other platforms, actually, we're quite pleased > when someone implements an AFP server on another platform, such as CAP or > the Gator Box from Caymen systems (even if it is slow; YOU try doing > NFS/AFP protocol translations on the fly sometime). Well, they don't exactly... Technically, they have written an AFP server that uses NFS as its native file system. A nifty feat, all in all, mainly because of the bizarreness of the Macintosh file system. One of the big wins of the new desktop calls under AFP was that you could actually implement AFP on a foreign platform without having to actually store away Directory IDs for the Finder. With File IDs, we'll have to go back to maintaining a parallel directory structure again. Bleah :-P I can see implementing something like File IDs to make things like the Publication stuff and live copy & paste easier in the presence of files being renamed. But in my opinion, making it yet another basic file system feature is silly. It was probably relatively easy to add to HFS, which uses B*-trees as directories, but I find it hard to believe that you worried at all about how difficult it would be to implement on non-Macs. I'm not sure this is exactly a bad thing--I mean, designing Mac software is Apple's job, and designing other stuff is ours, but still, it's aggravating. -- Amanda Walker InterCon Systems Corporation amanda@intercon.uu.net | ...!uunet!intercon!amanda
ralph@computing-maths.cardiff.ac.uk (Ralph Martin) (08/25/89)
Just my tuppence worth for thisa debate about file ID's: its always a bad idea to have two names for the same thing, cause they can get out of step. Just look at all the trouble having Font names and Font ID's has caused. And now it seems like Apple is going to make the same mistake all over again, this time with Files. I'm sure its to late to get them to change their minds on this one, so I will have to content myself with saying "Told You So" later! Ralph
tim@hoptoad.uucp (Tim Maroney) (08/26/89)
In article <1394@intercon.UUCP> amanda@intercon.uu.net (Amanda Walker) writes: > AppleShare & the new desktop interface don't use file IDs; it's something > new, and something which I think can only encourage bad programming... > > As for Tim's note, I'm afraid the people working on the Mac file system > simply don't care. It fits into Apple's general attitude towards other > machines doing things that "could be done with Macs": "Why would you want > to do that?" They even take this stand towards some of their own products, > annoyingly enough :-(. > > Grumble. In article <3908@internal.Apple.COM> chewy@apple.com (Paul Snively) writes: >I really must take exception to this, because it simply isn't true at all. > The rationale around providing fileIDs is actually to correct a glaring >deficiency in all existing Macintosh file systems, namely that the only >way to uniquely identify a file right now is--guess how?--the file name! >And guess what? The user can change file names anytime s/he wants to! WOW!!! What a hole! You actually identify files by NAME instead of by some invisible token that the user can't get to? Someone call the cops! Did you ever notice that this is also true on every other operating system? What makes this a deficiency? Doesn't it *raise* the level of user insecurity to increase the black box nature of simple operations? Anyone can understand "there's a file named 'Wanderer Preferences' in your system folder"; how many users can understand "There's a file which the program originally created called 'Wanderer Preferences' but which you may have renamed to anything or dragged anywhere but which the system is always keeping track of anyway"? And what does *anyone* gain from the latter case? Whose bright idea was this, anyway? Let's all do our bits to try to ward off the collapse of the Mac OS from terminal "neat-idea-ism". >So if your program keeps track of where a file is the "right way" (Volume >name/dirID/file name), you're screwed if the user changes the name of the >volume or the name of the file, and you have to "locate" the "lost" file, >even though the thing may not have moved so much as a pixel in its Finder >window. [sigh]. Gosharootie. I hardly know where to start on this. First of all, who said that was the right way? Again, network file systems are not being taken into account. The AFP documentation says that you should not rely on directory ids lasting longer than a session. If you remember it this way now, then you're screwed on any temporary-directory-id AFP server. This is not the right way to do things. Generally, the right way to find a file is to remember only one thing, the file name. Then look for it in the system folder of the boot volume. If you *must* remember a file somewhere else, then save a full path name as a resource. Then there's the volume renaming issue you've brought up. It has no effect in the most common case of needing to get at a file, the preferences file in the system folder. I don't understand how it is overcome in other cases by the file id mechanism, since from what I've seen you need a volume name/file id pair to get at a file. Perhaps I am mistaken on this point, in which case I hope someone will correct me. Finally, what if you have to remember a file on a network file system? The full path name will do it, provided the user always mounts the remote volume from the same point (which is generally the case). Well, too bad if you want to do it with file ids; they're optional and probably won't be implemented by many servers, since other operating systems don't have an analogue. (Sure, there's inode numbers, but they're not guaranteed to stay invariant given an operation like an emacs save file.) So you will have to have a menagerie of special cases in your code. Under 6.0 and earlier, save the full path name. Under 7.0, save the full path name for network volumes, but the file id otherwise. What a mess. >As for implementation on other platforms, actually, we're quite pleased >when someone implements an AFP server on another platform, such as CAP or >the Gator Box from Caymen systems (even if it is slow; YOU try doing >NFS/AFP protocol translations on the fly sometime). Thanks, but I just ate.... So why do you add worthless features like directory ids and file ids that are a major pain in the ass for implementors of network servers on other platforms, if you love them so much? And, by the way, are you saying that you're only happy when someone implements an AFP server, not a server using some other protocol? And what about AFP clients? ("You mean you're actually *using* a non-Macintosh?") Pretty parochial. When System 7.0 comes out, I will ignore the file id mechanism, and I suspect many others will do the same; and of course, no existing programs use it. So not only do we have a questionable feature that's used onlu by some programs, but the user has no way of knowing whether a given piece of software will or will not allow renaming. It's a mess for programmers; it's a mess especially for network programmers; it's a mess for users; it's especially a mess for network users. Ditch it now while you still have the chance. One last note. It occurs to me that some readers may think I just haven't worked on any software that would "benefit" from this feature. One of my current projects is a FAX modem with an envelope interface, where graphics files are stored in the envelopes. They are currently stored by full path name. If the user renames them, the user has shot itself in the foot. Also, if the user throws them in the trash, there's a hole in that foot, and if the user opens the documents in a graphics document editor before they can be sent by the background scheduler, so they're already open when the scheduler tries to send them, then you're looking at powder burns, flesh wounds, a permanent limp, etc. You can only protect a user so far before your protection becomes an unwanted burden, and you can never be completely successful anyway. Most of us are aware of this in mundane life, but Apple seems determined to impose this frankly fascist protection-from-yourself-at- any-cost wherever it can. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "The pride of the peacock is the glory of God. The lust of the goat is the bounty of God. The wrath of the lion is the wisdom of God. The nakedness of woman is the work of God." - Blake, "The Marriage of Heaven and Hell"
chewy@apple.com (Paul Snively) (08/26/89)
In article <8389@hoptoad.uucp> tim@hoptoad.uucp (Tim Maroney) writes: > WOW!!! What a hole! You actually identify files by NAME instead of by > some invisible token that the user can't get to? Someone call the > cops! > > Did you ever notice that this is also true on every other operating > system? What makes this a deficiency? You quoted my answer later in your post. In article <8389@hoptoad.uucp> tim@hoptoad.uucp (Tim Maroney) writes: > >So if your program keeps track of where a file is the "right way" (Volume > >name/dirID/file name), you're screwed if the user changes the name of the > >volume or the name of the file, and you have to "locate" the "lost" file, > >even though the thing may not have moved so much as a pixel in its Finder > >window. [sigh]. > > Gosharootie. I hardly know where to start on this. First of all, who > said that was the right way? Apple did, of course, because it is. Full pathnames are most definitely the WRONG way; volumes aren't unique by name, for starters, as they are on UNIX and many other OSes. Obviously directory names aren't unique. Neither are filenames. With a full pathname, there's no way in hell you can guarantee uniqueness. As for remembering dirIDs across fileserver sessions, in actual practice I don't believe that an AFP server (at least) will change them. In article <8389@hoptoad.uucp> tim@hoptoad.uucp (Tim Maroney) writes: > Then there's the volume renaming issue you've brought up. It has no > effect in the most common case of needing to get at a file, the > preferences file in the system folder. I don't understand how it is > overcome in other cases by the file id mechanism, since from what I've > seen you need a volume name/file id pair to get at a file. Perhaps I > am mistaken on this point, in which case I hope someone will correct me. Good point--if the only unique way to identify a volume is still by name, then we have accomplished nothing. In article <8389@hoptoad.uucp> tim@hoptoad.uucp (Tim Maroney) writes: > Finally, what if you have to remember a file on a network file system? > The full path name will do it, provided the user always mounts the > remote volume from the same point (which is generally the case). Well, > too bad if you want to do it with file ids; they're optional and > probably won't be implemented by many servers, since other operating > systems don't have an analogue. (Sure, there's inode numbers, but > they're not guaranteed to stay invariant given an operation like an > emacs save file.) So you will have to have a menagerie of special > cases in your code. Under 6.0 and earlier, save the full path name. > Under 7.0, save the full path name for network volumes, but the file id > otherwise. What a mess. The server may simpy layer fileIDs on top of the real file management, associating a unique ID with every new file that's made, and providing that ID when the appropriate call is made. That's assuming that nothing will be done to circumvent this associative process in a way that is intrusive to file service, which may or may not be the case; it depends upon how dedicated your server is. In article <8389@hoptoad.uucp> tim@hoptoad.uucp (Tim Maroney) writes: > Thanks, but I just ate.... So why do you add worthless features like > directory ids and file ids that are a major pain in the ass for > implementors of network servers on other platforms, if you love them so > much? > > And, by the way, are you saying that you're only happy when someone > implements an AFP server, not a server using some other protocol? > And what about AFP clients? ("You mean you're actually *using* a > non-Macintosh?") Pretty parochial. fildIDs aren't that tough to implement on other systems; it's just that the system might not hand them to you on a silver platter. As for AFP vs. anything else, well, we really want consistent file service, and we've already done the Macintosh AFP client software. I like NFS, too, which is why the existence of the Gator Box is a good thing; the Macintosh user still uses their AppleShare Workstation software that they're accumstomed to, and they see a pretty normal-looking "Macintosh" volume on their desktop, which is as it should be. And that's why we don't encourage writing AFP clients; we already did, and any developer can license it to ship with their product, as Caymen does. In article <8389@hoptoad.uucp> tim@hoptoad.uucp (Tim Maroney) writes: > One last note. It occurs to me that some readers may think I just > haven't worked on any software that would "benefit" from this feature. > One of my current projects is a FAX modem with an envelope interface, > where graphics files are stored in the envelopes. They are currently > stored by full path name. If the user renames them, the user has shot > itself in the foot. Also, if the user throws them in the trash, > there's a hole in that foot, and if the user opens the documents in a > graphics document editor before they can be sent by the background > scheduler, so they're already open when the scheduler tries to send > them, then you're looking at powder burns, flesh wounds, a permanent > limp, etc. You can only protect a user so far before your protection > becomes an unwanted burden, and you can never be completely successful > anyway. Most of us are aware of this in mundane life, but Apple seems > determined to impose this frankly fascist protection-from-yourself-at- > any-cost wherever it can. Thank you for your complete and cogent explanation of precisely why NOT to use full pathnames, etc. We really are trying to look out for the average user, and if here-and-now that means a little more black magic on the part of the developer, well, that's here-and-now. We really do want the Mac to be easy to program, too, but let's face it: it's gonna take a total redesign of our OS to allow that, and I'm just a DTS grunt; I'm not in a position to say if/when we'd ever do such a thing. ___________________________________________________________________________ chewy@apple.com Just because I work for Apple Computer, Inc. doesn't mean that they believe what I believe or vice-versa. ___________________________________________________________________________
tim@hoptoad.uucp (Tim Maroney) (08/27/89)
In article <8381@hoptoad.uucp>, tim@hoptoad.uucp (Tim Maroney) writes: > I guess it > really is. You seem to be reasonably well connected, and if you don't > know of any Apple answer to the network file system issue here, I'm > willing to bet that they haven't even bothered to think about it. In article <1399@intercon.UUCP> amanda@intercon.uu.net (Amanda Walker) writes: >Well, I haven't spoken to any file system people recently, so I can't be >completely certain, but that's how it looks. One thing, though, is that >file IDs are *not* mandatory. For one thing, they don't work on MFS >volumes. Since "aliases" (symbolic links) use them, that will likely mean that you won't be able to make links to applications on server volumes. That means they can't show up in the Apple menu and so they are second-class citizens.... >> David Oster had a good point about the programming implications. You >> now must save your documents by overwriting the old file. > >Actually, this isn't true. Apple wasn't entirely asleep when they came >up with this idea :-). There's a routine called "PBHExchangeFiles" that >exchanges the contents of two files (sort of like a mutual rename that >keeps the file ID attached to the name, not the file contents). Grody, >but at least it's there (at least, as of the Dev. Conf. :-)). Oh boy, more version-specific conditionals. I love those. What's wrong with "if (((environs.systemVersion & 0xff00) >> 8) < 7)" all over your code? (You don't have to answer....) So under 7.0 and up, you save to a new file, then do the exchange files, then finally do a PBDelete on the original file? I suppose it could be worse. >Sigh. This is part of my love-hate relationship with Apple. They do great >stuff, but they are off in their own world, and they are very convinced that >"being Apple" is all they need to do. There's only so long you can say >"I am The Great And Powerful Oz", though, before people start wondering >what's behind the curtain. The more Macs they sell, and the bigger they >get, the more they will have to coexist with the rest of the world. I hope >they figure this out at some point ... Don't hold your breath.... >Ah, well. At least the External File System interface will be cleaned >up a whole lot. So I've heard. That does sound like a good thing; know of any available documentation on it? The old interface still required you to do a ton of trap patches, and trap patches on the file system are *not* as easy as patches elsewhere by any means. (The reasons why are left as an exercise for the reader.) I wonder if you'll be able to write a network file system with no trap patches under System 7.0. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "Gangsters would kidnap my math teacher, Miss Albertine, and I'd track them down and kill them one by one until she was free, and then she'd break off her engagement with my sarcastic English teacher, Mr. Richardson, because she'd fallen hopelessly in love with her grim-faced and silent fourteen-year-old savior." -- Nite Owl, in WATCHMEN by Alan Moore
amanda@intercon.uu.net (Amanda Walker) (08/29/89)
In article <3943@internal.Apple.COM>, chewy@apple.com (Paul Snively) writes: > With a full pathname, there's no way in hell you > can guarantee uniqueness. Well, two points (and then I'll stop for now :-)): 1. No scheme will be perfect in all circumstances. Life's just like that. In fact, I'll posit a strong version of this: Given any scheme for identifying files, there will always be at least one very useful operation that will be difficult or impossible. 2. My biggest problem with the file ID scheme is that it introduces a dichotomy between what the user uses to identify files and what software uses. While this may make some things easier (like aliases and live copy & paste), it is bound to introduce confusion somewhere else. I think this is a bad thing. I don't think it's The End Of The Macintosh As We Know It :-), but I still think it's a bad thing. > As for remembering dirIDs across fileserver sessions, in actual practice I > don't believe that an AFP server (at least) will change them. Depends. If the underlying file system has something like DirIDs, such as a Macintosh-based AppleShare server, this is true. If it's something else, it may not. And even on a Macintosh, DirIDs are not constant over backups and restores, which means any software that wants to use DirIDs had <expletive deleted> well better be able to handle them changing anyway... -- Amanda Walker InterCon Systems Corporation amanda@intercon.uu.net | ...!uunet!intercon!amanda
chewy@apple.com (Paul Snively) (08/29/89)
In article <1413@intercon.UUCP> amanda@intercon.uu.net (Amanda Walker) writes: > 1. No scheme will be perfect in all circumstances. Life's just like that. > In fact, I'll posit a strong version of this: Given any scheme for > identifying files, there will always be at least one very useful operation > that will be difficult or impossible. This strikes me as a truism. I didn't mean to imply that the new 7.0 file system will be the be-all and end-all file system; I just think it's, _in general_, better than what we have now. In article <1413@intercon.UUCP> amanda@intercon.uu.net (Amanda Walker) writes: > 2. My biggest problem with the file ID scheme is that it introduces a > dichotomy between what the user uses to identify files and what software > uses. While this may make some things easier (like aliases and live > copy & paste), it is bound to introduce confusion somewhere else. I > think this is a bad thing. I don't think it's The End Of The Macintosh > As We Know It :-), but I still think it's a bad thing. Of course this is a potential problem; I believe that in practice what will happen is that people will find that they can do things like rename files and move them around (maybe) without software that relies on their existence asking so many questions (like "where's that file?"). On the other hand, it probably does mean that gone are the days when you could kill off that defaults file by sticking an "x" in front of its name or what have you. And you could still write a non-AppleShare AFP server that provided consistent dirIDs; you're really just maintaining that associative list of IDs with respect to directory names that I mentioned. There's no reason whatsoever for those to change from session to session. Picture a hashtable of directory or pathnames associated with their dirIDs that is stored somewhere on the volume and read every time the server comes up. You're right; if you rely on dirIDs, you'd better be prepared for what happens after a backup and restore. The point is that those are infrequent operations by way of comparison with the user renaming a file and/or directory, so dirIDs are still the preferred way to go. ___________________________________________________________________________ chewy@apple.com Just because I work for Apple Computer, Inc. doesn't mean that they believe what I believe or vice-versa. ___________________________________________________________________________
ge@kunivv1.sci.kun.nl (Ge' Weijers) (08/30/89)
In article <1402@intercon.UUCP> amanda@intercon.uu.net (Amanda Walker) writes: >..................... One of the big wins of >the new desktop calls under AFP was that you could actually implement AFP >on a foreign platform without having to actually store away Directory IDs >for the Finder. With File IDs, we'll have to go back to maintaining a >parallel directory structure again. Bleah :-P I wonder why it is more difficult to implement file IDs than directory IDs. I suppose the problem is similar, especially in systems where directories are implemented as files (NFS/UNIX) Ge' Weijers Ge' Weijers Internet/UUCP: ge@cs.kun.nl Faculty of Mathematics and Computer Science, (uunet.uu.net!cs.kun.nl!ge) University of Nijmegen, Toernooiveld 1 6525 ED Nijmegen, the Netherlands tel. +3180612483 (UTC-2)
ge@kunivv1.sci.kun.nl (Ge' Weijers) (08/30/89)
In article <1989Aug24.221123.4188@mdivax1.uucp> hiebert@mdivax1.uucp (Graeme Hiebert) writes: >In article <8381@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >> ... >> (And for anyone who may think that file ids are required for the new >> symbolic link feature, which *is* useful -- think again. All you need >> to store is what UNIX stores, the full path name.) >> > >(By the way, for what little difference it makes, UNIX stores the relative >path name.) BSD Unix stores whatever you want as a 'symbolic link', which is just a text. It can be an absolute or relative path, or your mother's bank account number. Just being pedantic. Ge' Weijers. Ge' Weijers Internet/UUCP: ge@cs.kun.nl Faculty of Mathematics and Computer Science, (uunet.uu.net!cs.kun.nl!ge) University of Nijmegen, Toernooiveld 1 6525 ED Nijmegen, the Netherlands tel. +3180612483 (UTC-2) Ge' Weijers Internet/UUCP: ge@cs.kun.nl Faculty of Mathematics and Computer Science, (uunet.uu.net!cs.kun.nl!ge) University of Nijmegen, Toernooiveld 1 6525 ED Nijmegen, the Netherlands tel. +3180612483 (UTC-2)
rang@frith.egr.msu.edu (Anton Rang) (08/31/89)
In article <8381@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: [ Stuff about file ID information deleted ] >David Oster had a good point about the programming implications. You >now must save your documents by overwriting the old file. Never mind >that most people either delete the old file before creating a new one, If you do this, please remember to save the file comment ID (and the other Finder information). This is one of my pet peeves about a few of the public-domain programs I have (most of the [few] commercial ones seem to work OK). >or write the new one while the old one is still around for an extra >layer of failureproofing. Yes, this is a good idea. An alternative is to copy the old file somewhere else, then write the new file onto it, then delete the copy. It's a little messy, though--I agree. > Never mind that overwriting the old file >preserves fragmentation even when the disk is capable of laying out >the file in a smarter fashion. This is only true if you don't truncate the file before overwriting it. A call to SetEOF to truncate the file to zero length, then a call to Allocate to grab however much space you need, will let the file system grab contiguous free space if it can. >(And for anyone who may think that file ids are required for the new >symbolic link feature, which *is* useful -- think again. All you need >to store is what UNIX stores, the full path name.) Umm, I really can't totally agree. It is *possible* to implement symbolic links by storing the full path name. However, I don't like it, because renaming files then breaks symbolic links. (It can be very frustrating to discover that a program doesn't run because it uses a symbolic link and the target has been renamed or deleted.) It's a little better to use the directory ID and file name--that way, renaming/moving the directory doesn't break the link. Renaming the file still does, though. A file ID system would work best (kind of like UNIX's hard links), but the HFS directory structure doesn't allow lookups by file-ID (file IDs already exist, they're called file numbers and are used internally by HFS). Without a lookup mechanism, file IDs are sort of useless. Of course, you can always find the file with the right ID by just searching the whole HFS directory tree :-) . >Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com +----------------------------------+------------------------+ | Anton Rang (grad student) | "VMS Forever!" | | Michigan State University | rang@cpswh.cps.msu.edu | +----------------------------------+------------------------+
amanda@intercon.uu.net (Amanda Walker) (08/31/89)
In article <416@kunivv1.sci.kun.nl>, ge@kunivv1.sci.kun.nl (Ge' Weijers) writes: > I wonder why it is more difficult to implement file IDs than directory IDs. > I suppose the problem is similar, especially in systems where directories > are implemented as files (NFS/UNIX) Two reasons, both of them pragmatic: 1. There are usually many fewer directories than there are files, so that strategies that would work for Directory IDs are likely to bog down sooner if used for files as well. 2. Currently, the only application which actually *depends* on Directory IDs is the Finder, and especially in conjunction with the Dekstop Database calls, this means that Directory IDs can be created on a per-session basis, as opposed to maintaining a (potentially very large) database on disk. -- Amanda Walker InterCon Systems Corporation amanda@intercon.uu.net | ...!uunet!intercon!amanda