Bin unzufrieden mit Finder

._ut schrieb:
@ Lynhirr
Die von mir erläuterten Probleme treten auch nur auf, wenn man ein instabiles SMB-Netz verwendet, d.h. wenn der Server Zugriffsprobleme hat, z.B. durch schlechte Kabel, zu hohe Last etc. oder gar abstürzt.
Zum Vergrößern anklicken....

Ja, so hatte ich das auch verstanden. Gäbe es denn ein alternatives Netzwerk, das zum empfehlen wäre?
 
._ut schrieb:
Das würde allerdings bei den oben angesprochenen Problemen mit SMB auch nichts ändern. Dann würden einfach beide (bzw. n) Tasks stehen. Denn wenn das Dateisystem gelockt ist, kann kein Task darauf zugreifen.
Zum Vergrößern anklicken....
Wenn das Dateisystem angeblick gelockt ist, wieso kann ich dann mit anderen Anwendungen Dateien lesen & schreiben? Oder hab ich dich da falsch verstanden?
 
Zuletzt bearbeitet:
._ut schrieb:
@ pks85
Ich habe es es auch gerade mal getestet, als höchstes hatte ich mal ganz kurz 15%, sonst so um 5% (bei einem 450MHz G4).
Hast Du vielleicht defekte JPEGs in Deinem Ordner?
Zum Vergrößern anklicken....

Das ist schon länger so... (hab mich irgendwie damit abgefunden - seit 10.3.7 oder so - PB 17" 1,5GHz, 1GB Ram)

Wenn es an defekten JPEGs liegen sollte, dann müssten alle meine Bilddateien defekt sein - tritt nämlich bei allen Ordner mit Bilddateien drin auf (gif, jpeg etc.) wenn die Vorschau aktiviert ist... finder.plist löschen bringt nix, naja vielleicht wird, wenn ich endlich meinen Studentenausweis habe und mir dann Tiger kaufe, dann alles gut ;)
 
Darii schrieb:
Wenn das Dateisystem angeblick gelockt ist, wieso kann ich dann mit anderen Anwendungen Dateien lesen & schreiben?
Zum Vergrößern anklicken....
Kannst Du nicht. Alle Anwendungen, mit denen man versucht auf das Dateisystem zuzugreifen, bleiben dann stehen.

D.h. Es funktionieren keine Öffnen- und Sichern-Dialoge mehr, die Hierarchie-Menüs von Ordnern im Dock gehen nicht mehr etc. (Ein User hier im Forum hat das mal beschrieben mit: Wenn der Finder abstürzt, reißt er alle Cocoa-Programme mit sich.)
 
Zuletzt bearbeitet von einem Moderator:
Lynhirr schrieb:
Ja, so hatte ich das auch verstanden. Gäbe es denn ein alternatives Netzwerk, das zum empfehlen wäre?
Zum Vergrößern anklicken....
Prinzipiell scheint AppleShare und NFS fehlertoleranter zu sein bzw. schneller zu reagieren und das Dateisystem wieder freizugeben.
Im Windows-Netzwerk ist beides keine Alternative, Windows kann ja nichts anderes.
 
pks85 schrieb:
Das ist schon länger so... (hab mich irgendwie damit abgefunden - seit 10.3.7 oder so - PB 17" 1,5GHz, 1GB Ram)

Wenn es an defekten JPEGs liegen sollte, dann müssten alle meine Bilddateien defekt sein - tritt nämlich bei allen Ordner mit Bilddateien drin auf (gif, jpeg etc.) wenn die Vorschau aktiviert ist... finder.plist löschen bringt nix, naja vielleicht wird, wenn ich endlich meinen Studentenausweis habe und mir dann Tiger kaufe, dann alles gut ;)
Zum Vergrößern anklicken....

10.3 hatte mit der Vorschau von Bildern so seine Probleme. Ein Brute-Force-Ansatz, wenn Plattenplatz keine große Rolle spielt, ist das Vorgenerieren der Thumbnails.

Dazu ins Terminal gehen, in den jeweiligen Ordner wechseln und:

sips --addIcon *

eingeben. Damit werden dann die Thumbnails generiert. Rentiert sich vermutlich nur bei den häufiger besuchten Verzeichnissen.
 
das mit dem Samba Problem ist anderen auch schon aufgefallen(mich eingeschlossen):

>>klick<<

unter 10.3.9 gabs die Probleme, unter 10.4.0 wars weg, seit 10.4.1 ist es wieder da.
Und das der Finder nicht der Schnellste ist, naja das stimmt auf jeden Fall,
aber was bleibt uns übrig wir müssen es hinnehmen.
 
grabmeru schrieb:
10.3 hatte mit der Vorschau von Bildern so seine Probleme. Ein Brute-Force-Ansatz, wenn Plattenplatz keine große Rolle spielt, ist das Vorgenerieren der Thumbnails.

