---

Jeg roder lidt med noget HTML-pjat og vil gerne se hvordan det ser ud
i de forskellige browsere. Mozilla og IE har ikke nogen problemer med
at tage filer direkte fra filsystemet, men den Netscape 4.77 som
ligger i OS 9 applikationerne tror det er binaer filer og viser dem
derfor ikke.

Ikke noget problem, jeg gaar bare via Apache paa maskinen, men det
lader til at jeg ikke kan tilgaa maskinen selv fra Communicatoren.
Alle andre gaar fint, men ikke til hverken 127.0.0.1 eller det
IP-nummer jeg faar tildelt af DHCP-serveren. Det synes jeg er mystisk
- er det bare mig, eller kan man ikke det?

(OS X udgaverne kan sagtens).
--
Thorbjørn Ravn Andersen
http://homepage.mac.com/ravn

---

Thorbjørn Ravn Andersen <ravn@mac.com> wrote:

> Jeg roder lidt med noget HTML-pjat og vil gerne se hvordan det ser ud
> i de forskellige browsere. Mozilla og IE har ikke nogen problemer med
> at tage filer direkte fra filsystemet, men den Netscape 4.77 som
> ligger i OS 9 applikationerne tror det er binaer filer og viser dem
> derfor ikke.

Hvilken fil type er der tale om siden Netscape ikke vil kendes ved den?
Det kan være et simplet spørgsmål om filemapping i Mac OS 9

> Ikke noget problem, jeg gaar bare via Apache paa maskinen, men det
> lader til at jeg ikke kan tilgaa maskinen selv fra Communicatoren.
> Alle andre gaar fint, men ikke til hverken 127.0.0.1 eller det
> IP-nummer jeg faar tildelt af DHCP-serveren. Det synes jeg er mystisk
> - er det bare mig, eller kan man ikke det?

Classic programmer kan desværre ikke tilgå Mac OS X servere lokalt.

Du kan slå Mac OS 9's "Personlig webdeling" til, og teste din html i Mac
OS 9 browserere derfra.

--
Venlig hilsen Morten Reippuert Knudsen...

<icq:131382336>

---

spam@reippuert.dk (Morten Reippuert) writes:

> Hvilken fil type er der tale om siden Netscape ikke vil kendes ved den?
> Det kan være et simplet spørgsmål om filemapping i Mac OS 9

HTML-filer jeg har gemt med XEmacs. Jeg har IKKE bootet i Mac OS 9,
men bare startet Classic.

> Classic programmer kan desværre ikke tilgå Mac OS X servere lokalt.

Hvorfor ikke??? Mig ikke forstaa.

> Du kan slå Mac OS 9's "Personlig webdeling" til, og teste din html i Mac
> OS 9 browserere derfra.

Hmmm... Det maa jeg lige kigge paa. Virker det i Classic? Jeg er
ikke interesseret i at reboote.

--
Thorbjørn Ravn Andersen
http://homepage.mac.com/ravn

---

ravn@mac.com (Thorbjørn Ravn Andersen) writes:

> HTML-filer jeg har gemt med XEmacs. Jeg har IKKE bootet i Mac OS 9,
> men bare startet Classic.

Ok. Det her er vejen frem. HTML-filer under et givent katalog skal
kunne aabnes af Communicator. Vodden goer man det? Og kun for OS 9
programmer?
>
> > Classic programmer kan desværre ikke tilgå Mac OS X servere lokalt.
>
> Hvorfor ikke??? Mig ikke forstaa.
>
> > Du kan slå Mac OS 9's "Personlig webdeling" til, og teste din html i Mac
> > OS 9 browserere derfra.
>
> Hmmm... Det maa jeg lige kigge paa. Virker det i Classic? Jeg er
> ikke interesseret i at reboote.

Heh. Start Webdeling giver en god gammeldags bombe med en Reboot.
Den har jeg ikke set de sidste 10 aar Hvordan lukker man saa
Classic ned?
--
Thorbjørn Ravn Andersen
http://homepage.mac.com/ravn

---

Thorbjørn Ravn Andersen <ravn@mac.com> wrote:

> Heh. Start Webdeling giver en god gammeldags bombe med en Reboot.
> Den har jeg ikke set de sidste 10 aar

En vaskeægte udvidelseskonflikt

Jeg har lige selv prøvet uden bombe og kunne også starte webdeling, men
det tog et par minutter og trueblue åd _alle_ systemrecurser

> Hvordan lukker man saa Classic ned?

alt+shift+esc

--
Venlig hilsen Morten Reippuert Knudsen...

<icq:131382336>

---

Thorbjørn Ravn Andersen <ravn@mac.com> wrote:

> spam@reippuert.dk (Morten Reippuert) writes:
>
> > Hvilken fil type er der tale om siden Netscape ikke vil kendes ved den?
> > Det kan være et simplet spørgsmål om filemapping i Mac OS 9
>
> HTML-filer jeg har gemt med XEmacs. Jeg har IKKE bootet i Mac OS 9,
> men bare startet Classic.

Det behøver du heller ikke. Programmer der afvikles i Classic benytter
Mac OS 9's håndtering af filemappeing, de forstår ikke filnavn
extensions.

Tildel din fil type/crator værdier som netscape kan forstå: eks type:
TEXT og crator: MOSS (OBS. begge er case sensitive).

Du skal bruge en resurcegren editor til formålet, standart værktøjet er
Apples Resedit til Mac OS 9, men der er flere Mac OS X programmer der
kan klare opgaven, eks. SuperGetInfo.

> > Classic programmer kan desværre ikke tilgå Mac OS X servere lokalt.
>
> Hvorfor ikke??? Mig ikke forstaa.

Jeg ved ikke hvorfor, jeg har bare konstateret det (og tilmed netop
forsøgt mig med en host fil uden held). Der er to problemer:

En begrænsning i trueblue VM'en mht. at man ikke kan koble på
serverere, der kører i Mac OS X på samme IP nummer. Det er muligt at
det kan omgås ved portmapping.

Mac OS 9 har aldrig understøttet en loopback adresse (127.0.0.1)

> > Du kan slå Mac OS 9's "Personlig webdeling" til, og teste din html i Mac
> > OS 9 browserere derfra.
>
> Hmmm... Det maa jeg lige kigge paa. Virker det i Classic? Jeg er
> ikke interesseret i at reboote.

Ja, det vil jeg mene. Det skulle være lige til at starte i Mac OS 9
kontrolpanelet "Personlig webdeling".

--
Venlig hilsen Morten Reippuert Knudsen...

<icq:131382336>

---

spam@reippuert.dk (Morten Reippuert) writes:

> Du skal bruge en resurcegren editor til formålet, standart værktøjet er
> Apples Resedit til Mac OS 9, men der er flere Mac OS X programmer der
> kan klare opgaven, eks. SuperGetInfo.

Heh. Skulle Mac OS 9 vaere mere brugervenligt end Unix? Jaja, man
laerer noget nyt hver dag.

Min konklusion paa det her er indtil videre at jeg ikke er imponeret
over OS 9 og emuleringen af samme, og at jeg vil afvente aftestning
med Netscape 4.77 indtil jeg har flyttet det over paa en anden
maskine.

Det skal dog ogsaa siges at det er den foerste alvorlige mangel ved
emuleringen jeg er faldet over. Eneste anden detalje er at OS X har
svare problemer med 256 farve tilstanden, som nogle af de gamle
programmer jeg har hentet for sjov meget gerne vil have. Selv det
gamle Crystal Quest som jeg spillede paa de oprindelige Mac'er i
terminalrummet i tidernes morgen, kan koere paa min powerbook.
Desvaerre er det ret svaert at styre med en touchpad, men der var
nostalgi i laartykke straaler.

> Mac OS 9 har aldrig understøttet en loopback adresse (127.0.0.1)

Hallo. Man skal da have 127.0.0.1 for at have en komplet TCP/IP
implementation. Hvad er det her for noget.

> Ja, det vil jeg mene. Det skulle være lige til at starte i Mac OS 9
> kontrolpanelet "Personlig webdeling".

Classic er ikke kommet op endnu efter jeg gav den kniven. Gad vide
hvad den laver?
--
Thorbjørn Ravn Andersen
http://homepage.mac.com/ravn

---

Thorbjørn Ravn Andersen <ravn@mac.com> wrote:

> spam@reippuert.dk (Morten Reippuert) writes:
>
> > Du skal bruge en resurcegren editor til formålet, standart værktøjet er
> > Apples Resedit til Mac OS 9, men der er flere Mac OS X programmer der
> > kan klare opgaven, eks. SuperGetInfo.
>
> Heh. Skulle Mac OS 9 vaere mere brugervenligt end Unix? Jaja, man
> laerer noget nyt hver dag.

Både og type/creator er smartere end almindelige extensions, idet flere
filer af samme type ikke nødvendigvis mappes til samme program.
Ulempen ved Apples valg er at meta data gemmes i resucegrenen, som mildt
sagt er noget bøvl så snart filen flyttes til andre filsystemer.

I Mac OS X har Apple lavet en uskøn blanding af brug af filnavn
exensions og cytpe/creator i recursegrenen.

> > Mac OS 9 har aldrig understøttet en loopback adresse (127.0.0.1)
>
> Hallo. Man skal da have 127.0.0.1 for at have en komplet TCP/IP
> implementation. Hvad er det her for noget.

noget lort? TCP/IP implemantationen OpenTransport er så at sige
klasket oven på et OS, hvis primære netværks protokol altid har været
AppleTalk.

> > Ja, det vil jeg mene. Det skulle være lige til at starte i Mac OS 9
> > kontrolpanelet "Personlig webdeling".
>
> Classic er ikke kommet op endnu efter jeg gav den kniven. Gad vide
> hvad den laver?

