Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?
Forum>Software>Wählt man heutzutage für interne Boot-Festplatten lieber Journaled mit oder Journaled ohne Groß/Kleinschreibung

Wählt man heutzutage für interne Boot-Festplatten lieber Journaled mit oder Journaled ohne Groß/Kleinschreibung

fadenschein04.09.1512:51
Früher hiess es mal, man solle auf Groß/ Kleinschreibung verzichten.
Ist das immer noch so oder wählt man zwischenzeitlich lieber 'mit Groß-/ Kleinschreibung'?

Dank und Gruß
Fadenschein
0

Kommentare

Hannes Gnad
Hannes Gnad04.09.1512:53
So lassen wie es standardmäßig eingestellt ist.
0
mac_heibu04.09.1512:59
Unbedingt ohne Groß-/Kleinschreibung sofern man beispielsweise mit Adobe-Produkten arbeitet. Die laufen auf solchen Platten nämlich nicht.
0
fadenschein04.09.1513:01
Standardmäßig ist es gar nicht eingestellt. Es ist ja eine neue Festplatte.
Was wäre denn der Standard heutzutage?

Früher hiess es, die Option 'Gross-/ Kleinschreibung' könnte eher Probleme machen.
Man solle also eher darauf verzichten.
0
john
john04.09.1513:06
Standardmäßig ist es gar nicht eingestellt. Es ist ja eine neue Festplatte.
?
standardmässig bedeutet das, was eben der installationsassistent schon vorgewählt vorgibt.
und das dürfte eben ohne case sensitive sein.
was hat das mit dem alter der festplatte zu tun? oder überhaupt mit der festplatte?
„biete support. kostenlos, kompetent und freundlich. wähle zwei.“
0
fadenschein04.09.1513:17
@john
Na ja, es handelt sich im Dienstprogramm doch um ein Aufklappmenü mit 6 wählbaren Formaten.
Das Journaled ohne Groß-Kleindifferenzierung ist tatsächlich an erster Stelle.
Ich finde aber nicht, dass das der gesicherte Beleg ist, dass es sich um den 'Standard' handelt.

Und: mit dem Alter der Festplatte hat es gar nichts zu tun. Aber hätte ich hier einen fabrikmäßigen Mac rumstehen, könnte ich nachsehen, wie es dort formatiert ist und wüsste dann was Apple standardmäßig nimmt.

Lange Rede kurzer Sinn. Ich wähle ohne grosskleinschreibung.

Danke Euch
Fadenschein
0
sunni04.09.1513:37
Es ist der Quasi-Standard.
Die Festplatten neuer Macs sind immer in diesem Format formatiert.

Und, wie mac_heibu schon schrieb, führt es zu Problemen bei z.B. Photoshop CC 2015 , wenn ein Volume mit Groß-/Kleinschreibung formatiert ist.
0
Legoman
Legoman04.09.1513:43
Was genau heißt jetzt "ohne Groß- und Kleinschreibung"?
Werden nur noch kleine Buchstaben verwendet? Oder werden Groß- wie Kleinbuchstaben behandelt?

Probleme:
1. Ich habe auf meinem Windowsrechner 2 Dateien (meist Lieder) mit den Namen "Lied.mp3" und "lied.mp3". Beim Kopieren wird gemeckert - Datei wäre schon vorhanden. Meist unproblematisch, so findet man Doubletten.
Ähm oder war es umgekehrt? Von Mac dann auf Windows die Probleme? Bin grad nicht sicher...
2. Ich möchte gern aus optischen Gründen das Lied "Ich Geh Am Morgen In Den Wald.mp3" in "Ich geh am Morgen in den Wald.mp3" umbenennen. Geht einfach nicht! (Ich kann aber stattdessen erst irgendwo einen Buchstaben einfügen, dann nochmal umbenennen.)

Die vernünftige Bezeichnung der Dateien ist mir aus diversen Gründen wichtig. Ich überlasse die Sortierung nicht iTunes, ich mach das manuell - vor allem auch zur Verwendung auf verschiedenen Systemen.

So richtig hab ich es noch nicht geblickt. (20 Jahre Windows vs <1 Jahr Mac...)
0
john
john04.09.1513:45
@fadenschein

ich kapier nach wie vor nicht deine fragestellung.

du möchtest eine formatierte, interne bootfestplatte eines macs mit einem neuen frischen system neu bespielen. richtig?
dazu würdest von einem installationsmedium booten und den installations-assistenten vor dir haben.
selbiger fragt dich dann auf welchem volumen installiert werden soll. da wählst du dann eben diese formatierte leere festplatte und ab die post. also alles auf standard.
erst wenn du was änderst, wird es doch nicht mehr standard...
wozu also die frage?
Was genau heißt jetzt "ohne Groß- und Kleinschreibung"?
Werden nur noch kleine Buchstaben verwendet? Oder werden Groß- wie Kleinbuchstaben behandelt?
die englische bezeichnung drückt es vielleicht verständlicher aus: case sensitive

bedeutet, dass gross- und kleinschreibung (in pfaden und dateinamen) berücksichtigt werden.
ohne halt nicht.
„biete support. kostenlos, kompetent und freundlich. wähle zwei.“
0
Legoman
Legoman04.09.1514:05
"Ein Unterschied zwischen MS-Windows und Linux/Unix besteht darin, dass Windows bei Dateinamen nicht zwischen Groß- und Kleinschreibung unterscheidet, während Unix dies tut (zum Beispiel bezeichnen dort Haustuer.txt und hausTuer.txt unterschiedliche Dateien)."

Na jetzt hab ich es halbwegs verstanden. Alles unproblematisch, so lange man nicht zwischen verschiedenen Systemen springt. Aber da ich meine Musik mit Windows, Mac, Linux und im Autoradio (was auch immer das nutzt...) verwende, gibt es ab und an schon mal Probleme...

Also sollte man für den Mac weiterhin "Mac OS Extended (Journaled)" und nicht "Mac OS Extended (Groß-/Kleinschreibung und Journaled)" wählen, richtig?
0
john
john04.09.1514:12
Also sollte man für den Mac weiterhin "Mac OS Extended (Journaled)" und nicht "Mac OS Extended (Groß-/Kleinschreibung und Journaled)" wählen, richtig?
was per default bereits ausgewählt ist beim neuinstallieren. korrekt.
„biete support. kostenlos, kompetent und freundlich. wähle zwei.“
0
Legoman
Legoman04.09.1514:13
/thread

0
fadenschein04.09.1514:25
@john

Die eigentliche Frage ist längst beantwortet aber trotzdem nochmal zur Erläuterung meiner alten Fragestellung:

Ich hatte eine völlig unformatierte Festplatte, die ich formatieren wollte, um danach ein System aufzuspielen.