Dazu ins Terminal gehen, in den jeweiligen Ordner wechseln und:

sips --addIcon *

eingeben. Damit werden dann die Thumbnails generiert. Rentiert sich vermutlich nur bei den häufiger besuchten Verzeichnissen.
Zum Vergrößern anklicken....

Hm danke, werds mal ausprobieren - wieviel Plattenplatz braucht das denn ca. (bei 13GB Bilder...)?
 
._ut schrieb:
Prinzipiell scheint AppleShare und NFS fehlertoleranter zu sein bzw. schneller zu reagieren und das Dateisystem wieder freizugeben.
Im Windows-Netzwerk ist beides keine Alternative, Windows kann ja nichts anderes.
Zum Vergrößern anklicken....

ne du, ich arbeite mit NFS in mehreren Netzwerken und auch SMB und Apple hat bei der NFS und SMB Implementierung einfach schlampig gearbeitet. Der Finder blockiert z.B. oft das ganze System wenn ein Mount aus dem Netzwerk verschindet. Diebezüglich gibt es auch massenhaft Bugreports. Apple arbeitet auch unentwegt an den Problemen. Erst mit 10.4 wurde z.B. die Performance von SMB und NFS durch Kernel-Modifikationen verbessert.
 
@ cilly
Wie ich schon sagte, es ist nicht der Finder, der das ganze System blockiert. Bei SMB z.B. ist es der Samba-Client und der ist der gleiche, der auch in den verschiedenen Linux-Distributionen und BSD etc. werkelt.
 
Zuletzt bearbeitet von einem Moderator:
pks85 schrieb:
Danke, gut. Und wie wende ich den Befehl auf Ordner+Unterordner an? Habe keine Lust immer das Verzeichnis zu wechseln und von vorn... :)
Zum Vergrößern anklicken....

