NTFS *SCHREIBEN* unter OS X 10.4.5

leute... back to topic bitte!

wie wäre es mit einer einfachen aussage?

[ ] es gibt keine möglichkeit NTFS unter OSX zu beschreiben
oder
[ ] mit dem Programm XYZ kannst du NTFS unter OSX beschreiben.

das ist eine einfache entweder oder frage das kann doch so schwer nicht sein.
es geht hier um simple USB Festplatten (meiner meinung schon schlimm genug das es USB ist, aber das ist egal).

jemand kommt mit ner NTFS platte und sagt "kannst du das mal druff kopieren?" wenn man da als Mac user sagt "Nö" hat man wieder jemanden fazu gebracht kein Mac zu kaufen. weil "Mac ist ja eh immer inkompatibel zu allem, warum muß man sonst soviel für den Müll ausgeben?"

das man in diesen forum permanent so vom thema abschweifen muß *kotz*

cu assetburned
ps. mir ist leider keine möglichkeit bekannt NTFS unter OSX zu beschreiben. aber über Virtual PC wär´s mal nen versuch wert.
 
Mac OS X hat laut manpages zu dem Kommando mount_ntfs eingeschränkte Fähigkeiten auf NTFS Volumes zu schreiben.
In Ermangelung einer entsprechend formatierten Festplatte kann ich das nicht testen.
Weitere Details (wie gesagt):
Code:
man mount_ntfs
 
Habe es zwar selbst noch nicht getestet, aber nach Hörensagen ist NTFS-Schreibunterstützung unter OSX wohl auf ähnlichem Stand wie unter Linux, somit nicht allgemeintauglich. (IMO)

Wenn der Plattenbesitzer nicht extra auf ext2/3 oder reiser umstellen will. finde ich die Idee bzgl VirtualPC oder Q(Emu) gar nicht schlecht. Ist nicht wirklich schnell, aber 'sicher', sofern Du eine 2000/XP-CD hast.

Ich entschuldige mich, den Thread unnötig aufgeblasen und vom Thema weggeführt zu haben, ich dachte eigentlich, daß das Fehlen 'guter' NTFS-Schreibfähigkeit implizit ausgesagt wurde.
Ich wiederhole nochmals meine persönlichen Erfahrungen und meine Einschätzung, daß NTFS sehr stabil ist und eigentlich ein Punkt von Windows NT war, auf den man in der Linux-Welt besonders früher etwas neidisch gekuckt hat. Weiterhin gibt es die Möglichkeit in 2000/XP, andere Dateisysteme transparent zu integrieren, allerdings nicht für Bootmedien.
Daß MS auf NTFS die Hand drauf hat, bedauere ich auch sehr, aber MS ist da ja nicht der einzige, und ein entsprechendes Plugin von Apple wäre IMO etwas, was ggf. echten Alltagswert hat.
 
Ich will Dir da gar nicht widersprechen, General..., aber nachdem in diesem Thread in 40 Beiträgen nicht ein einziges mal erwähnt wurde, dass Mac OS X wenigstens eine eingeschränkte Schreibfähigkeit mitbringt, sah ich mich veranlasst das nachzuholen und auf die entsprechenden manpages hinzuweisen ;).
 
maceis schrieb:
dass Mac OS X wenigstens eine eingeschränkte Schreibfähigkeit mitbringt, sah ich mich veranlasst das nachzuholen und auf die entsprechenden manpages hinzuweisen
Ich wüßte aber nicht, wie man das nutzen sollte.

Im Finder, also per GUI geht's jedenfalls schonmal nicht.
Und auch in anderen Foren ist mir unter OS X keine Möglichkeit bekannt.
Vielleicht ist die man-page nur ein "Überbleibsel" von FreeBSD
 
maceis schrieb:
Mac OS X hat laut manpages zu dem Kommando mount_ntfs eingeschränkte Fähigkeiten auf NTFS Volumes zu schreiben.
In Ermangelung einer entsprechend formatierten Festplatte kann ich das nicht testen.
Weitere Details (wie gesagt):
Code:
man mount_ntfs
Das klingt nicht so, wenn man man mount ruft, da steht:

SEE ALSO
mount(2), fstab(5), mount_afp(8), mount_cd9660(8), mount_cddafs(8),
mount_devfs(8), mount_fdesc(8), mount_hfs(8), mount_msdos(8),
mount_nfs(8), mount_smbfs(8), mount_synthfs(8), mount_udf(8),
mount_volfs(8), mount_webdav(8), umount(8)