Mein Festplattendienstprogramm bot mir 5 Möglichkeiten und für mich war nicht ersichtlich, welche dieser 5 Möglichkeiten der 'Standard' ist.

Deswegen hatte ich gefragt.
0
sierkb04.09.1516:00
Hannes Gnad
So lassen wie es standardmäßig eingestellt ist.

Wenn ich es mir einfach machen will, gebe ich eine solche kurz angebundene Antwort. Nach dem Motto: "Nicht dran rühren, hamma bisher immer so gemacht. Passt scho."
Ich glaube, so einfach kann und sollte man sich das nicht machen, wenn man halbwegs auf der Höhe der Zeit und zukunftszugewand schauen und agieren will, denn ein "Passt scho" könnte sich in Zukunft durchaus als Bumerang und großer Problemherd erweisen oder schon in der Gegenwart, je nachdem, was man macht und machen will.

Die Eingangsfrage heißt: Wählt man heutzutage für interne Boot-Festplatten lieber Journaled mit oder Journaled ohne Groß/Kleinschreibung?
Mein Festplattendienstprogramm bot mir 5 Möglichkeiten und für mich war nicht ersichtlich, welche dieser 5 Möglichkeiten der 'Standard' ist.

Diese rückwärtsgewandte und der Historie geschuldete Standard-Einstellung WIRD sich in nicht allzu ferner Zukunft ändern. Unter Time Machine und iOS IST es bereits geändert, ist case sensitive (also: mit Berücksichtigung von Groß- und Kleinschreibung) exklusiver Standard und ohne Wahlmöglichkeit.
Z.B. legt Apple schon seit einiger Zeit den Entwicklern, die für OS X und iOS entwickeln, sehr nahe, diese vorgegeben Standard-Einstellung bei sich und fürs Entwickeln unbedingt zu ändern in Richtung case-sensitive. Aus gutem Grund.
Früher hiess es, die Option 'Gross-/ Kleinschreibung' könnte eher Probleme machen.
Man solle also eher darauf verzichten.

Früher. Heute ist der Trend und die Problemlage eher umgekehrt. Und der Zug rollt unter OS X eindeutig in die Richtung, wo sich das restliche Unix-Lager schon seit Jahren längst befindet: case sensitive (Rücksicht auf Groß- und Kleinschreibung). Unter Time Machine und iOS hat Apple diesen Schritt bereits vollzogen und diesen alten Zopf abgeschnitten, von Anfang an.

Und: Dritthersteller-Software, die mit case-sensitive Probleme hat, die kann man ggf., diese Möglichkeiten gibt es auch:
a) meiden
b) wenn unvermeidbar, dann wenigstens dem Hersteller in den Ohren liegen, dass er's ändert
c) eine neuere Version benutzen, die das Problem nicht mehr hat.

Und Apple hilft Entwicklern sogar dabei, seine Software auf case-sensitive (Rücksicht auf Groß- und Kleinschreibung) umzustellen, wenn sie das nicht schon ist, gibt einem Hilfestellung und Tipps dazu an die Hand.
0
fadenschein04.09.1518:43
@sierkb

Danke für diesen differenzierten Einwurf.
Schön v.a., wenn jemand die Frage liest ('heutzutage').
0
sierkb04.09.1518:52
Ergänzend zu und das von mir bereits obig Gesagte unterstreichend die Erläuterungen und Hinweise unter:

Apple: Technical Note TN2096: Debugging Case-Sensitivity Bugs in Applications
0
MikeMuc04.09.1519:40
Und noch einmal: Wenn du mit Adobeprogrammen arbeiten willst dann wähle "ohne Groß/Kleinschreibung". Software von Adobe mag es nicht wen "eindateiname" nicht mehr gleich "EinDateiName" ist. Und andere vielleicht auch nicht weil der Programmierer nachlässig war.

Solltest du aber auf ein Datesystem bestehen welche Groß und kleinschreibung berücksichtigt, dann wird bei dir hier im Forum in Zukunft immer die 1. Antwort lauten: Sollte dein Dateisystem Groß-/Kleinschreibung berücksichtigen dann kann das die Ursache an deinem Problem sein
0
sierkb04.09.1520:21
MikeMuc
Und noch einmal: Wenn du mit Adobeprogrammen arbeiten willst dann wähle "ohne Groß/Kleinschreibung". Software von Adobe mag es nicht wen "eindateiname" nicht mehr gleich "EinDateiName" ist.

Wenn. Womöglich. Nicht jeder benutzt (veraltete) Adobe Software oder Adobe Software überhaupt.
Und andere vielleicht auch nicht weil der Programmierer nachlässig war.

Doch! genau deshalb mögen die das nicht. WEIL deren Programmierer nachlässig waren. Und womöglich eben NICHT ausreichend getestet haben bzw. welber nicht diesem Rat gefolgt sind, auf case-senstitiv zu entwickeln. Auch Oracle ist das passiert mit deren MySQL. Erst, als ich denen den Hinweis gab., dass MySQL sich unter OSX nicht korrekt installiert bzw. nicht zum Laufen zu bringen ist, haben sie das geändert und sich entschuldigt mit einem "Uuups, da haben wir wohl nicht ausreichend getestet bzw. unsere Entwickler haben den Fehler gemacht, ihre Systeme eben unter der vorgegebenen Standardeinstellung case-insensitive laufen zu lassen statt unter case-sensitive, und dann fällt so ein Fehler einem Entwickler eben nicht auf bzw. rutscht durch."

Und bei Adobe wird's ganze genauso sein.

case-insensitive rührt noch aus alten Prä-Mac OS X-Zeiten her, als Classic Mac OS bis Version 9 noch angesagt war. Apple aber MacOS auf ein Unix-Fundament gestellt hat, und im gesamten Unix-Universum case-sensitive der Regelfall ist bzw. teilweise unabdingbar ist, damit es keine Probleme hagelt (bei modernen Versionsverwaltungssystemen wie SVN oder Git erst recht), macht Apple da jedoch einen Spagat zwischen alter Classic-Welt und neuer Unix-Welt.
Seit OS X 10.3 kann OS X case-sensitive. Das ist jetzt wie lange her? Wie lange schleppt HFS+ diese alte Krücke case-insensitive aus alten OS 7/OS 8/OS 9-Tagen mit sich herum?
Solltest du aber auf ein Datesystem bestehen welche Groß und kleinschreibung berücksichtigt, dann wird bei dir hier im Forum in Zukunft immer die 1. Antwort lauten: Sollte dein Dateisystem Groß-/Kleinschreibung berücksichtigen dann kann das die Ursache an deinem Problem sein

