Haben unsere Daten neu auf einem Linux-Server gespeichert. Seither gibt es massiv Probleme beim Laden von .pdf-Dateien im Quark Version 4.11 und 5 (Fehler -43 - Datei nicht gefunden). Auf dem MAC läuft System 9.21.
Laden wir die .pdf-Dateien von unserem alten NT-Server, keine Probleme. Wer kann helfen.
Mueke

Hallo Mueke,

auch meine Daten sind auf einem Linux-Datenserver und ich arbeite ebenfalls mit 9.2 und X-Press 4. Probleme dieser Art kenne ich aber nicht. Kannst du denn dieses problematische pdf laden, wenn du es dir lokal auf deinen Arbeitsrechner ziehst? So könnte man zumindest sicher gehen, dass es NICHT am pdf liegt sondern wirklich an der Netzumgebung... Und dann müsste diese Frage in das WIN-Forum...

Grüße, Ilona.

definiere doch bitte linux-server. samba? netatalk?

merci.

Hi Leute,

da fällt mir eigentlich nur eine Möglichkeit ein, denn das Verhalten von Win Servern formatiert in NTFS und mit "Services for Macintosh" ist was die Namenslänge von Dateinamen anbelangt zu Linuxen mit Netatalk leicht different. Allerdings gilt das nicht nur für Quark sondern für alle Anwendungen die Files erzeugen die einen längeren Namen haben können.
Eine weitere Möglichkeit wäre eine fehlende Dateiendung (Suffix). Da Linux keine Forks kann muss das dem 9er System mit versteckten Dateien nahegebracht werden.
Ich denke es könnte dabei gut sein dass eine sehr neue Version Linux mit deinem Arbeitsstationen Probleme hat.
Das waren mal meine ersten Ideen – hoffe das hilft ein wenig weiter.

hallo,

dies kann ich so nicht beistimmen. je nach verwendetem filesystem kann unix bzw seine derivate deutlich mehr zeichen im zb dateinamen beinhalten als NTFS.

auch unterstützt netatalk forks - das ist ja sinn der sache.

infos http://netatalk.sourceforge.net/

anmerkungen: für kleine arbeitsgruppen eignet sich netatalk je nach bedürfnissen gut. bei grösseren projekten ist jedoch davon abzuraten, da z.b. alle user über einen atalkd-prozess laufen. stürzt ein user ab, stürzen alle ab. dies ist z.b. mit helios anders geregelt, wo jeder benutzer seinen eigenen prozess hat.

somit bleiben die näheren spezifikationen von mueke abzuwarten, um das umfeld seines servers näher zu betrachten.

Hallo zusammen,

jetzt erst mal die näheren Details (entschuldigt bitte die Verspätung):

Der Server ist ein Debian Sarge mit Kernel 2.6.8-2-k7.
Es läuft sowohl ein Samba (3.0.14a-Debian) für die Windows-Freigaben, sowie netatalk in der Version 2.0.2 für MacOS (leider beherrscht MacOS 9 noch keine SMB-Freigaben, so dass dies notwendig ist).

Unter Windows (also mit Samba) gibt es keine Probleme. Und auch lange Dateinamen unter MacOS ansich machen keine Probleme (Umlaute funktionieren auch). Nur mit pdfs haben wir von Zeit zu Zeit (nicht wirklich eingrenzbar oder reproduzierbar) dieses Problem.

MfG
Mueke

mmh, da es nicht reproduzierbar ist, wird das schwierig werden.

ich schlage vor, dass du beim nächsten fehler dieser art das logfile vom atalkd mal hier reinkopierst. falls was auffälliges in /var/log/messages steht dann gerne auch.

könnte mir vorstellen, dass es was mit "mangled filenames" zu tun hat, welche unter umständen sonderzeichen beinhalten können, die dann wieder das problem verursachen.

alternativ würde ich dich bitten, zum testen einfach filenames (kurz, ohne sonderzeichen etc) zu benutzen.