also kein Wort mehr von "mount_ntfs".

Beim man mount_ntfs und den limited writing capabilities sieht es auch TRAURIG aus:
WRITING
There is limited writing ability. Limitations: file must be nonresident
and must not contain any sparces (uninitialized areas); compressed files are also not supported.

Kein "sparces" und was auch immer "nonresident files" sind... ?
Klingt alles nicht nach einer Methode, der man businesscritical data anvertrauen sollte.

Laut einer BSD-Mailingliste:
http://unix.derkeiler.com/Mailing-Lists/FreeBSD/questions/2003-11/2029.html
Zitat: "o in other words, you should probably should not count on being able to write to an NTFS partition. "

Ich denke, man kann das als "geht nicht" abhaken, im Sinne der Alltagstauglichkeit.
 
SilentCry schrieb:
Das klingt nicht so, wenn man man mount ruft, da steht:
[...]
also kein Wort mehr von "mount_ntfs".
...
Da steht aber auch:
Code:
4th Berkeley Distribution        [color=red]June 16, 1994[/color]       4th Berkeley Distribution
Sind also nicht gerade topaktuell, die manpages von mount :D.
SilentCry schrieb:
...
Ich denke, man kann das als "geht nicht" abhaken, im Sinne der Alltagstauglichkeit.
Das kann natürlich jeder halten, wie er möchte.
Wenn ich die Anforderung hätte, würde ich es ausprobieren, bevor ich aufgebe. Kann natürlich gut sein, dass ich danach zu dem selben Schluss käme.
 
maceis schrieb:
Da steht aber auch:
Code:
4th Berkeley Distribution        [color=red]June 16, 1994[/color]       4th Berkeley Distribution
Sind also nicht gerade topaktuell, die manpages von mount :D.
Das kann natürlich jeder halten, wie er möchte.
Wenn ich die Anforderung hätte, würde ich es ausprobieren, bevor ich aufgebe. Kann natürlich gut sein, dass ich danach zu dem selben Schluss käme.
ad a) Stimmt. Allerdings lässt eine Suche nach dem Thema nicht gerade die aberdutzenden Treffer zu "hey, guy, use mount_ntfs, works here in my company just great with terabytes of data every day" aufspringen. Geht eher gegen Null, die Treffersumme... :)

ad b) Das Problem mit unzuverlässigen Filesystemtreibern ist, dass sie sich selten deterministisch verhalten. Welche Laborbedingungen und Testszenarien soll ich ansetzen, bevor ich sagen kann: Ja, scheint stabil zu klappen oder nein, geht nicht produktiv?

Ich bin ein Privatanwender mit geringen Überschneidungen ins Business, langwierige Tests sollten von den Developern bzw. dem lieben Apple gemacht werden, Zeit, sich eine InstallationsCD für Windows am macbookpro auszudenken hatte der liebe Apple ja auch, nur für den Need der ECHTEN OSX-Anwender hat er offenbar keinen Draht mehr. Ich brauche keinen zwanzigsten Variantenaufguss vom iPod, ich brauche zZt. getestet funktionierenden ntfs-Schreibzugriff.
 
SilentCry schrieb:
ad a) Stimmt. Allerdings lässt eine Suche nach dem Thema nicht gerade die aberdutzenden Treffer zu "hey, guy, use mount_ntfs, works here in my company just great with terabytes of data every day" aufspringen.
LOL.
Ganz im Gegenteil.
Selbst bei den Threads, wo von mount_ntfs die Rede war, konnten die Leute nicht schreiben.

SilentCry schrieb:
nur für den Need der ECHTEN OSX-Anwender hat er offenbar keinen Draht mehr.
Warte doch erst mal ab, was in Leopard kommt.*
Außerdem würde ich sagen: Der "Need" (sag mal, studierst du Marketing?) vieler OS X-Anwender war, auch Windows zu haben.
Und das gab's auf Intel-Macs nicht mal per Virtual PC.

SilentCry schrieb:
ich brauche zZt. getestet funktionierenden ntfs-Schreibzugriff.
Ich bezweifel, dass Apple das noch nicht erkannt hat.
Ich könnte mir vorstellen, dass es einfach nicht möglich ist.
"Reverse Engineering" ist für eine Firma wie Apple "so eine Sache"...