1. ist dieses Forum hier nicht der Nabel der Welt. Da kreucht und fleucht viel Unwissenheit und falsches Wissen und die Macht der Gewohnheit herum.
2. immer häufiger tritt der umgekehrtte Fall auf, dass eben Apples Standard-Einstellung case-insensitive zu Problemen führt, gerade im Austausch mit anderen Systemen und erst Recht bei Entwicklern, zum Beispiel beim Ein- und Auschecken von Dateien in Git oder SVN. Oder beim simplen Austausch und Handhaben von Dateien übers Netzwerk. Unlängst erst hat sich niemand geringerer als Linus Torvalds öffentlich daürber sehr abfällig geäußert, was für einen Scheiß Apple da mit seinem HFS+ fabriziert habe und es sei das "worst file system ever". Unter anderem ein Punkt: diese bekackte Voreinstellung case-insensitive, weil das nur zu horrenden Problemen führe im Handhaben und Austausch von Dateien darunter, grad' beim verteilten Entwicklen.

Und wenn Adobe es bis zum heutigen Tag immer noch nicht hinbekommen haben sollte, seine Software so zu bauen, dass sie das kann, dann ist das eigentlich ein Grund mehr, Adobe Software zu meiden wo man nur kann. Und wenn man sie nicht meiden kann, dann Adobe so lange in den Ohren zu liegen, bis sie es endlich hinbekommen haben. Apple gibt dazu sogar Hilfestellung. Und das nicht erst seit gestern.

Man muss keine Adobe Software verwenden. Man kann auf sie auch verzichten. In der Eingangsfrage taucht diese Frage gar nicht auf. Vielleicht benutzt der Fragesteller ja gar keine Adobe Software, dann hat er diese potentielle oder tatsächliche Problemquelle schon mal gar nicht erst im Haus.

Vielleicht entwickelt er ja sogar für OS X und/oder iOS oder Cross-Plattform oder fürs Web. Oder tauscht sich eben zwischen verschiedenen Plattformen aus bzw. hat Sharing Volumes mit einem anderen Unix/Linux. Dann könnte er eigentlich, ohne dass er größere Gefahr laufen müsste, bedenkenlos auf case-sensitive wechseln und hier mit dem Zug der Zeit gehen und das Dateisystem wenigstens an dieser Stelle in der Neuzeit angekommen sein haben.

Ich z.B. formatiere mein OS X seit Jahren abseits der vorgegebenen Standardeinstellung case-sensitive und habe (bis auf einmal in Bezug auf Oracles MySQL, das habe ich dann Oracle gemeldet gehabt, einen Bug draus gemacht, Oracle hat's behoben, und seitdem läuft's) null Probleme damit, egal, welche Dritthersteller-Software ich verwende – ganz im Gegenteil. Ich benutze allerdings auch keine Adobe Software, meide diese Firma wo es nur irgend geht (gleiches in Bezug auf Microsoft). Adobe ist hinlänglich bekannt dafür, teilweise miserable Software-Qualität abzuliefern. Wer auf Adobe Software verzichten kann bzw. verzichtet, hat da also ein paar Sorgen weniger. Nicht jeder braucht, nicht jeder verwendet deren Software. Und auch da: auch Adobe hat einen Support, der ist auch dazu da, Fragen und Probleme aufzunehmen, die deren Produkte verbessern. Das Problem ist nicht neu, und so langsam müsste es auch Adobe gebacken kriegen, auch diesbzgl. in der Neuzeit anzukommen. OS 9 ist lange, lange her.
0
fabisworld
fabisworld04.09.1521:04
sierkb
[…] Ich z.B. formatiere mein OS X seit Jahren abseits der vorgegebenen Standardeinstellung case-sensitive […]

sierkb
Habe ich das richtig verstanden, dass Du also die im u.a. Screenshot dargestellte Variante meinst und empfiehlst, zumindest wenn man keine Adobe- oder Microsoft-Programme einsetzt ?
0
Arne 204.09.1521:45
Wenn die Software sauber programmiert ist, läuft sie auf beiden Dateisystemen. Bei unsauber programmierten Programmen, überwiegen wohl die, die nur auf dem default Dateisystem laufen -gerade bei älteren Programmen, die nur noch notdürftig gepflegt werden.

Einen echten Vorteil bietet dir das case sensitiv Filesystem aktuell nur, wenn du regelmäßig Dateien/Verzeichnisse mit anderen Rechnern abgleichst, die zwischen Groß- und Kleinschreibung unterscheiden und die User das auch tatsächlich nutzen.
0
sierkb04.09.1522:02
fabisworld
sierkb
Habe ich das richtig verstanden, dass Du also die im u.a. Screenshot dargestellte Variante meinst und empfiehlst, zumindest wenn man keine Adobe- oder Microsoft-Programme einsetzt ?

Du hast mich nur teilweise richtig verstanden. Eine Empfehlung habe ich nicht ausgesprochen. Ich habe lediglich gesagt, dass man gewisse Aussagen so gesichert, wie oben getan worden ist, so nicht pauschalisiert tun kann und dass es sicher auf den Einzelfall drauf ankommt, was man genau macht und was man für eine Software- und Netzwerkumgebung vor sich liegen hat.

Und dass zumindest ich mit genau der Einstellung, die Du in Deinem Screenshot meinst, nämlich Mac OS Extended (Groß-/Kleinschreibung und Journaled) Format meiner Boot- und System-Partition seit längerem sehr gut und ohne irgendwelche Probleme und Seiteneffekte fahre. Und ich bin da wohl auch nicht der Einzige, der damit keine Probleme hat.

Zudem empfiehlt ausgerechnet Apple genau diese von Dir abfotografierte Einstellung in obig von mir genannten Dokument auch höchst selbst grundsätzlich für alle Entwickler, die für OS X und/oder iOS entwickeln – abweichend von der Standard-Voreinstellung und rät den Entwicklern eindringlich davon ab, es bei der vorgegebenen Standardeinstellung zu belassen und führt sogar an, dass das Belassen der Standardeinstellung zu Fehlern und Folgefehlern beim Entwicklen und bei der zu entwickelnden Software führen könnte (wie an obigem Beispiel Oracle trefflich zu bemerken gewesen ist).

Und viele Unix-Nutzer und Entwickler unter Unix, die stellen das auch um für sich bzw. nutzen das, wenn sie unter OS X unterwegs sind. Um weniger Probleme zu haben, um in der Unix- und Cross-Plattform-Welt einheitlich zu fahren und sich auch diesbzgl. unter OS X heimisch zu fühlen, wie sie es unter Unix/Linux gewohnt sind.

Und den Namen Microsoft habe ich lediglich in dem Zusammenhang genannt, dass ich deren Software (außer zum Testen in einer VM) ebenfalls meide, genau wie Adobes Software, wo es nur geht. Mit dem vorliegenden Fall hat das nichts zu tun bzw. ich weiß nicht, ob Microsofts Software den Schuss ebenfalls noch nicht gehört hat und da noch Probleme mit hat oder nicht, da kann ich keine Aussage zu machen, weil ich es nicht weiß.