Den er sikkert afgået ved døden - kig efter om "trueblue-et-eller-andet"
kører. ellers kan du jo myrde det manuelt. (Classic er kun det prgram
som indlæser Mac OS 9 i trueblue VM'en)

--
Venlig hilsen Morten Reippuert Knudsen...

<icq:131382336>

---

spam@reippuert.dk (Morten Reippuert) writes:


> > Classic er ikke kommet op endnu efter jeg gav den kniven. Gad vide
> > hvad den laver?
>
> Den er sikkert afgået ved døden - kig efter om "trueblue-et-eller-andet"
> kører. ellers kan du jo myrde det manuelt. (Classic er kun det prgram
> som indlæser Mac OS 9 i trueblue VM'en)

Den staar og KVAERNER ved opstart. Jeg bad om at se vinduet og den
naar praecis til cirka 80% hvor den lige har ryddet velkomstskaermen
med de der ikoner der kommer i bunden, og viser en fin blank blaa
skaerm (gad vide om det er der den har navnet fra).

Der har den nu staaet i et kvarter i tredie forsoeg. Jeg tror der er
gaaet noget kaputbof.
--
Thorbjørn Ravn Andersen
http://homepage.mac.com/ravn

---

Thorbjørn Ravn Andersen <ravn@mac.com> wrote:

> Den staar og KVAERNER ved opstart. Jeg bad om at se vinduet og den
> naar praecis til cirka 80% hvor den lige har ryddet velkomstskaermen
> med de der ikoner der kommer i bunden, og viser en fin blank blaa
> skaerm (gad vide om det er der den har navnet fra).
>
> Der har den nu staaet i et kvarter i tredie forsoeg. Jeg tror der er
> gaaet noget kaputbof.

Det er der - eller også er skrivebordsdatabasen meget stor og
fragnmenteret.

Slå den ihjel, og start uden udvidelser (går ud fra at du ikke gider en
Mac OS 9 fejlretning). Netscape burde kunne køre og læse filer uden
netværksstakken er indlæst.

System Preferences -> Classic, fanebladet "advanced", under "startup
options" kan du starte classic uden at indlæse udvidelser.

--
Venlig hilsen Morten Reippuert Knudsen...

<icq:131382336>

---

spam@reippuert.dk (Morten Reippuert) writes:

> Slå den ihjel, og start uden udvidelser (går ud fra at du ikke gider en
> Mac OS 9 fejlretning). Netscape burde kunne køre og læse filer uden
> netværksstakken er indlæst.

Det lykkedes mig at starte uden udvidelser inden jeg fik dit svar.
Men saa kan jeg jo ikke surfe med Communicatoren, og det er jo ikke en
loesning, saa svaret maa blive at "Jo, jeg gider godt en OS 9
fejlretning". Oev.

Nu ser jeg foerst om en genstart af maskinen loeser problemet.
--
Thorbjørn Ravn Andersen
http://homepage.mac.com/ravn

---

Thorbjørn Ravn Andersen <ravn@mac.com> wrote:

> Det lykkedes mig at starte uden udvidelser inden jeg fik dit svar.
> Men saa kan jeg jo ikke surfe med Communicatoren, og det er jo ikke en
> loesning, saa svaret maa blive at "Jo, jeg gider godt en OS 9
> fejlretning". Oev.
>
> Nu ser jeg foerst om en genstart af maskinen loeser problemet.

Det gør det højst sansynligt ikke.

Ellers vil jeg anbefale at du finder din CD frem #"¤#¤%, øh nej det er
det vist noget med du ikke kan

Ok, jeg vil tro at det fejl skyldes en række indstillings filer,
relateret til Fildeling, Webddeling og OpenTransport.
Det nemeste er et nuke mappen '/Systemmappe/Indstillinger', idet jeg går
ud fra, at du ikke før har brugt Mac OS 9 og dermed ikke har nogen
indstillinger, der er værd at gemme på - ellers kan du jo lige hive dem
ud inden mappen slettes.

--
Venlig hilsen Morten Reippuert Knudsen...

<icq:131382336>

---

spam@reippuert.dk (Morten Reippuert) writes:

> > Det lykkedes mig at starte uden udvidelser inden jeg fik dit svar.
> > Men saa kan jeg jo ikke surfe med Communicatoren, og det er jo ikke en
> > loesning, saa svaret maa blive at "Jo, jeg gider godt en OS 9
> > fejlretning". Oev.
> >
> > Nu ser jeg foerst om en genstart af maskinen loeser problemet.
>
> Det gør det højst sansynligt ikke.

Den brugte ellers en lille time paa at checke disken (formentlig
hovedgrunden til at OS X ikke markedsfoerers som et serversystem)
hvorefter den haardnakket mente at det var en OS 9 maskine. Saa fik
jeg ogsaa set det... Efter lidt hovedbundskradseri lykkedes det mig
at komme tilbage i OS X. Jeg kan godt se at folk synes at de er meget
forskellige.

Bumbum. Nu venter jeg paa at Communicator faar trukket Classic i
luften. Vupti, aha, nu koerer det fint. Saa, OS X er virkelig
ligesom Windows - genstart og saa virker det. Windows er bare
hurtigere til at koere scandisk.

Hvis den var mere snakkesagelig havde jeg nok gaettet at den stod og
taeskede loes paa disken... Oh well.

> Det nemeste er et nuke mappen '/Systemmappe/Indstillinger', idet jeg går
> ud fra, at du ikke før har brugt Mac OS 9 og dermed ikke har nogen
> indstillinger, der er værd at gemme på - ellers kan du jo lige hive dem
> ud inden mappen slettes.

Jeg har brugt det da jeg isntallerede OS X, men ellers ikke. Det var
sjovt at se hvor anderledes den velkendte maskine blev.

Pyt, nu tror jeg den har det bedre. Takker for tiltagene.

--
Thorbjørn Ravn Andersen
http://homepage.mac.com/ravn

---

Morten Reippuert skrev:

> Både og type/creator er smartere end almindelige extensions, idet flere
> filer af samme type ikke nødvendigvis mappes til samme program.
Nemlig.

> Ulempen ved Apples valg er at meta data gemmes i resucegrenen, som mildt
> sagt er noget bøvl så snart filen flyttes til andre filsystemer.
Well, det er vel principielt ikke helt korrekt (selv om effekten er den
samme).

Som jeg har forstået det, kan man sige, at der for et "gammeldags"
Apple-arkiv er tre dele:

1) Data-grenen, der består af en lang sekvens af bytes.

2) Resurse-grenen, der består af en række "resurser".

3) Metaoplysninger, herunder navn, oprettelsestidspunkt, tidspunkt for
seneste ændring, oprettelsesprogram, arkivtype, synlighed, låst/ikke
låst osv.

Der er således tale om et mere avanceret system, end det kendes fra
andre filsystemer, hvor der typisk ikke er resursegren, og hvor der er
færre (og/eller andre) metaoplysninger.

Når det er "noget bøvl", at oplysninger om oprettelsesprogram og
arkivtype ikke bibeholdes, når arkivet flyttes til andre filsystemer,
skyldes det altså - som jeg forstår det - ikke disse systemers mangel på
resursegren, men at der er færre metaoplysninger, hvilket ikke er helt
det samme.

--
Mvh.
Jesper Juellund Jensen
E-mail: jjj@cyrk.dk
http://cyrk.dk/programmer/

---

Jesper Juellund Jensen <jjj@cyrk.dk> wrote:

> Som jeg har forstået det, kan man sige, at der for et "gammeldags"
> Apple-arkiv er tre dele:
>
> 1) Data-grenen, der består af en lang sekvens af bytes.
>
> 2) Resurse-grenen, der består af en række "resurser".
>
> 3) Metaoplysninger, herunder navn, oprettelsestidspunkt, tidspunkt for
> seneste ændring, oprettelsesprogram, arkivtype, synlighed, låst/ikke
> låst osv.

Som arkiveres i recusegrenen, frem for i datagrenen.

> Der er således tale om et mere avanceret system, end det kendes fra
> andre filsystemer, hvor der typisk ikke er resursegren, og hvor der er
> færre (og/eller andre) metaoplysninger.
>
> Når det er "noget bøvl", at oplysninger om oprettelsesprogram og
> arkivtype ikke bibeholdes, når arkivet flyttes til andre filsystemer,
> skyldes det altså - som jeg forstår det - ikke disse systemers mangel på
> resursegren, men at der er færre metaoplysninger, hvilket ikke er helt
> det samme.

Enig - Fordelene er at metadata er universelle frem for bundet til det
enkelte program, det lokale filsystem eller lagres på forskellig vis fra
fil til fil, men det er bestemt en ulempe når filerne flyttes til andre
filsystemer, eller computere uden creator programmet.

Da 95% af verdens computere ikke bruger dette system, er det
irriterende.

Personligt synes jeg godt om Mac OS X's løsning med extensions som
generel fil mapping og LS filerne til at lagre undtagelser i, frem for
den gamle mac OS 9 løsning. BeOS's løsning var dog intet mindre end
genial.

--
Venlig hilsen Morten Reippuert Knudsen...

<icq:131382336>

---

Morten Reippuert <spam@reippuert.dk> wrote:

> Jesper Juellund Jensen <jjj@cyrk.dk> wrote:
>
> > Som jeg har forstået det, kan man sige, at der for et "gammeldags"
> > Apple-arkiv er tre dele:
> >
> > 1) Data-grenen, der består af en lang sekvens af bytes.
> >
> > 2) Resurse-grenen, der består af en række "resurser".
> >
> > 3) Metaoplysninger, herunder navn, oprettelsestidspunkt, tidspunkt for
> > seneste ændring, oprettelsesprogram, arkivtype, synlighed, låst/ikke
> > låst osv.
>
> Som arkiveres i recusegrenen, frem for i datagrenen.