* Leopard wäre angesichts des Intel Switchs, Boot Camp, und gerüchteweiser Virtualisierungs-Techniken in Leopard genau der richtige Zeitpunkt, um NTFS-Unterstützung auszuweiten
 
Generalsekretär schrieb:
Deine Meinung, daß NTFS schlecht ist, kann ich selbst nicht teilen, und offenbar auch keiner der anderen Poster. Vielleicht solltest Du Dir erst mal den Schaum vom Mund wischen.

Tja, da liegt ihr dann wohl falsch. NTFS ist schlecht, das ist Fakt. Gerne kann ich dir auch mal ein paar Teststellungen notieren.
Fat32 ist ein top FS dagegen, leider nur veraltet.
Wenn du das nicht verstehen willst, dann laß es halt..

Zu 'dumm zum Dokumentieren' war MS sicher nicht, man wollte wohl einfach die Hand drauf lassen.

Das wird sich zeigen. NTFS hat sich nie so durchgesetzt wie FAT. Lediglich Windows Systeme setzen NTFS ein auf Bootpartitionen.

Nun, das ist aber schon Ideologie und bedeutet auch 'kein OSX'.
Verstehen kann ich das bei Kryptographie, aber sonst?

Auch bei Dateisystemen ist das sinnvoll. Im Crashfall läßt sich aus einer Fat32 Partition noch eher was Extrahieren, als bei NTFS, weil es mehr Tools gibt, bessere Doku etc.
 
Incoming1983 schrieb:
NTFS hat sich nie so durchgesetzt wie FAT. Lediglich Windows Systeme setzen NTFS ein auf Bootpartitionen.
???
...und das sind vielleicht 90% der Computerwelt.

Linux hatte auch früher nie FAT, Mac OS auch nicht.
 
performa schrieb:
LOL.
Warte doch erst mal ab, was in Leopard kommt.*
Außerdem würde ich sagen: Der "Need" (sag mal, studierst du Marketing?)
Nein, ich bin Informatiker, aber Du hast Recht, ich arbeite in einer Firma, in der man bei einer Unterhaltung im Raucherzimmer davon ausgehen kann, dass IP nicht Internet-Protocol sondern "intellectual property" heisst und IC nicht "integrated circuit" sondern "intellectual captial"...
Als Techniker fühlt man sich dort wie eine Prinzessin.
In einer Welt voller Drachen.