Wer evtl. auch den Schuss noch nicht gehört hat, genau wie Adobe, das könnte evtl. Steam sein, zumindest hatten die wohl mal Probleme mit case sensitive, setzen das voraus (warum auch immer). Ob sie das inzwischen behoben und geändert haben: keine Ahnung.

Also Adobe Software und Steam Software, wo man mal genauer schauen und gucken sollte, ob die das inzwischen hinbekommen haben oder nicht. Welcher Hersteller noch?

Und wenn man keinen von denen benutzt, keinerlei Adobe Software, keinerlei Steam Software (was zu prüfen wäre, ob die immer noch damit ein Problem hat) auf seinem System hat? Und zufällig Software installiert hat, die eben in der Neuzeit angekommen ist und die, wie es sich gehört, case-sensitive-ready ist? Wenn man das weiß und ausprobiert hat und es da zu keinen Problemen im Betrieb kommt, dann spricht eigentlich nichts gegen case-sensitive. So soll es sein, so spricht die gesamte restliche Unix-Welt, und in die Richtung wird es gehen (siehe Tme Machine, siehe iOS).
0
sierkb04.09.1522:11
Apple, Technical Note TN2096
Technical Note TN2096
Debugging Case-Sensitivity Bugs in Applications


Case-sensitive boot volumes are becoming more prevalent with the advent of case-sensitive HFS Plus, and the file system in iPhone OS is also case sensitive. Unfortunately, many applications do not work correctly on case-sensitive volumes. This technote describes techniques for tracking down case-sensitivity bugs and fixing them. It also provides suggestions for testing techniques to prevent new case sensitivity bugs from appearing in the future. This technote is intended for both Mac OS X and iPhone developers.

Introduction

Beginning in Mac OS X version 10.5, (or 10.4 Server), Mac OS X supports the case-sensitive HFS Plus volume format. Because case-sensitive HFS Plus performance is comparable to that of standard HFS Plus, case-sensitive boot volumes are becoming much more common. Time Machine and iPhone OS also use case-sensitive volumes, adding further momentum to this trend. With this rise in popularity, it no longer makes sense to assume that only a handful of your application's users will use case-sensitive volumes.

Case sensitivity brings to light many latent bugs in existing software caused by developers using capital letters to access files whose names contain lower-case letters and vice-versa. Case sensitivity also brings with it a number of challenges for application developers, who must now make certain that their applications work correctly in two environments—case-sensitive HFS Plus and case-insensitive HFS Plus. This technote shows you how to fix these problems and tackle these new challenges.
[…]
Avoiding Case Sensitivity Problems in the Future

You should always build and test iPhone applications using a case-sensitive volume. Using a case-insensitive file system can lead to new bugs showing up when you move from the simulator to an actual iPhone. And because iPhone OS uses a case-sensitive file system exclusively, there is no benefit to testing iPhone applications on case-insensitive volumes at all.

When developing applications for Mac OS X, the easiest way to avoid case sensitivity problems is simple: do most of your testing on case-sensitive HFS Plus. If you always test on case-sensitive HFS Plus, unless you go out of your way to break things (intentionally creating temporary files that have the same name as open documents, but with different case, for example), the only problem you are likely to encounter is having two different files in your project with the same name and different case.
Quelle: Apple Mac Developer Library: Technical Note TN2096 , letzte Änderung an dem Dokument: 2010-05-19
0
sierkb04.09.1522:19
,
,
0
Arne 204.09.1522:36
Ich traue mich mal zu wetten, dass unter denen, die nicht genau wissen, welches Dateisystem für sie das richtige System ist, mehr Steam/MS Office/Adobe Nutzer sind, als iOS Developer
0
sierkb04.09.1522:45
Arne R:

Für WEN entwickeln denn die iOS- und OSX-Entwickler denn bzw. sollen entwickeln, wer ist deren Zielpublikum? Sie selber doch wohl nicht, oder? Und dieses Zielpublikum, diese Zielplattform im Blick habend, dafür sollen die Entwickler auf case-sensitive entwickeln! Weil dort case-sensitive von Apple gesehen werden will bzw. dort nix anderes da ist und bei iOS sogar gar nix anderes mehr zugelassen ist als genau das. Und nicht das bequeme Festhalten an alten Kamellen aus grauer Vorzeit (was case-insensitive leider nun mal eben ist). OS X befindet sich in der Unix-Welt. Seit 15 Jahren. Und in der Unix-Welt spricht man case-sensitive – egal, ob man Entwickler ist oder nicht.
0
fadenschein04.09.1522:50
@alle

Wow - ein kleines Rascheln löst ein Lawine aus.
0
sierkb04.09.1522:54
Linus Torvads
Quite frankly, HFS+ is probably the worst filesystem ever. Christ what shit it is. NTFS used to have similar issues with canonicalizing utf8 (ie using non-canonical representations of slashes etc). I think they at least fixed them. The OS X problems seem to be fundamental.

The true horrors of HFS+ are not in how it’s not a great filesystem, but in how it’s actively designed to be a bad filesystem by people who thought they had good ideas.

The case insensitivity is just a horribly bad idea, and Apple could have pushed fixing it. They didn’t. Instead, they doubled down on a bad idea, and actively extended it – very very badly – to unicode. And it’s not even UTF-8, it’s UCS2 I think.

Ok, so NTFS did some of the same. But apple really took it to the next level with HFS+.

There’s some excuse for case insensitivity in a legacy model (“We didn’t know better”). But people who think unicode equivalency comparisons are a good idea in a filesystem shouldn’t be allowed to play in that space. Give them some paste, and let them sit in a corner eating it. They’ll be happy, and they won’t be messing up your system.

And then picking NFD normalization – and making it visible, and actively converting correct unicode into that absolutely horrible format, that’s just inexcusable. Even the people who think normalization is a good thing admit that NFD is a bad format, and certainly not for data exchange. It’s not even “paste-eater” quality thinking. It’s actually actively corrupting user data. By design. Christ.

And Apple let these monkeys work on their filesystem? Seriously?

There are lots of good reasons to not move to ZFS (cough-Oracle-cough), but they could have pushed people to case-sensitive HFS+, which would have then made it much easier to (in the long run) migrate to anything else saner. But no. There is a case sensitive option, but Apple actively hides it and doesn’t support it.

The stupidity, it burns.

So you had all these people who made really bad decisions and actively coded for them. And I find that kind of “we actively implement shit” much more distasteful than just the “ok, we don’t implement a lot of clever things” that John complained about.
Quelle: ,
So you had all these people who made really bad decisions and actively coded for them.