Er du _helt_ sikker på det? Jeg har nemlig forstået det ligesom Jesper.

Et arkiv kan godt eksistere uden en ressource-gren. Faktisk er det
tilfældet for de fleste af vores almindelige dokumenter og specielt for
de dokumenter, som frit kan flyttes mellem platforme.

Hvis man prøver at åbne sådan et dokument i Resedit, så får man at vide,
at der ikke er nogen ressource-gren, og man får tilbudt at oprette en.
Men alle dokumenter har alligevel alle meta-data, bl.a. koder for type
og skaber. Disse gemmes så vidt jeg har forstået i et særligt område i
starten af disken.

Fra "nørdens" synspunkt er det naturligvis irriterende at disse
meta-data er gemt og ikke umiddelbart rediger-bare. For os andre er det
nu meget godt. Vi kan hurtigt kløjs i alt for mange mystiske koder og
forkortelser. Generelt synes jeg Mac OS X er blevet langt mere "nørdet"
end de tidligere versioner, og har mistet en del i brugervenlighed.
Måske er det blot et udtryk for, at den gennemsnitlige computer-bruger
er blevet mere fortrolig med computere og ikke skal "pakkes så godt ind"
som tidligere?

--
Thorkil Olesen,
Hanstholm.

---

Thorkil Olesen <thorkil.spam-block@pip.dknet.dk> wrote:

> Morten Reippuert <spam@reippuert.dk> wrote:
>
> > Jesper Juellund Jensen <jjj@cyrk.dk> wrote:
> >
> > > Som jeg har forstået det, kan man sige, at der for et "gammeldags"
> > > Apple-arkiv er tre dele:
> > >
> > > 1) Data-grenen, der består af en lang sekvens af bytes.
> > >
> > > 2) Resurse-grenen, der består af en række "resurser".
> > >
> > > 3) Metaoplysninger, herunder navn, oprettelsestidspunkt, tidspunkt for
> > > seneste ændring, oprettelsesprogram, arkivtype, synlighed, låst/ikke
> > > låst osv.
> >
> > Som arkiveres i recusegrenen, frem for i datagrenen.
>
> Er du _helt_ sikker på det? Jeg har nemlig forstået det ligesom Jesper.
>
> Et arkiv kan godt eksistere uden en ressource-gren. Faktisk er det
> tilfældet for de fleste af vores almindelige dokumenter og specielt for
> de dokumenter, som frit kan flyttes mellem platforme.
>
> Hvis man prøver at åbne sådan et dokument i Resedit, så får man at vide,
> at der ikke er nogen ressource-gren, og man får tilbudt at oprette en.
> Men alle dokumenter har alligevel alle meta-data, bl.a. koder for type
> og skaber. Disse gemmes så vidt jeg har forstået i et særligt område i
> starten af disken.

type/creator som vi diskuterer gemmes altid i recusegrenen.

Internetconfig og Arkivudveksling tildeler dokumenterne en recursegren,
når de overføres mac'en. Disse filemappings kan være et helvede når
diverse programmer, uden at advare brugeren, modificer indstillingerne
efter eget godt befindende.

For den almindelige bruger, er det ikke særligt nemt at overskue,
hvordan han skal ændre filemapping indstillinger i Mac OS 7-9.

I Mac OS X er er det uhyre enkelt: Vis info på filen i Finder.app og
vælg "open with application". Vælg et program og tryk "Change all",
hvorefter alle dokumenter med netop den "type" og fil endelse fremover
vil blive åbnet af det valgte program - med mindre man har tildelt filen
individuelle atributter.

> Fra "nørdens" synspunkt er det naturligvis irriterende at disse
> meta-data er gemt og ikke umiddelbart rediger-bare. For os andre er det
> nu meget godt. Vi kan hurtigt kløjs i alt for mange mystiske koder og
> forkortelser. Generelt synes jeg Mac OS X er blevet langt mere "nørdet"
> end de tidligere versioner, og har mistet en del i brugervenlighed.
> Måske er det blot et udtryk for, at den gennemsnitlige computer-bruger
> er blevet mere fortrolig med computere og ikke skal "pakkes så godt ind"
> som tidligere?

mht. til metadata er MacOS X blevet mere nørdet, fordi Apple har valgt
at blande to forskellige metoder for håndtering af metadata, og endnu
værre: har undladt at udstede klare retningsliner om hvilken type der
_bør_ anvendes af udviklerne.

--
Venlig hilsen Morten Reippuert Knudsen...

<icq:131382336>

---

spam@reippuert.dk (Morten Reippuert) writes:

> type/creator som vi diskuterer gemmes altid i recusegrenen.

I så fald burde ResEdit vel aldrig komme med beskeden: This file has
no resource fork. Opening it will add one. Are you sure you wish to
continue? Eller hvad?

Nå, hvem kommer først med en henvisning til Inside Macintosh: Files?


--
Thomas Bjorn Andersen - tba@gen-v.net
+++ATH

---

Thomas Bjorn Andersen skrev:

> Nå, hvem kommer først med en henvisning til Inside Macintosh: Files?
Jeg har prøvet at bladre i den, men uden resultat.

På side 1-5 står der dog om data- og resursegrenen, at "one or both of
those forks can be empty. Document files sometimes contain only data (in
which case the resource fork is empty)."

Det må betyde, at oplysning om arkivtype og oprettelsesprogram
(type/creator) IKKE placeres i resursegrenen, da disse oplysninger ALTID
er en del af et arkiv på HFS(+) - uanset om resursegrenen er tom eller
ej.

--
Mvh.
Jesper Juellund Jensen
E-mail: jjj@cyrk.dk
http://cyrk.dk/

---

Thomas Bjorn Andersen <tbamacnews@gen-v.net> wrote:

> Nå, hvem kommer først med en henvisning til Inside Macintosh: Files?
>

det regner jeg bestemt med at du gør - se i øvrigt mit svar til jesper.

--
Venlig hilsen Morten Reippuert Knudsen...

<icq:131382336>

---

Morten Reippuert skrev:

> type/creator som vi diskuterer gemmes altid i recusegrenen.
Jeg er - som du kan forstå - uenig.

Mener du så også, at andre ligestillede oplysninger som for eksempel
navn, oprettelsestidspunkt, tidspunkt for seneste ændring, synlighed,
låst/ikke låst osv. også skulle være placeret i resursegrenen? Nej,
vel?...

> Internetconfig og Arkivudveksling tildeler dokumenterne en recursegren,
> når de overføres mac'en.
Nej, systemet "justerer" arkivernes arkivtype og oprettelsesprogram
(type/creator), de "tildeler" dem ikke (da de altid findes).

Ja, ja, jeg ved godt, at det er ordkløveri, men det er for at
understrege, at arkivtype og oprettelsesprogram er oplysninger, der
altid findes, og altså oplysninger, der ikke ligger i resursegrenen.

> Disse filemappings kan være et helvede når diverse programmer, uden at
> advare brugeren, modificer indstillingerne efter eget godt befindende.
Ja, det kan være irriterende.

Men det er vel ikke anderledes på et system, hvor dokumenter knyttes til
programmer alene ved "endelse" (".jpg" osv.): Der må være en liste, hvor
hver endelse tilknyttes et program - og det er irriterende, når
programmer ændrer i disse oplysninger uden at advare brugeren.

I det mindste ændrer modificerede indstillinger i Arkivudveksling ikke
på arkiver, der allerede findes på disken.

--
Mvh.
Jesper Juellund Jensen
E-mail: jjj@cyrk.dk
http://cyrk.dk/

---

Jesper Juellund Jensen <jjj@cyrk.dk> wrote:

> > type/creator som vi diskuterer gemmes altid i recusegrenen.
>
> Jeg er - som du kan forstå - uenig.

Pas på med det, i visse lande kan man blive skudt for den slags

> Mener du så også, at andre ligestillede oplysninger som for eksempel
> navn, oprettelsestidspunkt, tidspunkt for seneste ændring, synlighed,
> låst/ikke låst osv. også skulle være placeret i resursegrenen? Nej,
> vel?...