Wieder Brute-Force (stellt vermutlich jedem UNIX-Geek die Nackenhaare auf, aber für mich hat's damals gereicht).

1. Schritt:

Datei mit absoluten Pfaden zu den Bildern erstellen, die Thumbnails erhalten sollen.

find -d /DeinStartordner -name '*.jpg' > ~/iconify

Das Kommando findet in allen Ordnern unterhalb von /DeinStartordner alle .jpg-Files und schreibt die absoluten Pfade in die Datei "iconify" in deinem Home-Directory. Meines Wissens kann der -name Parameter auch Pattern-Matching, man könnte also in einem Rutsch alle interessierenden Grafik-Dateien finden. So gut kenne ich mich nicht damit aus; ich hab halt einen zweiten Durchlauf für die .gifs gemacht.

2. Schritt:

In dieser Datei in einem Texteditor deines Vertrauens die Dateien mit dem sips-Kommando ausstaffieren (sicherheitshalber auch noch einfache Anführungszeichen ' um den Pfad machen, falls der Leerzeichen enthält). Die Zeilen sollten dann also etwa so aussehen:

sips --addIcon '/DeinStartorder/.../DeinBild1.jpg'
sips --addIcon '/DeinStartorder/.../DeinBild2.jpg'
...


3. Schritt.

Die Datei ausführbar machen. Dazu folgende Zeile oben in der Datei einfügen (wenn du in der bash-Shell arbeitest; ist in 10.3. glaube ich Standard):

#!/bin/bash

sips --addIcon '/DeinStartorder/.../DeinBild1.jpg'
sips --addIcon '/DeinStartorder/.../DeinBild2.jpg'
...


4. Schritt:

Datei im Terminal ausführen (unter der Annahme, dass du im Home-Directory bist - und möglicherweise möchtest du das erst mal mit einer Kopie der Kommandodatei machen, die bloß ein paar Thumbnails erzeugt):

DeinRechner:~ . iconify

Zur Sicherheit: Das ist "Punkt blank Dateiname"

Je nach Anzahl der Bilder nudelt der Rechner dann ein bißchen, und hinterher ist ein bißchen weniger Platz auf der Platte. Wer elegantere Lösungen hat, möge sie bitte beisteuern.
 
Vielen Dank für die ausführliche Erklärung!
Werde es heute noch ausprobieren!

Gruß,pks
 
._ut schrieb:
Wie ich schon sagte, es ist nicht der Finder, der das ganze System blockiert. Bei SMB z.B. ist es der Samba-Client und der ist der gleiche, der auch in den verschiedenen Linux-Distributionen und BSD etc. werkelt.
Zum Vergrößern anklicken....
Klar ist's nicht der Finder, aber der Finder lässt es zu, dass SMB oder NFS ihn blockiert... deshalb grotten schlechte Implementierung von Apple bezüglich Finder & SMB, NFS, AFP.
 
._ut schrieb:
Kannst Du nicht. Alle Anwendungen, mit denen man versucht auf das Dateisystem zuzugreifen, bleiben dann stehen.

D.h. Es funktionieren keine Öffnen- und Sichern-Dialoge mehr, die Hierarchie-Menüs von Ordnern im Dock gehen nicht mehr etc. (Ein User hier im Forum hat das mal beschrieben mit: Wenn der Finder abstürzt, reißt er alle Cocoa-Programme mit sich.)
Zum Vergrößern anklicken....
Wenn du meinst, ich habe leider gerade nicht die Möglichkeit nachzuprüfen ob mich meine Erinnerung trügt. ;)

Aber auch wenn es so ist stimme ich da voll und ganz cilly zu. Wenn der Finder sich blockieren läßt trägt er Mitschuld. Meine ganz naive Meinung. Über die technischen Hintergründe werde ich mit dir nicht diskutieren, das wäre sinnlos, davon habe ich nämlich keine Ahnung.
 
@ cilly
Nicht nur der Finder lässt zu, dass er blockiert wird. *Jedes* Programm, das auf das Dateisystem zugreifen will lässt das zu.
Soweit ich das weiß ist das auch normales UNIX-Verhalten. Es kann allerdings sein, dass man das unter Mac OS X mehr bemerkt, da das Ganze hier stärker automatisiert und abstrahiert sind, als bei anderen Unices.


@ Darii
Das kannst Du ganz schnell ausprobieren. Du mountest ein Server-Volume und ziehst den Ethernet-Stecker raus. Sobald Du auf das Dateisystem zugreifst (aber erst dann), egal wie (Beispielsweise, indem Du Apfel-S drückst), wird der entsprechende Prozess blockiert. Ca. 2 min später gibt es eine Meldung, dass die Verbindung abgebrochen war und nicht wieder hergestellt werden konnte, das Volume verschwindet vom Schreibtisch und alles andere funktioniert wieder wie gehabt.
 
Zuletzt bearbeitet von einem Moderator:
@._ut

Nun, auf meiner Gentoo-Kiste läuft das mit smb und nfs einwandfrei, da friert nicht gleich der ganze Directory Service ein. Man kann smb und nfs sogar parallel zur gleichen Zeit mounten und darauf zugreifen, da gibt es keine Aussetzer. Läuft absolut geschmeidig. Ich nehme das mal als Gegenbeweis bezüglich deines betitelten Unix-Verhaltens.

Meiner Meinung nach hat Apple bei der Implementierung der verschiedenen Filesysteme geschlampt. Der Finder spricht ja nicht direkt mit diesen FS, auch andere Programme nicht, sonder Apple hat einige Services dazwischen geschaltet, wie z.B.:

root 60 0.0 0.1 27768 1064 ?? Ss Sun05PM 0:07.34 diskarbitrationd
root 72 0.0 0.1 31092 1956 ?? Ss Sun05PM 0:15.06 DirectoryService
root 253 0.0 0.1 29404 1096 ?? Ss Sun06PM 0:00.17 automount

Es könnte aber auch an einer schlechten Kernel-Implementierung liegen, da bei NFS und SMB auch Kernel-relevante Tasks angesprochen werden.

Da Aqua auf diese Services aufbaut und sich von diesen Services ausbremsen lässt, schiebe ich die Schuld Apple zu.
 
@ cilly
Bei Mac OS X läuft das unter normalen Umständen auch einwandfrei. Aussetzer gibt es nur, wenn das Netzwerk fehlerhaft ist.
Wie verhält sich denn Deine Gentoo-Kiste, wenn Du das Ethernet-Kabel rausziehst und dann über die GUI auf das Dateisystem bzw. die gemountete SMB-Freigabe oder NFS-Export zugreifst?

Ich denke nicht, dass das an der Implementierung der Dateisysteme liegt, sondern an der Art und Weise, wie auf das Dateisystem zugegriffen wird.
Im Gegensatz zu der Shell greift Aqua immer auf das Dateisystem als Ganzes (der Finder und die Öffnen- und Sichern-Dialoge stellen ja mehr, als nur das eine Verzeichnis dar) und in Echtzeit (z.B. erscheinen in der Shell neu angelegte oder geänderte Objekte automatisch im Finder bzw. den Dialogen) zu. Die Shell jedoch greift immer nur auf ein einzelnes Verzeichnis zu und aktualisiert den Inhalt nicht automatisch.
Die ls- und cd-Befehle funktionieren alle noch, wenn ein gemountetes Netzwerk-Volume zu dem die Verbindung getrennt ist im Dateisystem vorhanden ist. Wenn man aber mit der Shell versucht auf dieses Netzwerk-Volume zuzugreifen (zu dem die Verbindung getrennt ist), steht die Shell und reagiert auch nicht mehr auf Breaks o.ä.

Dass das Dateisystem manchmal steht ist sozusagen der Preis für den Bedienkomfort.
 
Zuletzt bearbeitet von einem Moderator:
Zurück
Oben Unten