Zeit, das endlich mal zu durchbrechen. Und case-sensitive zu benutzen und wo es nur geht, zu promoten und dafür zu werben. Als Entwickler. Als Nutzer. Und als Betriebssystem-Anbieter das zur neuen Standardvorgabe zu machen (Anzeichen in die Richtung, siehe Apples Dokument oben), damit sich endlich auch die letzten Entwickler, die den Schuss immer noch nicht gehört haben, endlich danach richten und sich nicht auf der Standard-Vorgabe ausruhen, die sie wiederum dazu verleitet, Shit zu schreiben.
0
dom_beta04.09.1523:14
sierkb
Zeit, das endlich mal zu durchbrechen. Und case-sensitive zu benutzen und wo es nur geht

Echt?!

Sorry, dann wechsel ich freiwillig auf Windows zurück, wo es diesen case sensitiven Krams nicht gibt.
„...“
0
dreyfus04.09.1523:27
Es sind nicht nur MS und Adobe, etliche von Windows portierte Anwendungen haben damit so ihre Probleme. Regulären Anwendern kann man das echt nicht empfehlen. Selbst wenn alle derzeitigen Anwendungen es hinkriegen, ist nicht gesagt, dass man nicht später eine installiert, die das Problem hat. Und der IT Abteilung erklären, dass man leider kein Word oder Excel nutzen kann, weil man leider seine Platte "falsch" formatiert hat, ist auch nicht.

Weit über 95% der Rechner und SANs auf Erden (und ca. 100% der externen Laufwerke und Speicherkarten) laufen ohne Unterscheidung von Groß- und Kleinschreibung. Solange MS nicht auf diesen Zug aufspringt, hat auch Apple keine Chance das durchzusetzen. Leider setzt sich nicht immer das Bessere oder Logischere durch.
0
Arne 204.09.1523:32
@sierkb

Das mag ja sein, dass die für mich entwickeln. Aber es ist doch mein Vorrecht als Nutzer zu entscheiden, was für MICH die beste Alternative ist. Und, da ich mit Adobe Produkten arbeite, ist das nun mal das default Filesystem. 100% Adobe-Kompatibilität brauche ich halt heute, nicht in 6 Monaten oder noch länger...
0
sierkb04.09.1523:47
Arne R.
@sierkb

Aber es ist doch mein Vorrecht als Nutzer zu entscheiden, was für MICH die beste Alternative ist.

Eben. Und genau deshalb kann man eben nicht eine so kurze, angebundene Empfehlung geben, wie sie Hannes Gnad gegeben hat. Denn ein Entwickler oder auch nur Nutzer, der unter Unix arbeitet oder arbeiten muss, der wird diese Frage wahrscheinlich anders für sich entscheiden, und der wird sich womöglich für case-sensitive entscheiden. So, wie es unter Unix sowieso üblich ist. Und so, wie es Apple seinen Entwicklern auch empfiehlt und so, wie es Apple in der Zukunft mit gewisser Wahrscheinlichkeit auch dem normalen Nutzer empfehlen und voreinstellen wird (iOS macht's vor, Time Machine auch).
Und, da ich mit Adobe Produkten arbeite

Und ich zum beispiel nicht. Und andere womöglich auch nicht. Also existiert da diese Problemquelle schon mal gar nicht, damit muss sich dann nicht befasst werden. Ich kann, davon völlig unbelastet, OS X als Unix verwenden, muss auf die Fehler und Probleme von Adobe Software keinerlei Rücksicht nehmen im alltäglichen Gebrauch, weil ich sie nicht nutze. Und es gibt durchaus einige Nutzer, die genauso denken und handeln können, weil sie derlei Software, die Probleme bereiten kann, gar nicht in Gebrauch haben, und für die beantwortet sich die im Thread-Titel gestellte Frage eben anders und viel freier und um ein paar Probleme ärmer als so, wie hier zunächst die Antworten gegeben worden sind.

[/quote]100% Adobe-Kompatibilität brauche ich halt heute, nicht in 6 Monaten oder noch länger...
[/quote]

Und ich zum Beispiel nicht. Und andere, die deren Software nicht benutzen auch nicht. Wobei da noch die Frage zu stellen wäre: welche Version der betreffenden Software denn überhaupt, womöglich hat eine neuere Version das Problem ja gar nicht mehr, und sie ist auf case-sensitive eingestellt?
0
geka04.09.1523:50
echt genial )))

Die Fragestellung ist eindeutig, die Antworten verlieren sich teilweise in geradezu absurder Weise in kaum einschätzbarem Geschwafel, oder sind nicht weniger unbefriedigend, überkurz angebunden.

Wo kann man am Mac etwa "case sensitiven" einstellen?
0
Weia
Weia04.09.1523:57
mac_heibu
Unbedingt ohne Groß-/Kleinschreibung sofern man beispielsweise mit Adobe-Produkten arbeitet. Die laufen auf solchen Platten nämlich nicht.
Das hast Du jetzt durcheinandergebracht. Korrekt heißt es:

Auf keinen Fall mit Produkten wie beispielsweise Adobe-Produkten arbeiten, deren Programmierer dermaßen brain-dead sind, dass sie nicht einmal Groß-/Kleinschreibungsfehler vermeiden können. Die laufen auf solchen Platten nämlich nicht.

Ich habe OS X seit Version 10.3 auf HFS+ Case-Sensitive laufen (vorher habe ich UFS verwendet, das auch case-sensitive war). Ich weigere mich einfach, Software zu akzeptieren, die nicht einmal in der Lage ist, den minimalen Qualitätsstandard einzuhalten, Kapitalisierungsfehler in den im Quellcode referenzierten Dateien zu vermeiden. Das ist Ausdruck einer Art von geistiger Trägheit, die ich verabscheue.

In der Tat hatte ich über die Jahre mehrfach Probleme mit Software (bezeichnenderweise fast immer von großen Softwarehäusern – man riecht förmlich den Schweiß der Sweatshops in Indien …). Ich habe jedesmal freundlich an den Support geschrieben, das Problem erklärt und angeboten, bei der Lösung zu helfen. In ca. ¾ der Fälle hat das geklappt. In den anderen Fällen habe ich mein Geld zurückverlangt und auch immer bekommen, teils allerdings erst nach Einschalten eines Anwalts.

Eine einzige Firma weltweit weigert sich, das Problem als Problem anzuerkennen und ihre Rechtschreibfehler im Quellcode zu beseitigen (mehr ist es ja nicht) und behandelt die Angelegenheit stattdessen als „Systemvoraussetzung“, und das ist Adobe. Stattdessen überprüft der Installer extra das Dateisystem und weigert sich, den Adobe-Mist zu installieren, wenn er HFS+ Case-Sensitive antrifft (Lightroom, Adobe Reader und Flash ausgenommen). Wann verschwindet diese unsägliche Firma endlich in dem großen Schlund, in den sie gehört?