Du har måske ret (#%¤#! damm...)

Jeg har lige åbnet en word fil i resedit og dens resucegren synes
umidelbart tom - der i al fald ingen editerbare data.

Ikke desto mindre forsvinder visse metadata, eks. type, creator, mærker,
kommentare og brugerretigheder (*nix), når jeg kopierer den til
windows's FAT32 partition og kopierer den tilbage igen til Mac OS's HFS
partition - kun oprettelse- og ændringsdato bibeholdes. Hvor gemmes de
resterende metadata så? De kan ikke ligge i datagrenen, da de i så fald
ville have været bibeholdt.

Hvordan bibeholdes type/creator når jeg koder filen med mac-binary eller
lignende og flytter den til en anden computer? Læser mac-binary koderen
de rette metadata fra diskens metadata arkiv og inkluderer metadata i
den kodede fil?

Jeg er tæt på at acceptere denne forklaring, men er stadig forvirret.
Det skyldes at Resedits "Get File/Folder Info..." komando angiver at der
_er_ data i den oprindelige fils recursegren, de er bare ikke umidelbart
editerbare eller læseslige. Helt bestemt er der 286 bytes i
recursegrenen. Filen der har været en tur om PC'en og har mistet de
oprindelige metadata og recursegrenen, har en recursegren på 0 bytes.

Kan det tænkes at metadata opbevares både i diskens metadata arkiv og i
resurcegrenen?

> > Internetconfig og Arkivudveksling tildeler dokumenterne en recursegren,
> > når de overføres mac'en.

> Ja, ja, jeg ved godt, at det er ordkløveri, men det er for at
> understrege, at arkivtype og oprettelsesprogram er oplysninger, der
> altid findes, og altså oplysninger, der ikke ligger i resursegrenen.

Men oplysningerne forsvinder hvis filen flyttes til eks. et FAT
filsystem.

> > Disse filemappings kan være et helvede når diverse programmer, uden at
> > advare brugeren, modificer indstillingerne efter eget godt befindende.
>
> Ja, det kan være irriterende.

Jeg vil nok vælge et stærkere udtryk.

> Men det er vel ikke anderledes på et system, hvor dokumenter knyttes til
> programmer alene ved "endelse" (".jpg" osv.): Der må være en liste, hvor
> hver endelse tilknyttes et program - og det er irriterende, når
> programmer ændrer i disse oplysninger uden at advare brugeren.

Til gængæld er det nemt at ændre tilhørsforhold for alle filer af samme
type på én gang. Envidere har type/creator systemet en ikke ubetydelig
ulempe på flerbrugersystemer.

Som du sikkert kan forstå, så jeg gerne at Apple havde kylet
type/creator ud og udelukkende basserede Mac OS X på MIME typer -
undtagelser for den enkelte fil kan lagres i en database. Alternativt
kunne Apple have givet brugeren mulighed for med en knap at slå
type/creator til og fra.

--
Venlig hilsen Morten Reippuert Knudsen...

<icq:131382336>

---

Morten Reippuert skrev:

> > Jeg er - som du kan forstå - uenig.
> Pas på med det, i visse lande kan man blive skudt for den slags
Det er vist ikke nu, at jeg skal nævne, at jeg arbejder på et
konkurrerende københavnsk lærerseminarium...

> Jeg har lige åbnet en word fil i resedit og dens resucegren synes
> umidelbart tom - der i al fald ingen editerbare data.
Præcis. Og alligevel har den oplysninger om oprettelsesprogram og
arkivtype.

> Ikke desto mindre forsvinder visse metadata, eks. type, creator, mærker,
> kommentare og brugerretigheder (*nix), når jeg kopierer den til
> windows's FAT32 partition og kopierer den tilbage igen til Mac OS's HFS
> partition - kun oprettelse- og ændringsdato bibeholdes.

Som jeg skrev tidligere, så er kan et arkivs data opdeles i tre og ikke
i to: Datagrenen, resursegrenen og metaoplysninger (eller attributter,
om man vil). Hvilke metaoplysninger/attributter, der er for et arkiv,
afhænger af filsystemet, og her har HFS(+) altså oprettelsesprogram og
arkivtype med, hvilket ikke er tilfældet for andre filsystemer.

> Hvor gemmes de resterende metadata så?
I en særskilt del af arkivet.

> Hvordan bibeholdes type/creator når jeg koder filen med mac-binary eller
> lignende og flytter den til en anden computer? Læser mac-binary koderen
> de rette metadata fra diskens metadata arkiv og inkluderer metadata i
> den kodede fil?
Ja.

For nu at være på helt sikker grund: Jeg ville ikke kalde det "diskens
metadata arkiv", da det ikke bør anskues som et selvstændigt arkiv. Der
er blot tale om, at et arkiv (altså en "fil") har attributter, som er
knyttet til det enkelte arkiv.

> Jeg er tæt på at acceptere denne forklaring, men er stadig forvirret.
Det kan vi da ikke have!

> Det skyldes at Resedits "Get File/Folder Info..." komando angiver at der
> _er_ data i den oprindelige fils recursegren,
Se, dét lyder mærkeligt.

Jeg har dokumenter uden resursegren, hvor ResEdit da også skriver, at
der er 0 bytes i resursegrenen - og alligevel har dokumenterne
oplysninger om oprettelsesprogram og arkivtype.

> Kan det tænkes at metadata opbevares både i diskens metadata arkiv og i
> resurcegrenen?
Ikke den samme metadata, nej.

Men selvfølgelig kan oplysningerne i resursegrenen ofte anskues som
metadata, bare andre data end f.eks. oprettelsesprogram og arkivtype.

> Men oplysningerne forsvinder hvis filen flyttes til eks. et FAT
> filsystem.
Jada. Pointen er jo, at forskellige filsystemer har forskellige
metaoplysninger/attributter for arkiverne. Når man kopierer fra et
filsystem til et andet, så kopieres vel kun de arkivattributter, som er
fælles.

--
Mvh.
Jesper Juellund Jensen
http://cyrk.dk/

---

spam@reippuert.dk (Morten Reippuert) writes:

> Jeg har lige åbnet en word fil i resedit og dens resucegren synes
> umidelbart tom - der i al fald ingen editerbare data.

Ja, eftersom resourcegrenen kan være tom, giver det ingen mening af
gemme data deri. Jeg kan dog godt forstå din forvirring, når man
tager i betragtning hvad Apple ellers har formået at mase ned i
resource grenen af ting såsom ikoner BNDL resourcer osv.

> Ikke desto mindre forsvinder visse metadata, eks. type, creator, mærker,
> kommentare og brugerretigheder (*nix), når jeg kopierer den til
> windows's FAT32 partition og kopierer den tilbage igen til Mac OS's HFS
> partition - kun oprettelse- og ændringsdato bibeholdes. Hvor gemmes de
> resterende metadata så? De kan ikke ligge i datagrenen, da de i så fald
> ville have været bibeholdt.

De kan f.eks. gemmes i en fil med navnet .fndrinfo eller tilsvarende.


> Hvordan bibeholdes type/creator når jeg koder filen med mac-binary eller
> lignende og flytter den til en anden computer? Læser mac-binary koderen
> de rette metadata fra diskens metadata arkiv og inkluderer metadata i
> den kodede fil?

Præcist.

> > Men det er vel ikke anderledes på et system, hvor dokumenter knyttes til
> > programmer alene ved "endelse" (".jpg" osv.): Der må være en liste, hvor
> > hver endelse tilknyttes et program - og det er irriterende, når
> > programmer ændrer i disse oplysninger uden at advare brugeren.

Uden at være sikker, mener jeg BeOS gemte en mime streng i metadata
under deres BeFS. Det giver dog samme problem når filen flyttes til
mindste fællesnævner, ie. DOS.

I øvrigt: Da der ikke er andre der er kommet med reference til Inside
Mac Macintosh: Files må jeg vel hellere gøre det; Inside
Macintosh:Files pp 2-87 Data Organization on Volumes.

Her fremgår det ret tydeligt hvad der gemmes i filsystemet.

Thomas
--
Thomas Bjorn Andersen - tba@gen-v.net
+++ATH

---

Morten Reippuert <spam@reippuert.dk> wrote:

> mht. til metadata er MacOS X blevet mere nørdet, fordi Apple har valgt
> at blande to forskellige metoder for håndtering af metadata, og endnu
> værre: har undladt at udstede klare retningsliner om hvilken type der
> _bør_ anvendes af udviklerne.

Retningslinjerne er nu ganske klare nu. De var lidt vage under betaen og
første udgave af Mac OS X. Apple anbefaler nu at bruge extensions og kun
bruge type/creator som en bagudkompatibilitet til 9.x.

Jeg har ikke megen online adgang og mulighed for at finde et online
link, så jeg har sakset fra min udvikler dokumentation og det er ganske
god information

Personligt er jeg glad for at type/creator ryger ud. At det skulle være
mere brugervenligt syntes jeg ikke det er. De fleste har alligevel en
eller anden form for editor til redigering af disse koder og så er ideen
jo røget ikke sandt? Faktisk er det kun creator som ryger - type er
flyttet fra metadata ud i dokumentnavnet.

Mac OS X meget simple system er ganske godt og kræver ingen værktøjer og
meget bedre end windows ditto. Jeg har f.eks sat pdf dokumenter til at
åbne i preview som udgangspunkt og enkelte hyppigt frekventeret åbner i
Acrobrat Reader. Sådan er mine prefrencer. Andre kan have det
anderledes, så hvis jeg sender dem et pdf dokument har jeg ikke fastlagt
hvilket program der skal bruges - de har de selv.

----------------------------------------------
File Name Extension Guidelines

File Name Extension Hiding

File name extensions and file types are two ways to associate the same
information with a single file: What format the file is. Mac OS 9 stores
this information in a file's meta data as HFS file types. Most other
operating systems, including Windows and most UNIX systems, use file
name extensions to store format information for a file.

Mac OS X aims to provide maximum compatibility with other operating
systems, as well as files exchanged with other users over the Internet,
while preserving the user experience Macintosh users are familiar with.
To accomplish this, Mac OS X version 10.1 introduces per-file hiding of
file name extensions. This feature allows applications to store type
information in file name extensions (enabling easy exchange of files
with users on other platforms or over the Internet) while still
presenting a simple, human readable name to the user. The experience Mac
OS X presents to the user is simple: What you see is what you type. That
is, the file name shown in the Finder matches the file name you typed in
the Save dialog or in the Finder. If you type a file name with an
extension, you see the extension. If you type a file name with no
extension, you see no extension.

Finder Handling of File Name Extensions

The Finder in Mac OS X 10.1 has been enhanced to respect the presence of
a file name extension hidden flag stored for each file. The Finder works
in conjunction with Launch Services to determine what extensions are
known to the system. Known extensions are those claimed by an
application in any of the "regular" application search paths, or claimed
by an application the user has previously launched that is installed in
some other location. (For information on search paths and how the Finder
deals with applications, see Inside Mac OS X: System Overview,
specifically the chapters on the File System and the Finder.)

Files created by Mac OS 9, downloaded from the Internet, or obtained
from some other source always have the hide extension flag unset
initially, regardless of whether or not they have an extension.
Therefore, when a user downloads a file "image.jpg" from the Internet,
it does not magically rename itself to "image" in the Mac OS X Finder.
What the user sees stays consistent. If the user later renames the file
to "mygroovyimage", the .jpg extension is maintained, but becomes
hidden. Again, what the user typed matches what is displayed. In no case
will Mac OS X rename an existing file without the user taking a specific
action to rename that file, nor will renaming a file ever result in
accidental multiple extensions (like " mygroovyimage.jpg.jpg").

Any file with the hide extension flag set and a known extension has that
extension hidden in the Finder. When users edit the name of such a file,
they edit only the user-visible portion. If they explicitly type in a
known file name extension for the file, either the Finder warns them
that what they're doing may change the type of the file (if they enter a
different file name extension), or the Finder changes the state of the
hide extension flag to show the extension (if they enter a new file name
with the proper, currently hidden extension for the file). In all cases,
the Finder allows users to make the changes if they wish. What users see
in the Finder is what they typed when renaming the file, whether or not
they included an extension.

