Riesenbug bzgl. Groß-Kleinschreibung bei SMB / Mavericks

[Ameisentaetowierer]

Das ist aber mal ein Tempo hier...
Was spricht eigentlich gegen folgendes

ssh als root
cd in Systemverzeichnis
Copy der Konfigdatei nach /volume1/EinsDerExportiertenVerzeichnisse
Mounten von EinsDerExportiertenVerzeichnisse auf dem Mac
Editieren der Konfigdatei auf dem Mac
Zurückkopieren der Datei von /volume1/EinsDerExportiertenVerzeichnisse in das Systemverzeichnis
Dienst neu starten bzw. reboot

Oder:
ssh als root
vi ....

Micky

 

[Bernhard Heinz]

@ all
Heureka, ich tanze Samba... es funzt. Nach Reboot der Station und des Mac (!!!) werden beide Dateien angezeigt. Jetzt gehe ich erstmal durch iTunes und schaue, ob es noch hunderte verlorener Dateien gibt...

Danke an alle, die so fleißig an der Problemlösung mitgemacht haben, die zuletzt erwähnte Lösung von Ameisentätowierer wäre sicher die einfachste aus Mac Sicht gewesen, leider zu spät....

Ich werde den Case mal an den Synology Support melden, die sollten das mit dem case Sesitive für SMB zumindest einstellbar machen.

Gruß
Bernhard

 

[trininja]

Gute Nachrichten und gute Entscheidung für nen Support Ticket. Ich nehme eh an das alle Dateien von "vor" 10.9.1 noch da sind, da sich das Dateisystem von der Synology ja nicht mal eben geändert hat, EXT4 ist case-sensitive eingestellt auf den DiskStations (Ja, man kann case-sensitive auf auf EXT4 abschalten, sollte man aber !!!NIEMALS!!! in einem Live System versuchen. Ich erwähnte ja vorhin, das ich erst einmal in meinem Leben einen Datenverlust durch Experimente hatte. ). Nur Apple hat das Handling geändert von AFP auf SMB und somit hat Samba nur jede Datei einmal gesehen, da der Server im eben "zusammengefasst" hat, da er nicht auf case-sensitive reagiert hat (Samba nimmt meines wissens die "neuste" erstellte Datei und händigt diese aus.).

Aber nach wie vor: ssh als root und vi. *hust* KUNG-FU!

 

[raymond]

@ all
Heureka, ich tanze Samba... es funzt. Nach Reboot der Station und des Mac (!!!) werden beide Dateien angezeigt. Jetzt gehe ich erstmal durch iTunes und schaue, ob es noch hunderte verlorener Dateien gibt...

Danke an alle, die so fleißig an der Problemlösung mitgemacht haben, die zuletzt erwähnte Lösung von Ameisentätowierer wäre sicher die einfachste aus Mac Sicht gewesen, leider zu spät....

Ich werde den Case mal an den Synology Support melden, die sollten das mit dem case Sesitive für SMB zumindest einstellbar machen.

Gruß
Bernhard

Wunderbar. Aber die Erfahrungen bzw. Vorschlag solltest du definitiv Synology zukommen lassen. Und nun gibts einen Beruhigungstee?

 

[stefan_lx]

also, um jetzt das Chaos perfekt zu machen, muss ich mir jetzt selber ein wenig widersprechen...

Habe im video Ordner drei Ordner angelegt (über Filestation):
EinOrdner
einOrdner
einordner

Mounte ich mir den Video-Ordner unter Linux mit smb/cifs sehe ich alle drei Ordner, sie haben auch unterschiedliche Inhalte...
Gehe ich mit Win7 (allerdings eine VM, mit allen Patches) auf das Share, sehe ich auch alle drei Ordner, genauso, wie unter Linux...

Aber: ich habe in der smb.conf die case-sensitive-Änderungen gar nicht drin ... ???
Ich hab dreimal mit Kungfu-vi gesucht, ob ich nicht doch was übersehen habe.

Löschen funktioniert bei allen dreien, ohne dass die anderen Ordner gelöscht werden, nur das Anlegen von "Einordner" geht nicht, da kommt die Meldung "schon vorhanden"...