Von Adobe abgesehen ist HFS+ Case-Sensitive in jüngerer Zeit meiner Erfahrung nach (ich installiere und teste sehr viele Software) eigentlich kein Problem mehr (von Dictate Version 3 abgesehen – aber auch Nuance konnte ich „überreden“ ).
„Not every story must end with a battle (Ophelia, in der umwerfend guten feministischen Adaption des Hamlet-Stoffes in dem Film „Ophelia“)“
0
sierkb05.09.1500:00
Weia:

+1
0
dom_beta05.09.1500:04
ähm, ja, schän für euch.

Mich persönlich nervt es, wenn

Brief an Tante Erika.docx

eine andere Datei ist als

brief an Tante Erika.docx
„...“
0
Weia
Weia05.09.1500:10
dom_beta
Mich persönlich nervt es, wenn

Brief an Tante Erika.docx

eine andere Datei ist als

brief an Tante Erika.docx
Aber „brief“ wäre schlicht ein Rechtschreibfehler …

Und natürlich ist schrei.txt semantisch etwas anderes als Schrei.txt – das eine Dokument trägt ein Verb in Befehlsform als Titel, das andere ein Substantiv. Deutsch ist eine case-sensitive Sprache …

PS: Warum stört Dich dann nicht, dass Brief an Tante Erika.docx eine andere Datei ist als Briehf an Tante Erika.docx und als Brief an Tante Erica.docx?
„Not every story must end with a battle (Ophelia, in der umwerfend guten feministischen Adaption des Hamlet-Stoffes in dem Film „Ophelia“)“
0
sierkb05.09.1500:13
dom_beta
Mich persönlich nervt es, wenn

Brief an Tante Erika.docx

eine andere Datei ist als

brief an Tante Erika.docx

Warum nervt es Dich? Nur, weil Du so groß geworden bist und es nicht anders kennst und es für Dich zur Gewohnheit geworden ist?

Es sind nun mal eben zwei verschiedene Dateien. Blau ist nun mal eine andere Farbe als grün. Bei der Dateigröße möchtest Du auch gerne die korrekte Größe angezeigt haben und nicht "Pi mal Daumen" oder lediglich "klein – mittel – groß". Nur weil man früher aus reiner Platz- und Speichernot Platz sparen musste und Dateinamen künstlich schrumpfen und das Dateisystem entsprechend stricken musste, heißt das noch lange nicht, dass das generell und auf Dauer eine gute und richtige Entscheidung war, die zudem auf Ewigkeiten Bestand haben muss und auf Ewigkeit mit so einer Krücke auch problemfrei umgegangen werden kann. Irgendwann überwiegen die Probleme mit dem Festhalten an so einer alten Krücke (die nicht selten mal nur als Not- oder Übergangslösung gedacht war). Siehe auch Beispiel 8+3-Dateinamen versus lange Dateinamen.

Weia:

+1
0
Weia
Weia05.09.1500:23
geka
Wo kann man am Mac etwa "case sensitiven" einstellen?
Im Festplattendienstprogramm beim Formatieren der Festplatte.

Beim Installieren von OS X kannst Du ziemlich am Beginn des Installationsvorgangs selbigen pausieren und aus der Menüleiste heraus das Festplattendienstprogramm starten, um anzugeben, wie Deine Festplatte formatiert werden soll.
„Not every story must end with a battle (Ophelia, in der umwerfend guten feministischen Adaption des Hamlet-Stoffes in dem Film „Ophelia“)“
0
Weia
Weia05.09.1500:29
Übrigens: Microsoft-Software hatte früher mal Probleme, aber schon seit geraumer Zeit arbeiten die aktuellen Versionen aller Microsoft-Produkte für OS X tadellos auf HFS+ Case-Sensitive.
„Not every story must end with a battle (Ophelia, in der umwerfend guten feministischen Adaption des Hamlet-Stoffes in dem Film „Ophelia“)“
0
Weia
Weia05.09.1500:32
Ein Problemkind habe ich auch noch vergessen: X-Rites i1Profiler (die Hilfe-Dateien werden nicht angezeigt, sonst geht’s).
„Not every story must end with a battle (Ophelia, in der umwerfend guten feministischen Adaption des Hamlet-Stoffes in dem Film „Ophelia“)“
0
MikeMuc05.09.1500:36
Ach Leute, formatiert doch was ihr wollt. Es kann halt nicht jeder wie Weia einen Bogen um Adobeprodukte machen. Oder immer die neueste Software nutzen die vielleicht mit der Unterscheidung klar kommt. Und sierkbs Theorie ist schön und gut, aber er scheint den Unterschied zu Praxis nicht zu kennen. Ich werde mir als Anwender nicht die Unterscheidung ans Bein binden den ich habe keinen Bock drauf nicht mit dem Problem rumzuschlagen. Ich brauch was was funktioniert. Nur dann kann ich arbeiten. Und daher bleibe ich bei meiner Empfehlung auf die Unterscheidung zu verzichten.
Sollte übrigends ein Programm eines Entwickler aufgrund der Tatsache das er die Unterscheidung braucht bei 90% der Anwender nicht laufen weil deren Dateisystem das nicht unterscheidet, dan taugt das nix, auch wenn es noch so sehr nach Sierkbs Links und Apples Empfehlungen geschrieben wurde. Wenn es irgendwo deshalb nicht läuft dann ab in die Tonne damit
0
dreyfus05.09.1500:36
Weia
Übrigens: Microsoft-Software hatte früher mal Probleme, aber schon seit geraumer Zeit arbeiten die aktuellen Versionen aller Microsoft-Produkte für OS X tadellos auf HFS+ Case-Sensitive.

Ja und nein. "Ja" auf dem eigenen Rechner, "Nein" wenn es bspw. um betriebliche Office 365 Cloud Storage, Sharepoint oder Backup-Lösungen geht... von zwei Dateien mit vermeintlich identischem Namen wird da maximal eine gespeichert / gesichert. Völlig untragbar.
0
sierkb05.09.1500:52
MikeMuc
Ach Leute, formatiert doch was ihr wollt. Es kann halt nicht jeder wie Weia einen Bogen um Adobeprodukte machen. Oder immer die neueste Software nutzen die vielleicht mit der Unterscheidung klar kommt. Und sierkbs Theorie ist schön und gut, aber er scheint den Unterschied zu Praxis nicht zu kennen.