The Finder also allows users to choose to always display file name
extensions, disabling the smart extension hiding behavior that is on by
default. If users want to keep the smart extension hiding on, but need
to know the exact on-disk file name for a given file, they can see it in
that file's Info window in the Finder. Users can also control whether a
specific file's extension is hidden using a checkbox in the Info window.

Interoperability

With the addition of file name extension hiding, it's possible for every
file on the system that has a specific format to also have an extension
indicating that format. Users don't need to be aware of the extension,
and will not accidentally remove it using the Finder. When a user copies
the file to a non-Mac OS system, the file name extension is present and
gives the operating system the information it needs to handle the file
correctly. On Mac OS X, applications that already write out file name
extensions for interoperability purposes now provide an enhanced user
experience; these file name extensions can be hidden on Mac OS X but
automatically get transferred with the file as it moves to a non-HFS
file system. An example of this is when a user uploads a web site
containing html and movie files. Since the movie files already have
their proper file name extensions they don't need to be renamed and
links in associated web pages aren't broken as a result.

Application Responsibilities

To preserve the "what you see is what you typed" user experience, while
supporting robust interoperability by using file name extensions to
indicate file format, applications have several responsibilities. Apple
recommends that applications adopt the following behavior:

* All document files should have an extension indicating the
file's format.
* When displaying file names in their user interface, applications
should use the display name for the file. Mac OS X version 10.1 includes
an API to get the display name for a file. See the "Support" section
below for details.
* When saving files, users should be able to control whether file
name extensions are hidden. For more details, see "Save Dialog
Behavior," below.
* Applications should save newly created document files with a
file name extension, for easy exchange with other operating systems and
other users over the Internet. This file name extension can be hidden,
as described in "Save Dialog Behavior," below.
* When opening and saving a document file, applications should
preserve the value of the document file name extension hidden flag.
* When opening and saving a document file, applications should
preserve the existing file name extension unless the user creates a new
document file by choosing Save As.
* When opening and saving a document file without an extension,
applications should not append an extension or change the value of the
hide extension flag.
* When saving a document file without an extension as a new file
in a Save As operation, applications should add an extension just as
they would when creating a new document file.

Applications may set an HFS file type for documents they create if they
wish. The benefit is increased interoperability with Mac OS 9
applications. Any existing HFS type of a file opened and saved by an
application should be preserved, unless the user does an explicit Save
As operation that creates a new file, or the application changes the
type of the file as a result of the editing. If the user performs a Save
As operation, the application may choose what file name extension and
file type to use for the newly created file. If the application changes
the type of the file as a result of editing it, the application should
generally save it as a new file.

Applications may set an HFS creator for documents they create if they
wish. This creates a tight binding between the newly created document
and the application that created it. Users can always change which
application is used to open a specific document, or all documents with a
specific type and creator code, by using the Info window in the Finder.
If an application wants to change the creator code for a file it opens,
the application should bring up a Save dialog when the user saves the
file. At this point it is also appropriate to add an extension to
indicate the type of the file.

Applications that are not a primary editor for documents of a given type
should not set a creator code for those documents. The main example of
this is an Internet browser that downloads files of many different
types. In Mac OS X, users can associate applications with files of a
given type using file name extensions. Browsers downloading files from
the Internet should allow the user to choose which application to use to
view those files by simply allowing the Finder to open them with the
user's default application for that file type.

Save Dialog Behavior

Applications should support ease of interoperation with other operating
systems and Internet services by saving files with file name extensions.
Your application should claim the file name extensions it saves by
making appropriate entries in its Info.plist. See the discussion of file
types in the "Installation and Integration" chapter of Inside Mac OS X:
System Overview for details.

To support user controlled per-file file name extension hiding,
applications need to explicitly enable the new behavior provided by
Carbon and Cocoa in their Save dialogs.

Applications that enable this new functionality will see the following
new behavior in their save dialogs. A hide extension checkbox appears to
the left of the Save and Cancel buttons in the expanded view of the Save
dialog. (This checkbox does not appear in the collapsed version of the
Save dialog.) The state of this checkbox controls whether the file name
extension is displayed both in the Finder and the application. The Save
dialog remembers the last state of the hide extension checkbox as set by
the user and preserves it for future save operations.

There are three scenarios to consider when the user is saving a file:

1. The user types a file name with no extension or with an
extension not known to the system (for example "My Document.old").

The hide extension checkbox is checked, and the file is saved with the
file name extension appended to the name the user entered. The hide
extension flag is set in the file system for the new file. The Finder
displays the document name as "My Document.old".

2. The user types a file name with the known, correct extension.

The hide extension checkbox is automatically deselected, and the file is
saved with the file name and extension as entered by the user. The hide
extension flag is set to "no" in the file system for the new file.

3. The user types a file name with a known, incorrect extension.

The Save dialog displays an alert warning the user that they can not
save the file with the incorrect extension, and indicates what the
correct extension is. The dialog gives the user the choice of saving the
file with the correct extension, saving the file with both extensions,
or canceling the operation.

For example, if a user tries to save a TextEdit document as
"MyFile.jpg", the alert reads, "You cannot save this document with the
extension '.jpg' at the end of the name. The required extension is
'.rtf'. You can choose to use both, so that your file name ends in
'.jpg.rtf'." The buttons are Use .rtf, Cancel, and Use both. ".rtf" is
the correct extension for this document as set by TextEdit, and Use .rtf
is the default button. In no case will the system hide an extension if
doing so would make the file appear to have a different, valid
extension. Therefore, if the user chooses "Use both", the Finder will
display the full saved filename, "MyFile.jpg.rtf".




--
Mvh Michael Tysk-Andersen

---

Michael Tysk-Andersen <mta@mac.com> wrote:

> Retningslinjerne er nu ganske klare nu. De var lidt vage under betaen og
> første udgave af Mac OS X. Apple anbefaler nu at bruge extensions og kun
> bruge type/creator som en bagudkompatibilitet til 9.x.

Ok, jeg har ikke fulgt med i lang tid, idet jeg blev træt af at høre på
evangelisterne høvle Mac OS X i stykker pga. af brugen af extensions.
Jeg synes at der er alt for mange Carbon programmer der stadig bruger
type/creator.

> Personligt er jeg glad for at type/creator ryger ud. At det skulle være
> mere brugervenligt syntes jeg ikke det er. De fleste har alligevel en
> eller anden form for editor til redigering af disse koder og så er ideen
> jo røget ikke sandt?

Jo, filebuddy, resedit, type-mig-dit og type-mig-dat. Jeg har gennem
årene brugt ufattelig megen tid på at afprøve ordentlige type/creator
editore og ændre indstillinger i Arkivudveksling og InternetConfig. Hver
gang jeg er nået frem til ordentlige indstillinger, har jeg skiftet et
program ud, og ellers er der et installationsprogram, der insisterer på
at ændre det hele igen. Til tider har det mindet om klodernes kamp

> Mac OS X meget simple system er ganske godt og kræver ingen værktøjer og
> meget bedre end windows ditto. Jeg har f.eks sat pdf dokumenter til at
> åbne i preview som udgangspunkt og enkelte hyppigt frekventeret åbner i
> Acrobrat Reader. Sådan er mine prefrencer. Andre kan have det anderledes,
> så hvis jeg sender dem et pdf dokument har jeg ikke fastlagt hvilket
> program der skal bruges - de har de selv.

Precisely.

Jeg er envidere glad for at man kan nulstille filemappings ved at slette
LS filerne - hvis blot samtlige programmer ville undlade at tilføje
type/creater ville det være endnu lettere.

Jeg kan i øvrigt anbefale en kontextuel menu ved navn "Zingg!". Den
tilføjer en "open with" menu i Finder.app svarende til "Open with
Application" i info vinduet, men endnu mere anvendeligt.

--
Venlig hilsen Morten Reippuert Knudsen...

<icq:131382336>

---

in article 1f9923o.bo4lg357av9nN%spam@reippuert.dk, Morten Reippuert at
spam@reippuert.dk wrote on 18/03/02 17:12:

> Michael Tysk-Andersen <mta@mac.com> wrote:
>
>> Retningslinjerne er nu ganske klare nu. De var lidt vage under betaen og
>> første udgave af Mac OS X. Apple anbefaler nu at bruge extensions og kun
>> bruge type/creator som en bagudkompatibilitet til 9.x.
>
> Ok, jeg har ikke fulgt med i lang tid, idet jeg blev træt af at høre på
> evangelisterne høvle Mac OS X i stykker pga. af brugen af extensions.
> Jeg synes at der er alt for mange Carbon programmer der stadig bruger
> type/creator.