Kann das jemand nachvollziehen? So als Case-Ergänzung ...

Stefan

 

[trininja]

Vermutlich wurden die Ordner auch mit einem case-sensitive System angelegt oder? Dann würde es evtl. das Verhalten erklären, vor allem per CIFS, da bei cifs case-sensitive per default an ist. Du siehst ja im DSM unter aktuelle Verbindungen wer per CIFS drauf ist oder nur per reinem SMB. Wenn du dann per Windows versuchst diese Ordner nochmal so anzulegen schlägt es fehl, da Windows selber nicht case-sensitive ist und die Befehle an den Server nicht richtig sendet. Über Linux wiederum geht es, und Windows dürfte diese dann auch wieder sehen.

Fangt jetzt nicht an rumzufragen wieso und weshalb, google -> Dateisystem/Übertragungsprotokoll_XYZ +case +sensitive. Weil da gibt es Szenarien, da bekommste als Admin das kalte Grauen. Da ist man froh wenn einem die Backupsoftware alles abnimmt für solche Mischsysteme wo alles Kraut und Rüben an Dateisystemen rumrennt.

Noch extremer wird es wenn man dann mit Windows Server 2008 einen reinen NFS Servershare aufbaut, NFS kann auf NTFS case-sensitive schreiben und lesen. Wenn man weis was man einstellen muss. Um das Chaos dann noch perfekt zu machen am besten noch nen CIFS/SMB Server parallel auf demselben Server aufbauen der eben nicht case-sensitive ist und auf dieselben Verzeichnisse zugreift. Schneller kannst du deine IT nicht kaputtmachen als mit dem Fall.

 

[stefan_lx]

klar, habs ja mit der Filestation angelegt
ok, dann legen wir das mal zu den Akten und merken uns, dass man am besten Groß-/Kleinschreibung nicht mischt

Stefan

 

[Bernhard Heinz]

Kommando zurück:
Habe eben einen halben Schock bekommen, beim Kopieren eines Ordners zurück von Syno auf Mac wurde nach ein paar Dateien abgebrochen mit "Datei schon vorhanden".
Jetzt habe ich mir meinen Testordner nochmal angesehen: Mist, beide Dateien werden im Finder mit gleichem Namen angezeigt, also
TestOrdner
TestOrdner
Das gibt natürlich Probleme beim Zurückschreiben. Mit der Filestation heißen die
TestOrdner
Testordner

Fazit: Mein Problem leider nicht gelöst

Gruß
Bernhard

 

[trininja]

So, weiter gehts. Diesmal spielen wir mal eben Terminal auf deinem Mac, ich hab nen Verdacht:

Terminal auf dem Mac aufmachen und gib folgendes ein:

diskutil list /

Genau so.

Wenn dabei folgendes rauskommt:

File System Personality: Journaled HFS+
Type (Bundle): hfs
Name (User Visible): Mac OS Extended (Journaled)

Ist dein Mac NICHT case-sensitive eingestellt, bzw. das HFS+ wurde ohne case-sensitive erstellt.

Ansonsten müsste in der letzten Zeile: Mac OS Extended (Case-sensitive, Journaled) stehen und in der ersten Zeile Case-sensitive Journaled HFS

In den meisten Mac Foren wird übrigens DRINGENST davon abgeraten case-sensitive zu benutzen, da wohl einige Apps, darunter auch Microsoft Office und Adobe Tools, mittlerweile wohl sogar einige Apple eigene, nicht damit umgehen können und es vermehrt zu Problemen und Fehler führen kann. Die meisten Entwickler kleiner Tools denken auch garnicht an solch einen Fall und entwicklen auf einem case-intensive System und testen nicht wie es sich bei case-sensitive verhält. Gab da wohl nach der Umstellung auf 10.9.1 ein paar Systemtools, die die Mac Config Files falsch schrieben und es dann zu lustigen Fehlern bis hin zum vollen Verlust der Datenpartition kam.

 

[Bernhard Heinz]

Mac OS Extended (Journaled) steht bei meinen beiden internen disks, wenn ich die mit Apfel i aufrufe oder im Festplattendienstprogramm nachsehe.