Du scheinst nicht gelesen zu haben, was Apple höchst selbst seit Jahren empfiehlt. Und bei iOS von Grund auf konsequent anders macht. Und bei Tim Machine auch. DAS ist AUCH Praxis!
Und wenn man sich eben nicht dran hält und meint, wir hätten immer noch die 80er und 90er Jahre, so wie das Adobe anscheinend meint, dann kommen solche Problembaustellen eben bei heraus, über die wir hier reden. Und wer diese Software halt nicht nutzt, nicht nutzen muss, der hat eben diese Problembaustellen NICHT. OS X kennt seit OS X 10.3 case-sensitive, und seit 10.5 ist es selber so gebaut, dass es sich selber auch daran hält mit seinen eigenen Dateien. Das heißt im Klartext: das Betriebssystem selber kann das schon längst udn das seit langen Jahren. Und viele, viele Dritt-Software kann das inzwischen auch. Bis auf ganz wenige und immer weniger werdende Ausreißer, und dazu gehört eben offenbar Adobe. Alle anderen können das.
Ich werde mir als Anwender nicht die Unterscheidung ans Bein binden den ich habe keinen Bock drauf nicht mit dem Problem rumzuschlagen.

Du wirst es spätestens dann machen, wenn Apple seine diesbzgl. Standardvorgabe in diese Richtung ändert. Das kann morgen schon sein. Wenn nicht bei 10.11, dann bei 10.12. iOS ist schon. Time Machine Backups sind auch schon. Du benutzt es bereits.
Ich brauch was was funktioniert.

Ich auch. Und deshalb benutze ich zum Beispiel case-sensitive. Weil für mich die Unterscheidung in Groß- und Kleinschreibung essentiell wichtig ist (im Austausch und Zusammenspiel mit anderen Unices erst recht). Sonst gibt's Probleme, erst recht im Zusammenspiel mit anderen. So einen alten Schiet und Laxheiten wie auf so eine Unterscheidung in Groß- und Kleinschreibung verzichten zu können, kann ich nicht gebrauchen, damit handele ich mir nur Probleme ein. Klare Dateinamen, eineindeutig unterscheidbar. Nix Zusammengebasteltes und an altem Klebendes wie das leider imemr noch die Standardeinstellung vorgibt.
Nur dann kann ich arbeiten. Und daher bleibe ich bei meiner Empfehlung auf die Unterscheidung zu verzichten.

Empfehlung für WEN? Für manchen Entwickler ist das KEINE Empfehlung. Für iOS- und OSX-Entwickler erst recht nicht. Apple höchstselbst empfiehlt was anderes als Du für diese Klientel.
Sollte übrigends ein Programm eines Entwickler aufgrund der Tatsache das er die Unterscheidung braucht bei 90% der Anwender nicht laufen weil deren Dateisystem das nicht unterscheidet, dan taugt das nix, auch wenn es noch so sehr nach Sierkbs Links und Apples Empfehlungen geschrieben wurde.


Es gibt inzwischen eigentlich zunehmend mehr Probleme im Umgang mit case-insensitive statt im Umgang ohne. Unter anderme deshalb auch Apples Support-Dokument an die Entwickler. Um diese verbliebenen Baustellen in Dritt-Software endlich auszumerzen.
Wenn es irgendwo deshalb nicht läuft dann ab in die Tonne damit

Oracles MySQL lief unter OSX nicht. Weil deren Entwickler case-sensitive NICHT auf dem Schirm hatten und es bis dahin nicht gewohnt waren, drauf zu achten (was Apples Standard-Einstellung leider begünstigt, dass man da nicht drauf achtet und eben nachlässig ist offenbar). Wer ist Schuld dran gewesen und warum?

Nochmal: iOS IST bereits case-sensitive. Ausschließlich. Time Machine ebenfalls. Und OS X wird folgen. Darauf kannste Gift nehmen. Unter anderem, weil's ein Unix ist. Finde Dich damit ab, dass Apple diesen Schritt 1999/2000 gemacht hat und seitdem ein Unix/UNIX® ist. Wo eben diese Regeln gelten und diese Freiheiten eben vorhanden sind. Die alten Mac OS Classic- und DOS-Zeiten mit ihren jeweiligen Eigenarten und Beschränkungen sind lange lange vorbei. Zeit, das mal langsam zu akzeptieren und damit auch entspechend umzugehen und nach vorne zu schauen.
0
Weia
Weia05.09.1500:54
MikeMuc
Ich werde mir als Anwender nicht die Unterscheidung ans Bein binden den ich habe keinen Bock drauf nicht mit dem Problem rumzuschlagen. Ich brauch was was funktioniert. Nur dann kann ich arbeiten.
Ja, klar ist das ausschlaggebend. Aber was funktioniert, hängt eben von Deiner Arbeit ab.

Ich betreue z.B. eine umfangreiche Website, die jeweils deutsche und englische Seiten zu einem Thema hat.

U.a. gibt es da – auf derselben Hierarchieebene – deutsche und englische Seiten zu Jahreszeiten.

Deutsch: Fruehling.html Sommer.html Herbst.html Winter.html
Englisch: spring.html summer.html autumn.html winter.html

Du siehst das Problem mit HFS+ Case-Insensitive bei der 4. Jahreszeit? (Auf einem Linux- oder FreeBSD-Webserver ist das Problem natürlich keins …)
Sollte übrigends ein Programm eines Entwickler aufgrund der Tatsache das er die Unterscheidung braucht bei 90% der Anwender nicht laufen weil deren Dateisystem das nicht unterscheidet, dan taugt das nix, auch wenn es noch so sehr nach Sierkbs Links und Apples Empfehlungen geschrieben wurde.
Aber genau das kommt praktisch nie vor, das ist doch der springende Punkt. Wenn Du auf HFS+ Case-Sensitive entwickelst, dann wird das immer auch auf HFS+ Case-Insensitive laufen, es sei denn, Du verwendest zwei Dateinamen, die sich nur durch die Großschreibung unterscheiden (und daher für HFS+ Case-Insensitive dieselbe Datei sind). Dass Dir das aus Versehen passiert, ist extrem unwahrscheinlich.

Wenn Du hingegen auf HFS+ Case-Insensitive entwickelst, dann übersiehst Du beim Debuggen jeden Großschreibungs-Rechtschreibfehler, weil das bei Dir eben zu keinem Fehler führt, sondern nur auf HFS+ Case-Sensitive. Dass Du solche Rechtschreibfehler machst, ist aber um Größenordnungen wahrscheinlicher als dass Du aus Versehen für verschiedene Dateien denselben Dateinamen, nur unterschieden durch die Großschreibung, verwendest.