Alle Carbon programmer bruger type/creator, da de er lettere modificerede
Mac classic programmer. Cocoa programmer er ægte UNIX programmer, der ikke
benytter sig af type/creator.
>
>> Personligt er jeg glad for at type/creator ryger ud. At det skulle være
>> mere brugervenligt syntes jeg ikke det er. De fleste har alligevel en
>> eller anden form for editor til redigering af disse koder og så er ideen
>> jo røget ikke sandt?
>
> Jo, filebuddy, resedit, type-mig-dit og type-mig-dat. Jeg har gennem
> årene brugt ufattelig megen tid på at afprøve ordentlige type/creator
> editore og ændre indstillinger i Arkivudveksling og InternetConfig. Hver
> gang jeg er nået frem til ordentlige indstillinger, har jeg skiftet et
> program ud, og ellers er der et installationsprogram, der insisterer på
> at ændre det hele igen. Til tider har det mindet om klodernes kamp

Alternativet til type/creator er at alle dokumenter an en type kun kan
linkes til ét program, nøjagtig som på PC.

--
Jesper
"Hvis alle slår en skid mod racisme Fredag lugter der af lort Lørdag."
Lillebror i DR TV

---

Jesper <joy@luck.ii> wrote:

> Alle Carbon programmer bruger type/creator, da de er lettere modificerede
> Mac classic programmer.Cocoa programmer er ægte UNIX programmer, der ikke
> benytter sig af type/creator.

Carbon Mach0 programmer er da lige så fuldgyldige UNIX programmer som
Cocoa programmer.

Jeg er egentlig ligeglad om programmerne generer type/creator atributter
eller ej. Jeg ser bare gerne at Mac OS X ser helt bort fra dem.

Mht. til carbon mach0, tag et kig på denne version af mozilla,
programmet kører i BSD laget med en carbon frontend. Sidst jeg tjekkede
var 0.99 endnu ikke færdig, men 0.98 er betydeligt hurtigere end nogen
anden mac browser jeg er stødt på .

--
Venlig hilsen Morten Reippuert Knudsen...

<icq:131382336>

---

spam@reippuert.dk (Morten Reippuert) writes:

> Mht. til carbon mach0, tag et kig på denne version af mozilla,

Er det OS X versionen eller OS 8+

Mozilla er absolut brugbar. IE er bare meget aktiv med at hugge
tildelingen af "hvad skal jeg starte hvis der klikkes på en link"
tilbage. Det er ret irritererende.

--
Thorbjørn Ravn Andersen
http://homepage.mac.com/ravn

---

Thorbjørn Ravn Andersen <ravn@mac.com> wrote:

> Er det OS X versionen eller OS 8+

Det er en mac OS X version (der findes to), Jeg synes, at den seneste
..99 release (CFM) udgave æder voldsomt meget CPU tid.

<http://www.mozilla.org/ports/fizzilla/Mach.html>

> Mozilla er absolut brugbar. IE er bare meget aktiv med at hugge
> tildelingen af "hvad skal jeg starte hvis der klikkes på en link"
> tilbage. Det er ret irritererende.

Ja, det er irriterende, men fejlen ligger vist i Apples implementering
af Internetconfig. Jeg oplever det hver gang jeg opgraderer til seneste
sneakey peak af Omniweb (som er min fortrukne browser).

--
Venlig hilsen Morten Reippuert Knudsen...

<icq:131382336>

---

spam@reippuert.dk (Morten Reippuert) writes:

> Det er en mac OS X version (der findes to), Jeg synes, at den seneste
> .99 release (CFM) udgave æder voldsomt meget CPU tid.

To? Det er da rigtigt. Linket på forsiden er forskelligt fra det i
release notes. Hmmm.. Jeg har taget den fra release notes. Er der
forskel? Jeg har ikke bemærket nogen speciel forskel i forhold til IE.

> Ja, det er irriterende, men fejlen ligger vist i Apples implementering
> af Internetconfig. Jeg oplever det hver gang jeg opgraderer til seneste
> sneakey peak af Omniweb (som er min fortrukne browser).

Testede i går. Deres CSS-understøttelse er mangelfuld, og så vil de
ha pæng.

--
Thorbjørn Ravn Andersen
http://homepage.mac.com/ravn

---

Thorbjørn Ravn Andersen <ravn@mac.com> wrote:

> spam@reippuert.dk (Morten Reippuert) writes:
>
> > Det er en mac OS X version (der findes to), Jeg synes, at den seneste
> > .99 release (CFM) udgave æder voldsomt meget CPU tid.
>
> To? Det er da rigtigt. Linket på forsiden er forskelligt fra det i
> release notes. Hmmm.. Jeg har taget den fra release notes. Er der
> forskel?

Ja, release er som sagt et rent carbon program (CFM), mens mach0 er et
darwin program med en carbon frontend.

> Jeg har ikke bemærket nogen speciel forskel i forhold til IE.

øh, hvordan kommer IE ind i billedet?

> > Ja, det er irriterende, men fejlen ligger vist i Apples implementering
> > af Internetconfig. Jeg oplever det hver gang jeg opgraderer til seneste
> > sneakey peak af Omniweb (som er min fortrukne browser).
>
> Testede i går. Deres CSS-understøttelse er mangelfuld, og så vil de
> ha pæng.

Ikke når det bruges af private, NGO'ere og uddannelsesinstitutioner.

Både CSS2, javacript og rendering hastigheden er ringe, men det er en
fornøjelse af betjene programmet og man kan blive helt afhængig af at
læse text der præsenteres af coregraphics.

--
Venlig hilsen Morten Reippuert Knudsen...

<icq:131382336>

---

spam@reippuert.dk (Morten Reippuert) writes:

> > > .99 release (CFM) udgave æder voldsomt meget CPU tid.

> > Jeg har ikke bemærket nogen speciel forskel i forhold til IE.
>
> øh, hvordan kommer IE ind i billedet?

Med hensyn til CPU-tid.

> > Testede i går. Deres CSS-understøttelse er mangelfuld, og så vil de
> > ha pæng.
>
> Ikke når det bruges af private, NGO'ere og uddannelsesinstitutioner.

Godt. Hvordan bliver jeg så fri for den der "Klik her for at
fortsætte"?

> Både CSS2, javacript og rendering hastigheden er ringe, men det er en
> fornøjelse af betjene programmet og man kan blive helt afhængig af at
> læse text der præsenteres af coregraphics.

Kunne man ikke forvente det af en tilpasset Mozilla, også?
--
Thorbjørn Ravn Andersen
http://homepage.mac.com/ravn

---

Thorbjørn Ravn Andersen <ravn@mac.com> wrote:

> > øh, hvordan kommer IE ind i billedet?
>
> Med hensyn til CPU-tid.

Så er jeg med. Her hos mig æder den hele tiden så meget den kan, selv
når ingen vinduer er åbner spiser den mindst +20% og med etblot et par
tabs spiser den +50% efter de _er_ indlæst og fortolket. Omniweb 4.1sp58
lægger sig pænt ned på 0%.

> > > Testede i går. Deres CSS-understøttelse er mangelfuld, og så vil de
> > > ha pæng.
> >
> > Ikke når det bruges af private, NGO'ere og uddannelsesinstitutioner.
>
> Godt. Hvordan bliver jeg så fri for den der "Klik her for at
> fortsætte"?

i Beta'erne kommer den kun op en gang i mellem - og jeg må indrømme at
jeg er blevet lidt i tvivl om hvorvidt den /er/ gratis til ovennævnte
grupper. Oplysningerne på ders website er i al fald uldne. Anyway, hvis
de får javascript og CCS2 understøttelsen på plads, vil jeg nok ikke
betænke mig for at købe en licens til de 19$ eller 29$.

hvis det var 4.0 eller 4.1b2 du prøvede vil jeg anbefale dig den seneste
sneaky peak i stedet

<http://www.omnigroup.com/ftp/pub/software/MacOSX/.sneakypeek/releases/>

> > Både CSS2, javacript og rendering hastigheden er ringe, men det er en
> > fornøjelse af betjene programmet og man kan blive helt afhængig af at
> > læse text der præsenteres af coregraphics.
>
> Kunne man ikke forvente det af en tilpasset Mozilla, også?

Jo, men endnu er der ingen versioner der bruger den flotte
skriftudjævning. Ikke engang chimera benytter coregraphics.

--
Venlig hilsen Morten Reippuert Knudsen...

<icq:131382336>

---

spam@reippuert.dk (Morten Reippuert) writes:

> Så er jeg med. Her hos mig æder den hele tiden så meget den kan, selv
> når ingen vinduer er åbner spiser den mindst +20% og med etblot et par
> tabs spiser den +50% efter de _er_ indlæst og fortolket. Omniweb 4.1sp58
> lægger sig pænt ned på 0%.

Her ligger den fint paa 1.6% hvilket stadig er for meget da den ikke
laver noget synligt.

Efter at have aabnet et par tabs, er den oppe og ringe paa 70%. Det
er ret interessant, da jeg ike har set det før. Det var med
Javasoft.com. Efter at have skiftet til en 100% statisk side ligger
den paa cirka 5%. Hvad ligger der på de sider du har eksperimenteret
med?

> i Beta'erne kommer den kun op en gang i mellem - og jeg må indrømme at
> jeg er blevet lidt i tvivl om hvorvidt den /er/ gratis til ovennævnte
> grupper. Oplysningerne på ders website er i al fald uldne. Anyway, hvis
> de får javascript og CCS2 understøttelsen på plads, vil jeg nok ikke
> betænke mig for at købe en licens til de 19$ eller 29$.

Fint. Diversitet er vigtig.

> hvis det var 4.0 eller 4.1b2 du prøvede vil jeg anbefale dig den seneste
> sneaky peak i stedet

4.0.6. Så ny som det kommer.

Oh well... All software sucks, some sucks less than others though.
--
Thorbjørn Ravn Andersen
http://homepage.mac.com/ravn

---

Thorbjørn Ravn Andersen <ravn@mac.com> wrote:

> spam@reippuert.dk (Morten Reippuert) writes:
>
> > Så er jeg med. Her hos mig æder den hele tiden så meget den kan, selv
> > når ingen vinduer er åbner spiser den mindst +20% og med etblot et par
> > tabs spiser den +50% efter de _er_ indlæst og fortolket. Omniweb 4.1sp58
> > lægger sig pænt ned på 0%.
>
> Her ligger den fint paa 1.6% hvilket stadig er for meget da den ikke
> laver noget synligt.
>
> Efter at have aabnet et par tabs, er den oppe og ringe paa 70%. Det
> er ret interessant, da jeg ike har set det før. Det var med
> Javasoft.com. Efter at have skiftet til en 100% statisk side ligger
> den paa cirka 5%. Hvad ligger der på de sider du har eksperimenteret
> med?

Der også forskel her - En reklame i flash får den til at spise _al_
ledig CPU tid. En tom side (efter gentart af programmet) får den til at
spise +5%. Hvis vinduer har været åbne ligger den højere typisk på +20%
(såfremt ingen andre programmer har behov for CPU tid)

Pointen er at den gerne skulle helt ned på 0% når programmet ikke
udfører noget. dvs. ingen åbne vinduer, ingen åbne forbindelser og
vinduer med statisk indhold (uanset hvor mange der måtte være)

> 4.0.6. Så ny som det kommer.

Det er en gammel svend, siden den er blevet meget bedre til CSS, java og
javascript - stabilitet, hastighed og finpudsning af features er også
mærkbart forbedret.

--
Venlig hilsen Morten Reippuert Knudsen...

<icq:131382336>

---

In article <1f9ahhl.c4lv3l1tz62stN%spam@reippuert.dk>,
spam@reippuert.dk (Morten Reippuert) wrote:

> i Beta'erne kommer den kun op en gang i mellem - og jeg må indrømme at
> jeg er blevet lidt i tvivl om hvorvidt den /er/ gratis til ovennævnte
> grupper. Oplysningerne på ders website er i al fald uldne. Anyway, hvis
> de får javascript og CCS2 understøttelsen på plads, vil jeg nok ikke
> betænke mig for at købe en licens til de 19$ eller 29$.

Citat fra OmniGroups hjemmeside:

"OmniWeb 4 for Mac OS X can be used for free, but occasionally you might
get little flashes of guilt while you use it. If this overwhelms you,
why not buy a license at our web store?"

--
Mvh.
René Frej Nielsen

---

René Frej Nielsen <rfn@mac.com> wrote:

> Citat fra OmniGroups hjemmeside:
>
> "OmniWeb 4 for Mac OS X can be used for free, but occasionally you might
> get little flashes of guilt while you use it. If this overwhelms you,
> why not buy a license at our web store?"

så var min formodning ikke helt hen i vejret

--
mvh. Morten Reippuert Knudsen <icq:131382336>

Lejlighed søges i KBH Besides, if you can't get a decent
kernal panic or two in a month, what's the point of living?

---

In article <1f9acvb.18viidr1kkcwvfN%spam@reippuert.dk>,
spam@reippuert.dk (Morten Reippuert) wrote:

> Ja, det er irriterende, men fejlen ligger vist i Apples implementering
> af Internetconfig. Jeg oplever det hver gang jeg opgraderer til seneste
> sneakey peak af Omniweb (som er min fortrukne browser).

....og så er den på dansk

--
Mvh.
René Frej Nielsen

---

René Frej Nielsen <rfn@mac.com> wrote:

> ...og så er den på dansk

og hvem mon er ansvarlig for det?

både java og script understøttelsen bliver i øvrigt bedre og bedre for
hver version, det er efterhånden sjælden jeg støder på websider der ikke
virker i omniweb - CSS2 halter desværre stadig.

--
mvh. Morten Reippuert Knudsen <icq:131382336>

Lejlighed søges i KBH Besides, if you can't get a decent
kernal panic or two in a month, what's the point of living?

---

In article <1f9q6br.19k7vo31y5w4asN%spam@reippuert.dk>,
spam@reippuert.dk (Morten Reippuert) wrote:

> > ...og så er den på dansk
>
> og hvem mon er ansvarlig for det?

Tjaa...

> både java og script understøttelsen bliver i øvrigt bedre og bedre for
> hver version, det er efterhånden sjælden jeg støder på websider der ikke
> virker i omniweb - CSS2 halter desværre stadig.

Måske jeg skulle til at bruge OmniWeb lidt mere... Jeg prøvede dengang
der kun var 4.0.6, men der var simpelthen for mange af de sider jeg
normalt bruger, som ikke virkede ordentligt.

Jeg må med skam tilstå, at jeg stadig bruger IE 99% af tiden, da den
viser næsten alle sider korrekt.

--
Mvh.
René Frej Nielsen

---

René Frej Nielsen <rfn@mac.com> wrote:

> Måske jeg skulle til at bruge OmniWeb lidt mere... Jeg prøvede dengang
> der kun var 4.0.6, men der var simpelthen for mange af de sider jeg
> normalt bruger, som ikke virkede ordentligt.

4.0x var notorisk langsom og inkompatibel med 40% af www. Prøv 4.1 sp63

--
mvh. Morten Reippuert Knudsen <icq:131382336>

Lejlighed søges i KBH Besides, if you can't get a decent
kernal panic or two in a month, what's the point of living?

---

In article <1f9q8pr.8xt7y51mbae4nN%spam@reippuert.dk>,
spam@reippuert.dk (Morten Reippuert) wrote:

> René Frej Nielsen <rfn@mac.com> wrote:
>
> > Måske jeg skulle til at bruge OmniWeb lidt mere... Jeg prøvede dengang
> > der kun var 4.0.6, men der var simpelthen for mange af de sider jeg
> > normalt bruger, som ikke virkede ordentligt.
>
> 4.0x var notorisk langsom og inkompatibel med 40% af www. Prøv 4.1 sp63

Jeg prøver... af alle personer burde jeg da også bruge programmet!

Chimera browseren tegner ellers til at blive ret interessant. Den er
dælme hurtig!

--
Mvh.
René Frej Nielsen

---

René Frej Nielsen <rfn@mac.com> wrote:

> Jeg prøver... af alle personer burde jeg da også bruge programmet!
>
> Chimera browseren tegner ellers til at blive ret interessant. Den er
> dælme hurtig!

Det gælder alle mach-0 udgaverne af mozilla hvor selve motoroen kører i
BSD laget og brugerfladen i X, Carbon eller Cocoa. Release udaven er
desværre en CFM udgave dvs et rent Carbon program.

--
mvh. Morten Reippuert Knudsen <icq:131382336>

Lejlighed søges i KBH Besides, if you can't get a decent
kernal panic or two in a month, what's the point of living?

---

In article <1f9qawb.1nhe50rp6cvtsN%spam@reippuert.dk>,
spam@reippuert.dk (Morten Reippuert) wrote:

> Det gælder alle mach-0 udgaverne af mozilla hvor selve motoroen kører i
> BSD laget og brugerfladen i X, Carbon eller Cocoa. Release udaven er
> desværre en CFM udgave dvs et rent Carbon program.

Det tegner da ganske god, for jeg er lidt træt af, at browsere skal være
så tæskelangsomme på Mac OS (og især X).

--
Mvh.
René Frej Nielsen

---

René Frej Nielsen <rfn@mac.com> writes:

> Det tegner da ganske god, for jeg er lidt træt af, at browsere skal være
> så tæskelangsomme på Mac OS (og især X).

Mozilla er ikke specielt langsom, synes jeg.

Du har masser af RAM? Ellers så installer links (så er der heller
ikke de der langsomme billeder at vente på).

--
Thorbjørn Ravn Andersen
http://homepage.mac.com/ravn

---

In article <kklmcclx8d.fsf@mimer.null.dk>,
ravn@mac.com (Thorbjørn Ravn Andersen) wrote:

> René Frej Nielsen <rfn@mac.com> writes:
>
> > Det tegner da ganske god, for jeg er lidt træt af, at browsere skal være
> > så tæskelangsomme på Mac OS (og især X).
>
> Mozilla er ikke specielt langsom, synes jeg.

Prøv at sætte din Mac op ved siden af en PC'er med IE af nyere dato. Der
er pokkers til forskel efter min mening.

> Du har masser af RAM? Ellers så installer links (så er der heller
> ikke de der langsomme billeder at vente på).

Jeg har 576 MB RAM i Cuben, så det burde række til en gang surfning.

Øhh.. "links". Er det et eller andet smart Unix CLI halløj?

--
Mvh.
René Frej Nielsen

---

René Frej Nielsen <rfn@mac.com> writes:

> Prøv at sætte din Mac op ved siden af en PC'er med IE af nyere dato. Der
> er pokkers til forskel efter min mening.

Jeg synes ikke forskellen er paafaldende mellem PowerBooken og min 866
MHz dual Pentium III. Maaske mod en moderne Pentium IV eller en AMD.

> Jeg har 576 MB RAM i Cuben, så det burde række til en gang surfning.
>
> Øhh.. "links". Er det et eller andet smart Unix CLI halløj?

Sae'foelig. Ren tekst. Understoetter frames, og kan downloade i
baggrunden.

--
Thorbjørn Ravn Andersen
http://homepage.mac.com/ravn

---

Morten Reippuert <spam@reippuert.dk> wrote:

> Jeg synes at der er alt for mange Carbon programmer der stadig bruger
> type/creator.

Desværre, ja.

> > Mac OS X meget simple system er ganske godt og kræver ingen værktøjer og
> > meget bedre end windows ditto. Jeg har f.eks sat pdf dokumenter til at
> > åbne i preview som udgangspunkt og enkelte hyppigt frekventeret åbner i
> > Acrobrat Reader. Sådan er mine prefrencer. Andre kan have det anderledes,
> > så hvis jeg sender dem et pdf dokument har jeg ikke fastlagt hvilket
> > program der skal bruges - de har de selv.
>
> Precisely.