Mit der Eingabe im Terminal kommt das raus (meine Systemplatte ist eine 256 SSD):
heinz-i7:~ Heinz$ diskutil list /
/dev/disk0
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *256.1 GB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_HFS Heinz-256 255.1 GB disk0s2
3: Apple_Boot Recovery HD 650.0 MB disk0s3

Wat nu?
So lassen und auf Fehler warten bzw. manuell die Station nach doppelten Namen durchgehen?
Irgendwie krass, aber wenn case sensitive mehr Probleme schafft, als löst, lasse ich die Finger davon.

Bin jetzt schon mal die iTunes Library durchgegangen, das waren es auf Anhieb ca 70 fehlende Dateien wegen Doppelung oder krasser Namen (ein Ordner hatte als Endung __. (2 mal Unterstrich dot), die darin befindlichen Dateien wurden von iTunes übergangen und waren deshalb weg. Der Ordner war von iTunes im April 2013 generiert worden (gekaufte Songs) !!!
Der Haupverbrecher bzgl doppelter Dateinamen ist inzwischen bei mir nicht mehr in Gebrauch, das war iMovie 6 (das hatte tatsächlich gleiche Dateinamen mit Endung mal .JPG, mal .jpg generiert, echt krass). Leider habe ich davon halt auch ein etliche Roh-Videos auf der Station - muß ich wohl manuell lösen...oder ich versuchs mal mit CCC (carbonCopyCloner) ??
Gruß
Bernhard

 

[trininja]

Case-sensitive ist manchmal eine sehr gute Sache, aber nicht im reinen Endanwender Umfeld. Vor allem wenn es wie jetzt hier zu diesen Katastrophen kommt. Ok, die der Befehl hat sich mit 10.8 schon geändert, my bad, ich hatte noch den alten Befehl.

Versuch mal diskutil info /, das sollte unter 10.9.1 die Infos anzeigen. Dein Ansatz zurückzukehren zum Case Intensive ist zu begrüssen, verhindert auf jedenfall solche Geschichten wie JPG und jpg.

File System Personality: Case-sensitive Journaled HFS+
oder
File System Personality: Journaled HFS+
kommt bei raus. ^^

Alternative:

touch abc.TXT
touch ABC.txt
ls abc*

Wenn er dir nur eine Datei anzeigt, kannst du davon ausgehen, das du Case Intensive hast, wenn er dir beide anzeigt, hast du Case Sensitive. Ja, lustig kompliziert das Ganze, aber wir wollen ja zu einem Ziel kommen.

 

[Bernhard Heinz]

Hier das Ergebnis der Terminaleingabe:
File System Personality: Journaled HFS+
Type (Bundle): hfs
Name (User Visible): Mac OS Extended (Journaled)
Journal: Journal size 24576 KB at offset 0x774000
Owners: Enabled
Partition Type: Apple_HFS
Damit ist klar, dass ich nicht case sensitiv habe, ich kann auch keine 2 Dateien oder Ordner generieren, die sich nur durch Groß-Klein unterscheiden.

Übrigens waren die Platten beim Mac-Kauf so formatiert vom Apple Händler, der mir genau dies auch empfahl. Ich hatte mir nie den Kopf darüber zerbrochen... bin halt seit ich nicht mehr SW entwickele (und das ist schon verdammt lange her) reiner Anwender!!!

Kann es sein, dass ich mal vor Unzeiten meine Platte mit case-sensitive formatiert hatte - sonst kann ich mir das mit dem .JPG / .jpg gar nicht gut erklären, das hätte ja schon früher zu Problemen führen müssen, nicht erst beim Zurückspielen von der Syno.

Gruß
Bernhard

 

[trininja]

Frage ist halt was Apple da verballert hat, bzw. du sagtest ja, das du auf die Syno Archiviert hast und AFP als Dateiprotokol wurde ja auf Case-Sensitive gestellt mit glaub Leopard damals und die Synos haben das soweit ich weis schön übernommen. Und iMovie hat dann nach Lust und Laune Dateinamen geschrieben. Problem ist halt, du hast ja auch vor dem MacMini schon Apple benutzt, da werden sich auch noch Altlasten reingedrängt haben, vor allem wenn der davor mit case-sensitive HFS+ aufgebaut war. Das erinnert mich so richtig lustig an die Zeiten mit den 8.3 Namen und der Abschaltung dieser Funktion per Registry als dann alte FiBu Systeme auf einmal nichtmehr gingen, da die nur mit 8.3 DOS Namen klar kamen. *evilsmile*

Denke mal hier ist von einigen Seiten her was schief gegangen und da muss man mal den schwarzen Peter Richtung Apple schieben, den die Sache mit AFP auf case-sensitive, aber das System selber steht auf case-intensive ist nicht gerade Förderlich, vor allem nicht wenn man ein NAS zum archivieren nutzt.

 

[Bernhard Heinz]

So, jetzt habe ich verstanden, dass mein Problem nicht gelöst werden kann - und Probleme, die man nicht lösen kann, ertrage ich gelassen.

Frage an die Experten:
Gibt es irgendein Package, mit dem man alle Dateien auf der Syno durchforsten kann nach irgendwelchen illegalen Dateinamen ?

Hintergrund:
Ich wollte jetzt meine Syno mal durchforsten nach irgendwelchen uralten Dateien, die Probleme verursachen könnten.
- Fotos (ca 80.000) sind bei mir unkritisch da ich die alle schon bei der Archivierung mit einem Tool vernünftig benahmst habe.
- Auch Musik (40GB) ist unkritisch, das ist so wenig, das kann ich zu Fuß durchforsten (auch wenn iTunes ziemlich lächerliche Ordnernamen vergibt wie z.B. "Super Fury - Best of__..."), so was kann man schnell erkennen!
- Filme : Meine Terabyte an alten Filmen möchte ich eigentlich retten. Da ich es rein zeitlich nicht schaffen würde, Millionen Dateien (von iMovie generiert) zu durchforsten, gehe ich den Weg über die Anwendungen. Meine Idee: Ich lade also ganz einfach in iMovie mit der Version die damals gültig war, die entsprechenden Rohfilme und schau mir die an.

Ptoblem:
Alles Theorie... Schon beim dritten Film blieb iMovie hängen und stürzte meinen kompletten Mini Mac ab (Hatte ich noch nie !!). Ich habe dann mal in den Paketen des Rohfilmes nachgeschaut und tatsächlich, da gab es eine Datei mit Länge 0 und völlig ohne Namen, aber mit einem schönen Icon. Klasse - und sowas führt dann zum Systemcrash, den es ja eigentlich in der Apple Welt nicht gibt!!!

Deshalb meine Frage, ob es irgendwelche Tools gibt die mir diesen Mist bereinigen können.

Gruß
Bernhard

 

[trininja]

Wenn du 0 Byte Dateien ausklammern willst, dann einfach über eine Dateisuche mit Dateigröße = 0 Byte. Würde dir aber Empfehlen das Ergebniss erstmal durchzuschauen, also auf die Dateinamen schauen, nicht das irgendwo ne 0 Byte Datei dabei ist, die wichtig sein könnte, manchmal werden ja solche .NOINDEX_DENY oder ähnliche Namen vergeben um Ordner vom Indexieren oder ähnliches auszuschliessen. Speziell jetzt in deinem Anwendungsfall fällt mir da nichts ein, evtl. Datenbereinigungstools wie CleanMyMac o.ä. mal versuchen.

 

[nilsen]

So, jetzt habe ich verstanden, dass mein Problem nicht gelöst werden kann - und Probleme, die man nicht lösen kann, ertrage ich gelassen.

Die Frage, die sich mir jetzt stellt: Wenn SMB nicht so funktioniert wie es soll, warum dann nicht bei AFP bleiben? Nur weil Apple in 10.9 auf SMB umschwenkt, bedeutet das ja nicht da AFP tot ist! Hier läuft 10.9.1 mit AFP auf einer Syno völlig ohne Probleme.

Gruß
Nils

 

[trininja]

Das Problem ist schon längst nicht mehr SMB, sondern die Case-Sensitive Geschichte und die dadurch verursachten Datenmüllhaufen, die sich gebildet haben. AFP mit case-sensitive wird ihm jetzt auch wenig bringen wenn sein Dateisystem Case-Intensive ist. Und er hat ja Samba auf Case-Sensitive umgestellt, ergo verhält es sich aktuell wie AFP.

 

[Bernhard Heinz]

@Nilsen:
AFP scheidet z.Zt. bei mir aus 2 Gründen aus:
1. Die Performance von AFP ist seit Mavericks katastrophal (Dateiliste anzeigen von 500 Dateien liegt im Minutenbereich). Da hat Apple leider mit Mavericks was funktionierendes geschrottet.
2. Die Anwendungen (iTunes etc) greifen auf die Syno nur noch über SMB zu, mir ist nicht bekannt, wie man das anders einstellen kann. Ich nehme an, Apple hat das seit Mavericks mit Absicht so eingerichtet, da sie mit AFP ein nicht so schnell lösbares Problem haben.

Fazit: An smb geht z.Zt. kein Weg vorbei.

Gruß
Bernhard

 

[nilsen]

@Bernhard
zu. 1. was die Performance angeht, ich kann hier leider nur für eine DS509+ mit DSM 4.2 (leider etwas veraltet) sprechen, aber die Darstellung einer Dateiliste mit 1000 Bildern (alle um die 6MB groß) dauert hier nicht länger als 2 Sekunde, das Ganze auch noch per WLAN (5 GHz max. Transfer 25 MB/Sec).

zu. 2. Ich gehe mal davon aus, dass das gesamte iTunes-Verzeichnis auf der DS liegt, geht hier ohne Stress, dto. Aperture

Fazit: Das Problem liegt mit hoher Wahrscheinlichkiet woanders.

Beste Grüße,
Nils

 

[Bernhard Heinz]

@Bernhard
zu. 1. was die Performance angeht, ich kann hier leider nur für eine DS509+ mit DSM 4.2 (leider etwas veraltet) sprechen, aber die Darstellung einer Dateiliste mit 1000 Bildern (alle um die 6MB groß) dauert hier nicht länger als 2 Sekunde, das Ganze auch noch per WLAN (5 GHz max. Transfer 25 MB/Sec).

zu. 2. Ich gehe mal davon aus, dass das gesamte iTunes-Verzeichnis auf der DS liegt, geht hier ohne Stress, dto. Aperture

Fazit: Das Problem liegt mit hoher Wahrscheinlichkiet woanders.

Beste Grüße,
Nils

zu 1.: Du benutzt tatsächlich Mavericks 10.9.1 mit AFP ? (Nur um sicherzugehen, dass wir nicht aneinander vorbeireden).
Falls ja, müssen wir beide dringend mal weiter graben, woran das bei mir liegen könnte.

zu 2:
Ja, ich hatte meine komplette iTunes Library schon vor Jahren auf die Syno umgezogen, bisher gabs keine Probleme bei AFP (case-sensitive)
Mit Mavericks / SMB und case insensitive gabs jetzt aber Probleme bei Ordnern wie
Nightwish
NighWish
die von iTunes mal vor Jahren so angelegt worden waren (!!! nicht von mir). Jetzt wurde wegen smb/case-insensitive von iTunes nur eine dieser Ordner gelesen, die Unterordner und Dateien des anderen ordners waren aus iTunes Sicht weg!!! Und das ist nur ein Beispiel von vielen.
Genauso bei iMovie, wo es Dateien mit gleichem Namen gibt mit Endung
.JPG
.jpg
Aperture generiert zwar krasse Dateinamen, aber keine doppelten, deshalb läuft das auch sauber. Und bei Import und Archivierung vergebe ich immer vernünftige Dateinamen. Deshalb tritt das nicht bei Aperture auf.

Vielleicht habe ich ein grundsätzliches Problem, dass meine Platten auf Mac OS Extended (Jornaled) formatiert sind (war beim Kauf so). Bitte schau mal nach, wie das bei Dir ist.

Gruß
Bernhard