vieler OS X-Anwender war, auch Windows zu haben.
Und das gab's auf Intel-Macs nicht mal per Virtual PC.
Dafür dürfen MBP-Besitzer jetzt WinXP direkt auf den Books intallieren.
(siehe http://www.heise.de/newsticker/meldung/71716)
Das ist ein Trend, den ich nicht gerne sehe. Bislang konnte man verzückt sein beim Anblick eines unerwarteten Apples in einem Cafe oder Zug, jetzt müsste man dem User über die Schulter auf den Bildschirm linsen um festzustellen, ob es nicht ein Schaf im Wolfspelz ist...

Ich bezweifel, dass Apple das noch nicht erkannt hat.
Ich könnte mir vorstellen, dass es einfach nicht möglich ist.
"Reverse Engineering" ist für eine Firma wie Apple "so eine Sache"...
Ich empfehle Apple, die Typen von Sysinternals.com und ihre Lösung NTFSDOS anzusehen, vielleicht möchten die Ingenieure von Apple auch mit einer "Wrapper"-Lösung das Problem umgehen?
(siehe http://www.sysinternals.com/Utilities/NtfsDosProfessional.html)
Linux macht sowas mit zB dem NDIS-Wrapper für native Win-Treiber, die dann unter Linux laufen um störrische Hardware anzusteuern.

Naja, für mich zZt. existiert keine praktikable Lösung. Bleibt nur die Hoffnung auf eine bessere Zukunft, wie so oft :)
 
Incoming1983 schrieb:
Abgesehen davon, daß es eben nicht gut ist, wenn Dateien wild verstreut sind (dadurch sinkt der größte freie zusammenhängende Speicherplatz, wodurch Fragmentierung sehr viel schneller auftritt), interpretiere ich die Anzeige richtig. Rot=böse.

Fragmentierung ist aber sehr gut für den mittleren Datendurchsatz einer Platte.

Oder hast du dich noch nie gefragt, warum klassische UNIX-Dateisysteme nicht defragmentiert werden?

Kleiner Tipp: Hintereinander bappende Files sind zwar gut für den sequentiellen Zugriff in exakt dieser Reihenfolge, verstreute Files haben aber den Vorteil, dass es wahrscheinlicher ist, dass die nächsten gesuchten Daten näher an der aktuellen Kopfposition sind...
 
Oder hast du dich noch nie gefragt, warum klassische UNIX-Dateisysteme nicht defragmentiert werden?

Weil es einfach anders ist. Klassischer Unixe werden nicht für den Desktop verwendet. Und im Serverumfeld sind zumindest RAID Arrays (i.d.R. R5) in Verwendung. Und dort egalisiert sich die Fragmentierung dadurch, dass die Daten eh auf vielen Spindeln verteilt sind.
Und für die Systemplatten kann man (zumindest im AIX) festlegen, wo auf der Platte die Daten abgelegt werden (Aussen, mittendrin oder innen (und dann noch dort aussen oder innen, wers ganz genau mag)).
Ausserdem ist ein Unix System mit iNodes aufgebaut und die sind ohnehin auf der Platte verteilt. NTFS und FAT haben einen festen Bereich, wo das Inhaltverzeichnis angeordnet wird. Und genau dorthin muss der Kopf zurück um festzustellen, wo das nächste Fragment ist. In einem Unixsystem steht der Ort des nächsten Fragments im iNode drin.
Man kann das also überhaupt nicht vergleichen.
 
Incoming1983 schrieb:
Tja, da liegt ihr dann wohl falsch. NTFS ist schlecht, das ist Fakt. Gerne kann ich dir auch mal ein paar Teststellungen notieren.
Fat32 ist ein top FS dagegen, leider nur veraltet.
Wenn du das nicht verstehen willst, dann laß es halt..
Warum so unhöflich?
Verstehen würde ich schon gerne, warum NTFS denn so schlecht sein soll.
Wenn Du Erfahrungswerte oder tieferes Wissen dazu hast, bin ich keinesfalls einer Erweiterung meines Wissens&Horizonts abgeneigt.
Nur bist Du eigentlich der erste, der mir unterkommt, der über die Qualität von NTFS schimpft.

Incoming1983 schrieb:
Auch bei Dateisystemen ist das sinnvoll. Im Crashfall läßt sich aus einer Fat32 Partition noch eher was Extrahieren, als bei NTFS, weil es mehr Tools gibt, bessere Doku etc.
Auch das ist zwar richtig, sofern man selbst Hand anlegen will.
Aber das betrifft doch eigentlich so ziemlich alle proprietären Dateisysteme.
Oder irre ich hier?
 
sgmelin schrieb:
NTFS hat kein Journaling.

In dem Sinne, wie es bei anderen Dateisystemen ist, stimmt das. ABER:

NTFS ist ein transaktionales Dateisystem. Es werden erst die Dateien geschrieben und wenn das erfolgreich war, wird die MFT aktualisiert. Sollte zwischendrin etwas passiert sein, dann ist es so, als wäre nix passiert. Daten können dadurch verloren sein, aber das Dateisystem behält seine Konsistenz.

Im Prinzip kann man sich das wie eine Transaktion bei einer SQL-Datenbank vorstellen. Es passiert entweder komplett oder gar nicht.

Die anstehenden Transaktionen werden natürlich "zwischengespeichert". Sollte es also zwischendrin zu einem Abbruch kommen, so erkennt Windows das anhand der noch anstehenden Transaktionen und guckt nach, was bisher passiert ist und kann entsprechend reagieren. Er schreibt also kein Journal in dem Sinne, sondern nutzt einfach das was er eh macht. Die Transaktions-Datenbank angucken.

Andere Dateisysteme mit Jounal schreiben dort ja nur rein, was als letztes auf der Platte passiert ist und prüfen nach einem Crash nur den entsprechenden Dateibereich.

Dateisysteme wie XFS oder UFS2 (FreeBSD) sind noch kranker. Die holen sich die Daten in den RAM und verändern die dort. In bestimmten Zeitabständen wird dann wieder alles zurück auf die Platte geschrieben. Wenn es dann zu einem Abbruch kommt (Stromausfall, etc.) dann sind die Daten halt weg, bzw. wurden nie geschrieben... Auch eine Art die Dateisystemkonsistenz beizubehalten. ;)
 
Zurück
Oben Unten