Nemmerlig!

> Jeg kan i øvrigt anbefale en kontextuel menu ved navn "Zingg!". Den
> tilføjer en "open with" menu i Finder.app svarende til "Open with
> Application" i info vinduet, men endnu mere anvendeligt.

Ja den er ganske genial!
--
Mvh Michael Tysk-Andersen

---

Michael Tysk-Andersen <mta@mac.com> wrote:

> > Precisely.
>
> Nemmerlig!

exactement!!


din tur...

--
Venlig hilsen Morten Reippuert Knudsen...

<icq:131382336>

---

Morten Reippuert <spam@reippuert.dk> wrote:

> Michael Tysk-Andersen <mta@mac.com> wrote:
>
> > > Precisely.
> >
> > Nemmerlig!
>
> exactement!!
>
>
> din tur...

Helt uenig!

Flere... ?

--
Thorkil Olesen,
Hanstholm.

---

In article <1f98uz0.1ipokeymio1tcN%mta@mac.com>,
mta@mac.com (Michael Tysk-Andersen) wrote:

> Morten Reippuert <spam@reippuert.dk> wrote:
>
> > mht. til metadata er MacOS X blevet mere nørdet, fordi Apple har valgt
> > at blande to forskellige metoder for håndtering af metadata, og endnu
> > værre: har undladt at udstede klare retningsliner om hvilken type der
> > _bør_ anvendes af udviklerne.
>
> Retningslinjerne er nu ganske klare nu. De var lidt vage under betaen og
> første udgave af Mac OS X. Apple anbefaler nu at bruge extensions og kun
> bruge type/creator som en bagudkompatibilitet til 9.x.

Hvis Mac OS X går hen og bliver som Windows på dette punkt, så vil jeg
og resten af den grafiske branche nok gå hen og blive kede af det.

Jeg synes nemlig det er totalt åndet, at alle .EPS filer skal låses til
én bestemt program i Windows. Det er temmeligt uheldigt, da der findes
Illustrator EPS filer og Photoshop EPS filer og de skal altså åbnes i
det rigtige program. På Mac'en er det ikke noget problem, da creator jo
er gemt i filen, men på Windows er man på herrens mark, da kun ét
program kan eje én extension.

Lad for guds skyld ikke Mac OS X blive lige så tumpet!

--
Mvh.
René Frej Nielsen

---

René Frej Nielsen <rfn@mac.com> wrote:

> Jeg synes nemlig det er totalt åndet, at alle .EPS filer skal låses til
> én bestemt program i Windows. Det er temmeligt uheldigt, da der findes
> Illustrator EPS filer og Photoshop EPS filer og de skal altså åbnes i
> det rigtige program. På Mac'en er det ikke noget problem, da creator jo
> er gemt i filen, men på Windows er man på herrens mark, da kun ét
> program kan eje én extension.

Det kan klares med en database - hvilket det rent faktisk er tilfældet i
Mac OS X.

Print en PDF fil med Preview.app. Vis info på filen i Resedit, filen har
ingen type/creator. Skift filens åbningsprogram i Finder.app til eks.
Acrobat Reader og vælg igen "vis info" i ResEdit, stadig ingen
type/creator

Denne fil vil fremover blive åbnet i Acrobat mens de øvrige PDF'er åbnes
i Preview,app. Jeg ved ikke om de seneste vindåse inkarnationer kan
noget lignende, men i Mac OS X fungerer det glimrende.

> Lad for guds skyld ikke Mac OS X blive lige så tumpet!

hæ, hæ - flamewar

--
Venlig hilsen Morten Reippuert Knudsen...

<icq:131382336>

---

In article <1f9a9qs.1hs8p3f1b1sfvtN%spam@reippuert.dk>,
spam@reippuert.dk (Morten Reippuert) wrote:

> Print en PDF fil med Preview.app. Vis info på filen i Resedit, filen har
> ingen type/creator. Skift filens åbningsprogram i Finder.app til eks.
> Acrobat Reader og vælg igen "vis info" i ResEdit, stadig ingen
> type/creator

Hvor gemmes disse oplysninger egentligt? Hvis det ligger gemt i nogle
filer på ens maskine, følger disse oplysninger så med, når man f.eks.
brænder filen ned på en CD?

Hvis det _ikke_ følger med, så er vi lige vidt, for så vil vi i
fremtiden få et hav af EPS-filer, som ikke hører til det "rigtige"
program.

--
Mvh.
René Frej Nielsen

---

René Frej Nielsen <rfn@mac.com> wrote:

> In article <1f9a9qs.1hs8p3f1b1sfvtN%spam@reippuert.dk>,
> spam@reippuert.dk (Morten Reippuert) wrote:
>
> > Print en PDF fil med Preview.app. Vis info på filen i Resedit, filen har
> > ingen type/creator. Skift filens åbningsprogram i Finder.app til eks.
> > Acrobat Reader og vælg igen "vis info" i ResEdit, stadig ingen
> > type/creator
>
> Hvor gemmes disse oplysninger egentligt? Hvis det ligger gemt i nogle
> filer på ens maskine, følger disse oplysninger så med, når man f.eks.
> brænder filen ned på en CD?

LS filerne i ~/Library/Preferences

> Hvis det _ikke_ følger med, så er vi lige vidt, for så vil vi i
> fremtiden få et hav af EPS-filer, som ikke hører til det "rigtige"
> program.

De følger ikke med (hvilket passer mig fint)

--
mvh. Morten Reippuert Knudsen <icq:131382336>

Lejlighed søges i KBH Besides, if you can't get a decent
kernal panic or two in a month, what's the point of living?

---

In article <1f9q6ga.1av6cb5re3dt7N%spam@reippuert.dk>,
spam@reippuert.dk (Morten Reippuert) wrote:

> > Hvis det _ikke_ følger med, så er vi lige vidt, for så vil vi i
> > fremtiden få et hav af EPS-filer, som ikke hører til det "rigtige"
> > program.
>
> De følger ikke med (hvilket passer mig fint)

Damn! Det er altså et kæmpe tilbageskridt efter min mening.

--
Mvh.
René Frej Nielsen

---

René Frej Nielsen <rfn@mac.com> wrote:

> > De følger ikke med (hvilket passer mig fint)
>
> Damn! Det er altså et kæmpe tilbageskridt efter min mening.

flameware?
--
mvh. Morten Reippuert Knudsen <icq:131382336>

Lejlighed søges i KBH Besides, if you can't get a decent
kernal panic or two in a month, what's the point of living?

---

In article <1f9q8na.1sx259ph62xt9N%spam@reippuert.dk>,
spam@reippuert.dk (Morten Reippuert) wrote:

> René Frej Nielsen <rfn@mac.com> wrote:
>
> > > De følger ikke med (hvilket passer mig fint)
> >
> > Damn! Det er altså et kæmpe tilbageskridt efter min mening.
>
> flameware?

Bah!

Jeg håber Apple finder på et eller andet smart inden for en overskuelig
fremtid.

--
Mvh.
René Frej Nielsen

---

jjj@cyrk.dk (Jesper Juellund Jensen) writes:

> Der er således tale om et mere avanceret system, end det kendes fra
> andre filsystemer, hvor der typisk ikke er resursegren, og hvor der er
> færre (og/eller andre) metaoplysninger.

Njah, de fleste andre moderne operativsystmer har implementeret en
n-grens filstruktur, dvs. man er ikke bundet til sølle to grene.

Sjovt nok er Windows NT et af disse systemer. Desværre er der så få
der bruger det, at virusforfatterene fandt ud af, at de kunne skjule
al deres kode i en ekstra gren, da antivirus programmerne kun scannede
den første.
--
Thomas Bjorn Andersen - tba@gen-v.net
+++ATH

---

in article 1f97ld1.148in151hydvqvN%jjj@cyrk.dk, Jesper Juellund Jensen at
jjj@cyrk.dk wrote on 17/03/02 21:48:

> Morten Reippuert skrev:
>
>> Både og type/creator er smartere end almindelige extensions, idet flere
>> filer af samme type ikke nødvendigvis mappes til samme program.
> Nemlig.
>
>> Ulempen ved Apples valg er at meta data gemmes i resucegrenen, som mildt
>> sagt er noget bøvl så snart filen flyttes til andre filsystemer.
> Well, det er vel principielt ikke helt korrekt (selv om effekten er den
> samme).
>
> Som jeg har forstået det, kan man sige, at der for et "gammeldags"
> Apple-arkiv er tre dele:
>
> 1) Data-grenen, der består af en lang sekvens af bytes.
>
> 2) Resurse-grenen, der består af en række "resurser".
>
> 3) Metaoplysninger, herunder navn, oprettelsestidspunkt, tidspunkt for
> seneste ændring, oprettelsesprogram, arkivtype, synlighed, låst/ikke
> låst osv.
>
> Der er således tale om et mere avanceret system, end det kendes fra
> andre filsystemer, hvor der typisk ikke er resursegren, og hvor der er
> færre (og/eller andre) metaoplysninger.
>
> Når det er "noget bøvl", at oplysninger om oprettelsesprogram og
> arkivtype ikke bibeholdes, når arkivet flyttes til andre filsystemer,
> skyldes det altså - som jeg forstår det - ikke disse systemers mangel på
> resursegren, men at der er færre metaoplysninger, hvilket ikke er helt
> det samme.

Metaoplysning kendes som FinderFlags, det var vist nok ved System 8.5 at
Apple udvidede antallet af flags fra 2 til 8.
--
Jesper
"Hvis alle slår en skid mod racisme Fredag lugter der af lort Lørdag."
Lillebror i DR TV