Genau wegen dieser Asymmetrie gibt Apple vor, auf HFS+ Case-Sensitive zu entwickeln.
Wenn es irgendwo deshalb nicht läuft dann ab in die Tonne damit
Einverstanden. Ab in die Tonne mit allem von Adobe.
„Not every story must end with a battle (Ophelia, in der umwerfend guten feministischen Adaption des Hamlet-Stoffes in dem Film „Ophelia“)“
0
Weia
Weia05.09.1501:03
dreyfus
Ja und nein. "Ja" auf dem eigenen Rechner, "Nein" wenn es bspw. um betriebliche Office 365 Cloud Storage, Sharepoint oder Backup-Lösungen geht... von zwei Dateien mit vermeintlich identischem Namen wird da maximal eine gespeichert / gesichert. Völlig untragbar.
Ah, das kann sein, solche Sachen habe ich nicht probiert. (Ich würde sowas nie von Microsoft nutzen.)

Und ja, das ist natürlich untragbar.
„Not every story must end with a battle (Ophelia, in der umwerfend guten feministischen Adaption des Hamlet-Stoffes in dem Film „Ophelia“)“
0
sierkb05.09.1501:06
Weia:

+1
0
geka05.09.1501:10
Weia
geka
Wo kann man am Mac etwa "case sensitiven" einstellen?
Im Festplattendienstprogramm beim Formatieren der Festplatte.

Beim Installieren von OS X kannst Du ziemlich am Beginn des Installationsvorgangs selbigen pausieren und aus der Menüleiste heraus das Festplattendienstprogramm starten, um anzugeben, wie Deine Festplatte formatiert werden soll.

nö, da steht nix von "case sensitiven"
0
sierkb05.09.1501:16
geka:


Und dem obig vorangegangen:
john
Was genau heißt jetzt "ohne Groß- und Kleinschreibung"?
Werden nur noch kleine Buchstaben verwendet? Oder werden Groß- wie Kleinbuchstaben behandelt?
die englische bezeichnung drückt es vielleicht verständlicher aus: case sensitive

bedeutet, dass gross- und kleinschreibung (in pfaden und dateinamen) berücksichtigt werden.
ohne halt nicht.

sowie
sierkb
case sensitive (also: mit Berücksichtigung von Groß- und Kleinschreibung)
0
Legoman
Legoman05.09.1508:00
So viel Text!

Es wäre möglicherweise aber hilfreich, wenn ein einheitlicher Terminus verwendet werden würde.
Und zwar der, der im Screenshot zu sehen ist.
Und da steht nirgendwo "mit oder ohne Groß- und Kleinschreibung"!
0
sierkb05.09.1508:31
Legoman
So viel Text!

Guten Morgen!

Du liest es Dir ja offenbar noch nicht mal durch, wenn es wenig Text ist und in einem einzigen Satz bereits zu Anfang von john gesagt worden ist.
Es wäre möglicherweise aber hilfreich, wenn ein einheitlicher Terminus verwendet werden würde.

Siehe grad' Gesagtes. Wer lesen kann, ist klar im Vorteil. Zumal u.a. auch Apples Original-Doku eben leider in englischer Sprache verfasst ist. Und im Englischen und auch in Apples Dokumenten heißt es eben case-sensitive (Groß-/Kleinschreibung wird berücksichtigt) und case-insensitive (Groß-/Kleinschreibung wird nicht berücksichtigt). Und aus dem Zusammenhang dürfte es mittlerweile auch klar geworden sein, zumal beim ersten Auftauchen dieser Begriffe, die Korrelation und deutsche Übersetzung bereits mitgeliefert worden sind. Sowohl von john ganz oben als auch von mir.

Mein Gott, seid ihr anspruchsvoll und quengelig! Liefert doch selber mal was ab und macht euch die Schreib- und Recherche-Mühe und haltet nicht immer nur die Hand auf und stellt Forderungen über Forderungen, und dann passt euch dies nicht, dann passt euch das nicht, Mimimi, quengel, quengel, quengel, und überhaupt: Schuld sind immer nur diejenigen, die euch helfen wollen und euch was erklären wollen…
Und da steht nirgendwo "mit oder ohne Groß- und Kleinschreibung"!

Doch. Steht da. Spätestens im bereits zweimal gegebenen Screenshot. Unübersehbar. Es springt Dich förmlich an. Für Apples Kurzfassung darin kann ich nix, kann keiner von uns was, aber es dürfte auch so klar sein, was damit gemeint ist, es dürfte aus dem Zusammenhang sehr klar sein. Und Abgesehen davon bietet Apples OS X bzw. das Festplattendienstprogramm immer noch eine eingebaute Hilfe-Funktion an (⌘?), die erklärt es Dir an der Stelle auch nochmal ganz genau, was Apple an der besagten Stelle mit der Auswahl und der Formulierung in dem Auswahl-Menü genau meint.
0
sierkb05.09.1508:50
sierkb
Und Abgesehen davon bietet Apples OS X bzw. das Festplattendienstprogramm immer noch eine eingebaute Hilfe-Funktion an (⌘?), die erklärt es Dir an der Stelle auch nochmal ganz genau, was Apple an der besagten Stelle mit der Auswahl und der Formulierung in dem Auswahl-Menü genau meint.
OSX Festplattendienstprogramm-Hilfe

Festplatte partitioneren

1. Wählen Sie eine Festplatte in der Seitenleiste aus und klicken Sie auf „Partitionieren“.

Wenn Sie eine externe Festplatte partitionieren, vergewissern Sie sich, dass sie an Ihrem Computer angeschlossen ist.

2. Klicken Sie auf das Einblendmenü „Partitionslayout“ und wählen Sie die Anzahl der Partitionen aus.

Sie können für jede Partition eine Größe eingeben oder die Trennlinie zwischen den Partitionen bewegen, um deren Größe zu ändern. Wenn sich neben dem Namen einer Partition ein Stern befindet, ist der tatsächliche Name länger als der angezeigte.

3. Klicken Sie auf jede Partition und geben Sie einen Namen dafür ein.

Klicken Sie für jede Partition auf das Einblendmenü „Format“, wählen Sie ein Format aus und geben Sie eine Größe an.

Mac OS Extended (Journaled): Verwendet das Journaling, um die Integrität des hierarchischen Dateisystems zu schützen.

Mac OS Extended (Groß-/Kleinschreibung, Journaled): Verwendet das Journaling und beachtet die Groß-/Kleinschreibung von Ordnernamen. Zum Beispiel werden Ordner mit den Namen „Homework“ und „hoMeWOrk“ als zwei unterschiedliche Ordner gewertet.


MS-DOS (FAT): Wird für Windows-Festplatten mit einer Größe von 32 GB oder weniger verwendet.

ExFAT: Wird für Windows-Festplatten mit einer Größe von mehr als 32 GB verwendet.

Frei: Mit dieser Option kann der freie Speicherplatz einer Festplatte eingestellt werden.

[…]
0

Kommentieren

Diese Diskussion ist bereits mehr als 3 Monate alt und kann daher nicht mehr kommentiert werden.