Discussion:
Dateinamen Windows, UDF (DVD) bzw. ISO9660 (CD) kompatibel machen
(zu alt für eine Antwort)
Michael Schmarck
2008-07-27 09:00:38 UTC
Permalink
Hallo.

Ich habe hier eine "Unmenge" von Dateien, die die "Dateisystemspezifika"
von Linux Dateisystemen ausnutzen - dh. sehr lange Dateinamen (zum Teil
mehr als 200 Zeichen im Dateinamen) und auch "Sonderzeichen" im
Dateinamen (insbesonders :).

Nun möchte ich das ganze auf DVD brennen und von Windows drauf
zugreifen.

Wenn ich einfach nur genisoimage ("mkisofs" von cdrkit) verwende,
so werden die Dateinamen die zu lang sind, einfach abgeschnitten.
Besonders ärgerlich ist das, weil dann auch die Extension verloren
geht und somit die betroffenen Dateien nicht mehr direkt unter
Windows verwendbar sind (sie sollen aus dem Explorer aus heraus
aufgerufen werden - es sind JPEG Bilder).

Kann jemand ein Tool/Script empfehlen, mit dem man die Dateienamen
zum Brennen einfach umnennen kann und sie somit Windows, UDF (DVD)
bzw. ISO-9660 (CD) kompatibel machen kann?

Danke,

Michael
Martin Schnitkemper
2008-07-27 09:21:20 UTC
Permalink
Post by Michael Schmarck
Kann jemand ein Tool/Script empfehlen, mit dem man die Dateienamen
zum Brennen einfach umnennen kann und sie somit Windows, UDF (DVD)
bzw. ISO-9660 (CD) kompatibel machen kann?
Hast du auch die mkisofs-Optionen -J oder -joliet-long verwendet, um die
Joliet-Erweiterungen zu erzeugen?

Martin.
--
OS: openSUSE 10.2 (i586)
Kernel: 2.6.18.8-0.10-default
KDE: 3.5.9 "release 65.1"
Michael Schmarck
2008-07-27 09:41:22 UTC
Permalink
Post by Martin Schnitkemper
Post by Michael Schmarck
Kann jemand ein Tool/Script empfehlen, mit dem man die Dateienamen
zum Brennen einfach umnennen kann und sie somit Windows, UDF (DVD)
bzw. ISO-9660 (CD) kompatibel machen kann?
Hast du auch die mkisofs-Optionen -J oder -joliet-long verwendet, um die
Joliet-Erweiterungen zu erzeugen?
Ja. Damit kommt man aber auf max. 103 Zeichen.

Wie gesagt, der längste Dateiname (also ohne Verzeichnisnamen) ist
238 Zeichen.

Mit Verzeichnisnamen davor komme ich auf vlt. 300 Zeichen.

Gruß,

Michael
Martin Schnitkemper
2008-07-27 11:48:32 UTC
Permalink
Post by Michael Schmarck
Post by Martin Schnitkemper
Hast du auch die mkisofs-Optionen -J oder -joliet-long verwendet, um die
Joliet-Erweiterungen zu erzeugen?
Ja. Damit kommt man aber auf max. 103 Zeichen.
Das ist aber eine Einschränkung der Joliet-Erweiterung, die nicht zu umgehen
ist.
Post by Michael Schmarck
Wie gesagt, der längste Dateiname (also ohne Verzeichnisnamen) ist
238 Zeichen.
Soweit ich mich erinnern kann, ist das Frontend "k3b" in der Lage, nur den
Namenanteil des Dateinamens so zu kürzen, daß die Erweiterung erhalten
bleibt. Den vollen Dateinamen wird man damit aber auch nicht retten können.

Martin.
--
OS: openSUSE 10.2 (i586)
Kernel: 2.6.18.8-0.10-default
KDE: 3.5.9 "release 65.1"
Michael Schmarck
2008-07-27 18:03:36 UTC
Permalink
Post by Martin Schnitkemper
Post by Michael Schmarck
Post by Martin Schnitkemper
Hast du auch die mkisofs-Optionen -J oder -joliet-long verwendet, um die
Joliet-Erweiterungen zu erzeugen?
Ja. Damit kommt man aber auf max. 103 Zeichen.
Das ist aber eine Einschränkung der Joliet-Erweiterung, die nicht zu umgehen
ist.
Klar. Darum such ich ja nach einem Weg, um die Dateinamen kompatibel
zu machen :)
Post by Martin Schnitkemper
Post by Michael Schmarck
Wie gesagt, der längste Dateiname (also ohne Verzeichnisnamen) ist
238 Zeichen.
Soweit ich mich erinnern kann, ist das Frontend "k3b" in der Lage, nur den
Namenanteil des Dateinamens so zu kürzen, daß die Erweiterung erhalten
bleibt.
Dann wäre das versteckt. Fügt man eine Datei mit einem zu langen
Dateinamen hinzu, so wird das anstandslos akzeptiert.
Post by Martin Schnitkemper
Den vollen Dateinamen wird man damit aber auch nicht retten können.
Klar.

Vielen Dank,

Michael
Martin Schnitkemper
2008-07-27 19:14:11 UTC
Permalink
Post by Michael Schmarck
Dann wäre das versteckt. Fügt man eine Datei mit einem zu langen
Dateinamen hinzu, so wird das anstandslos akzeptiert.
Beim Hinzufügen "ja", wenn man aber mit dem Brennen beginnen will (bzw. das
ISO erzeugt wird) erscheint aus k3b ein Dialog, der darauf hinweist, daß
der Dateiname nicht den ISO-Spezifikationen entspricht und ob der Dateiname
gekürzt oder manuell umbenannt werden soll.

Martin.
--
OS: openSUSE 10.2 (i586)
Kernel: 2.6.18.8-0.10-default
KDE: 3.5.9 "release 65.1"
Juergen Ilse
2008-07-28 06:42:25 UTC
Permalink
Hallo,
Post by Michael Schmarck
Post by Martin Schnitkemper
Post by Michael Schmarck
Post by Martin Schnitkemper
Hast du auch die mkisofs-Optionen -J oder -joliet-long verwendet, um die
Joliet-Erweiterungen zu erzeugen?
Ja. Damit kommt man aber auf max. 103 Zeichen.
Das ist aber eine Einschränkung der Joliet-Erweiterung, die nicht zu umgehen
ist.
Klar. Darum such ich ja nach einem Weg, um die Dateinamen kompatibel
zu machen :)
Aendere die Datei- (und Verzeichnis-) namen in "etwas kompatibles"
(sprich nicht zu langes) ...

Tschuess,
Juergen Ilse (***@usenet-verwaltung.de)
--
Ein Domainname (auch wenn er Teil einer Mailadresse ist) ist nur ein Name,
nicht mehr und nicht weniger ...
Michael Schmarck
2008-07-28 08:52:08 UTC
Permalink
Post by Bernd Mayer
Hallo,
Post by Michael Schmarck
Post by Martin Schnitkemper
Post by Michael Schmarck
Post by Martin Schnitkemper
Hast du auch die mkisofs-Optionen -J oder -joliet-long verwendet, um
die Joliet-Erweiterungen zu erzeugen?
Ja. Damit kommt man aber auf max. 103 Zeichen.
Das ist aber eine Einschränkung der Joliet-Erweiterung, die nicht zu
umgehen ist.
Klar. Darum such ich ja nach einem Weg, um die Dateinamen kompatibel
zu machen :)
Aendere die Datei- (und Verzeichnis-) namen in "etwas kompatibles"
(sprich nicht zu langes) ...
Exakt. Und danach habe ich ja gesucht *G* Um mal wieder an den Anfang
des Threads zurück zu kommen :-) Schrieb ich glaube ich schonmal: Ich
leide definitiv nich an NIH'eritis und hätte somit keine Probleme auf
eine fertige Lösung/fertiges Programm zurückzugreifen. Und eben dies
habe ich gesucht.

Michael
Joerg Schilling
2008-08-04 10:37:45 UTC
Permalink
Wie gesagt, der lÀngste Dateiname (also ohne Verzeichnisnamen) ist
238 Zeichen.
Kein Problem mit Originalsoftware. Niemand zwingt Dich defekte Forks
zu verwenden.
Mit Verzeichnisnamen davor komme ich auf vlt. 300 Zeichen.
Die 255 Zeichen-Grenze zählt pro Pfadnamenkomponente.
--
EMail:***@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
***@cs.tu-berlin.de (uni)
***@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Niklaus Kuehnis
2008-07-27 09:48:50 UTC
Permalink
Post by Michael Schmarck
Kann jemand ein Tool/Script empfehlen, mit dem man die Dateienamen
zum Brennen einfach umnennen kann und sie somit Windows, UDF (DVD)
bzw. ISO-9660 (CD) kompatibel machen kann?
Ich verwende in solchen Fällen tar.
--
Niklaus
Michael Schmarck
2008-07-27 10:36:19 UTC
Permalink
Post by Niklaus Kuehnis
Post by Michael Schmarck
Kann jemand ein Tool/Script empfehlen, mit dem man die Dateienamen
zum Brennen einfach umnennen kann und sie somit Windows, UDF (DVD)
bzw. ISO-9660 (CD) kompatibel machen kann?
Ich verwende in solchen Fällen tar.
Problem: tar hat keine Information darüber, welcher Zeichensatz
auf dem Quellsystem verwendet wurde. Und tar kann nicht so einfach
auf Windows XP verwendet werden (ohne Zusatztools).

Zumal: Könnte man ein solches Tar dann überhaupt auf Windows
schmerzfrei entpacken?

Bei ZIP gibt's auch das Zeichensatzproblem. Und RAR ist auch
nicht verwendbar, da es Probleme bereitet, bei Dateien deren
Pfadname (also Verzeichnisse + Dateiname) länger als 260 Zeichen
sind. Wobei diese Limitierungen evtl. auch durch NTFS kommen
mögen, das möchte ich nicht bestreiten.

Vielen Dank soweit,

Michael
Niklaus Kuehnis
2008-07-27 11:28:56 UTC
Permalink
Post by Michael Schmarck
Post by Niklaus Kuehnis
Post by Michael Schmarck
Kann jemand ein Tool/Script empfehlen, mit dem man die Dateienamen
zum Brennen einfach umnennen kann und sie somit Windows, UDF (DVD)
bzw. ISO-9660 (CD) kompatibel machen kann?
Ich verwende in solchen Fällen tar.
Problem: tar hat keine Information darüber, welcher Zeichensatz
auf dem Quellsystem verwendet wurde.
Da müsstest du vorher mit mvconv oder convmv die Dateinamen
konvertieren.
Post by Michael Schmarck
Und tar kann nicht so einfach
auf Windows XP verwendet werden (ohne Zusatztools).
Ja, da nimmt man z.B. cygwin.
Post by Michael Schmarck
Zumal: Könnte man ein solches Tar dann überhaupt auf Windows
schmerzfrei entpacken?
Ich denke schon, falls NTFS mit solchen Pfadlängen umgehen kann.
Post by Michael Schmarck
Bei ZIP gibt's auch das Zeichensatzproblem. Und RAR ist auch
nicht verwendbar, da es Probleme bereitet, bei Dateien deren
Pfadname (also Verzeichnisse + Dateiname) länger als 260 Zeichen
sind. Wobei diese Limitierungen evtl. auch durch NTFS kommen
mögen, das möchte ich nicht bestreiten.
Vielleicht doch umbenennen:
gprename - Complete batch renamer for Linux
gwenrename - Batch renamer tool for KDE
mrename - A tool for easy and automatic renaming of many files
krename - Powerful batch renamer for KDE 3.x

(alle ungetestet)
--
Niklaus
Michael Schmarck
2008-07-27 11:50:57 UTC
Permalink
Post by Niklaus Kuehnis
Post by Michael Schmarck
Post by Niklaus Kuehnis
Post by Michael Schmarck
Kann jemand ein Tool/Script empfehlen, mit dem man die Dateienamen
zum Brennen einfach umnennen kann und sie somit Windows, UDF (DVD)
bzw. ISO-9660 (CD) kompatibel machen kann?
Ich verwende in solchen Fällen tar.
Problem: tar hat keine Information darüber, welcher Zeichensatz
auf dem Quellsystem verwendet wurde.
Da müsstest du vorher mit mvconv oder convmv die Dateinamen
konvertieren.
Danke.
Post by Niklaus Kuehnis
Post by Michael Schmarck
Zumal: Könnte man ein solches Tar dann überhaupt auf Windows
schmerzfrei entpacken?
Ich denke schon, falls NTFS mit solchen Pfadlängen umgehen kann.
Ich glaube nicht, das NTFS damit umgehen könnte.
Post by Niklaus Kuehnis
Post by Michael Schmarck
Bei ZIP gibt's auch das Zeichensatzproblem. Und RAR ist auch
nicht verwendbar, da es Probleme bereitet, bei Dateien deren
Pfadname (also Verzeichnisse + Dateiname) länger als 260 Zeichen
sind. Wobei diese Limitierungen evtl. auch durch NTFS kommen
mögen, das möchte ich nicht bestreiten.
gprename - Complete batch renamer for Linux
gwenrename - Batch renamer tool for KDE
mrename - A tool for easy and automatic renaming of many files
krename - Powerful batch renamer for KDE 3.x
(alle ungetestet)
Danke, mal antesten!

Michael
Thomas Kosch
2008-07-28 07:47:43 UTC
Permalink
Post by Michael Schmarck
Post by Niklaus Kuehnis
Ich denke schon, falls NTFS mit solchen Pfadlängen umgehen kann.
Ich glaube nicht, das NTFS damit umgehen könnte.
Glauben kannst du in der Kirche. Die Maximale Pfadlänge bei NTFS ist
32000 Zeichen.

ttyl8er, t.k.
--
Life is Xerox, and you're just a copy
Michael Schmarck
2008-07-28 09:01:19 UTC
Permalink
Post by Thomas Kosch
Post by Michael Schmarck
Post by Niklaus Kuehnis
Ich denke schon, falls NTFS mit solchen Pfadlängen umgehen kann.
Ich glaube nicht, das NTFS damit umgehen könnte.
Glauben kannst du in der Kirche. Die Maximale Pfadlänge bei NTFS ist
32000 Zeichen.
Okay. Interessanterweise meldet RAR eine Fehlermeldung, die besagt,
das ein Pfad/Dateinamen nicht mehr als 260 Zeichen haben dürfte.

H:\bilder.rar: Konnte .............................
Verzeichnis- und Dateinamen zusammen dürfen nicht länger als
260 Zeichen sein
The system cannot find the pat hspecified.

Ist ja nicht so, als ob ich so eine Fehlermeldung erfinden würde :)

Michael
Juergen Ilse
2008-07-28 11:38:00 UTC
Permalink
Hallo,
Post by Michael Schmarck
Post by Thomas Kosch
Post by Michael Schmarck
Post by Niklaus Kuehnis
Ich denke schon, falls NTFS mit solchen Pfadlängen umgehen kann.
Ich glaube nicht, das NTFS damit umgehen könnte.
Glauben kannst du in der Kirche. Die Maximale Pfadlänge bei NTFS ist
32000 Zeichen.
Okay. Interessanterweise meldet RAR eine Fehlermeldung, die besagt,
das ein Pfad/Dateinamen nicht mehr als 260 Zeichen haben dürfte.
Die APIs unter NT nutzen nicht alle saemtliche Faehigkeiten von NTFS aus.
Ein Teil traegt vermutlich immer noch Altlasten aus "DOS-Zeiten" mit sich
herum und diese Beschraenkung scheint noch aus dieser Zeit zu stammen ...
Fuer den Nutzer ist es allerdings ziemlich gleichgueltig, an welcher Stelle
es scheitert, ihn interessiert nur, *ob* es scheitert (und im Zusammenhang
mit manchen Programmen scheint das zumindest der Fall zu sein ...).

Tschuess,
Juergen Ilse (***@usenet-verwaltung.de)
--
Ein Domainname (auch wenn er Teil einer Mailadresse ist) ist nur ein Name,
nicht mehr und nicht weniger ...
Thomas Kosch
2008-07-29 06:53:26 UTC
Permalink
Post by Bernd Mayer
Hallo,
Post by Michael Schmarck
Post by Thomas Kosch
Post by Michael Schmarck
Post by Niklaus Kuehnis
Ich denke schon, falls NTFS mit solchen Pfadlängen umgehen kann.
Ich glaube nicht, das NTFS damit umgehen könnte.
Glauben kannst du in der Kirche. Die Maximale Pfadlänge bei NTFS ist
32000 Zeichen.
Okay. Interessanterweise meldet RAR eine Fehlermeldung, die besagt,
das ein Pfad/Dateinamen nicht mehr als 260 Zeichen haben dürfte.
Die APIs unter NT nutzen nicht alle saemtliche Faehigkeiten von NTFS aus.
Ein Teil traegt vermutlich immer noch Altlasten aus "DOS-Zeiten" mit sich
herum und diese Beschraenkung scheint noch aus dieser Zeit zu stammen
Die stammt dann aber von RAR.

Oder vielleicht doch nicht.

Windows kann durchaus mit Pfadlängen von bis zu 32000 Zeichen umgehen.

Zu mindest theoretisch.

Unter bestimmten Umständen.

http://msdn.microsoft.com/en-us/library/aa365247.aspx

ttyl8er, t.k.
--
Life is Xerox, and you're just a copy
Joerg Schilling
2008-08-04 10:42:14 UTC
Permalink
Post by Michael Schmarck
Ich denke schon, falls NTFS mit solchen PfadlÀngen umgehen kann.
Ich glaube nicht, das NTFS damit umgehen könnte.
Glauben kannst du in der Kirche. Die Maximale PfadlÀnge bei NTFS ist
32000 Zeichen.
Okay. Interessanterweise meldet RAR eine Fehlermeldung, die besagt,
das ein Pfad/Dateinamen nicht mehr als 260 Zeichen haben dÃŒrfte.
RAR ist kein Standard und daher nicht für Archivierung zu empfehlen.

TAR hat unbegrenzte Pfadnamenlänge (gut eigentlich 8 GB) und es gibt
keine Implementierung die nicht wenisgtens 1024 Bytes unterstützt.
--
EMail:***@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
***@cs.tu-berlin.de (uni)
***@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Michael Schmarck
2008-08-04 11:20:24 UTC
Permalink
Post by Michael Schmarck
Post by Thomas Kosch
Post by Michael Schmarck
Post by Niklaus Kuehnis
Ich denke schon, falls NTFS mit solchen Pfadlängen umgehen kann.
Ich glaube nicht, das NTFS damit umgehen könnte.
Glauben kannst du in der Kirche. Die Maximale Pfadlänge bei NTFS ist
32000 Zeichen.
Okay. Interessanterweise meldet RAR eine Fehlermeldung, die besagt,
das ein Pfad/Dateinamen nicht mehr als 260 Zeichen haben dürfte.
RAR ist kein Standard und daher nicht f�r Archivierung zu empfehlen.
Allerdings lässt sich RAR unter Windows auch DAU-kompatibel bedienen,
da man mit RAR auch SFX (selbstentpackende Dateien) erstellen kann.
Es würde also keine .rar-Datei weiteregegeben werden, sondern eine
.exe-Datei.
TAR hat unbegrenzte Pfadnamenl�nge (gut eigentlich 8 GB) und es gibt
keine Implementierung die nicht wenisgtens 1024 Bytes unterst�tzt.
Was allerdings wenig nützt, wenn der Empfänger die Datei nicht entpacken
kann, da kein installiertes Programm mit TAR umgehen kann und da kein
zusätzliches Programm installiert werden soll.

Michael
Markus Kohm
2008-08-04 13:38:05 UTC
Permalink
Post by Michael Schmarck
Es würde also keine .rar-Datei weiteregegeben werden, sondern eine
.exe-Datei.
...
Post by Michael Schmarck
Was allerdings wenig nützt, wenn der Empfänger die Datei nicht entpacken
kann, da kein installiertes Programm mit TAR umgehen kann und da kein
zusätzliches Programm installiert werden soll.
tar, gunzip, bzip2 und ähnliche Werkzeuge muss man normalerweise nicht
installieren, sondern allenfalls auspacken (siehe beispielsweise
<http://www.gzip.org/> oder UnxUtils auf SourceForge). Worin liegt dann die
Anwendung derselben auf ein tar-Archiv im Vergleich zur Ausführung einer
Anwendung, von der der Absender behauptet, es wäre ein Archiv?

Gruß
Markus
Michael Schmarck
2008-08-04 13:58:52 UTC
Permalink
Post by Markus Kohm
Post by Michael Schmarck
Es würde also keine .rar-Datei weiteregegeben werden, sondern eine
.exe-Datei.
...
Post by Michael Schmarck
Was allerdings wenig nützt, wenn der Empfänger die Datei nicht entpacken
kann, da kein installiertes Programm mit TAR umgehen kann und da kein
zusätzliches Programm installiert werden soll.
tar, gunzip, bzip2 und ähnliche Werkzeuge muss man normalerweise nicht
installieren, sondern allenfalls auspacken
Nein, das reicht nicht. Man muss sie auch anwenden können.

Klar könnte man auch ein Batch / WSH File mitliefern, das einen Dialog
anzeigt, etc.pp.. Hast Du das fertig? Oder hast Du einen Link, der
weiterhilft?
Post by Markus Kohm
<http://www.gzip.org/> oder UnxUtils auf SourceForge). Worin liegt dann
die Anwendung derselben auf ein tar-Archiv im Vergleich zur Ausführung
einer Anwendung, von der der Absender behauptet, es wäre ein Archiv?
Hä?

Bei einem SFX muss der Anwender nur auf die Datei einen Doppelklick
machen, und es passiert was. Was passiert, ist natürlich vom SFX Modul
abhängig. Und irgendwelche Einschränkungen von wegen "man
klickt nicht auf EXEs" mögen zwar vlt. in gewissen Umgebungen richtig
sein, hier allerdings nicht.

Bei einer .tar Datei auf einem ansonsten nackten Windows XP passiert
gar nichts, wenn darauf ein Doppelklick gemacht wird (bzw. es passiert
schon was - Windows fragt nach, was mit so einer unbekannten Datei
gemacht werden soll).

Wer hier krampfhaft keinen Unterschied erkennen will, der erkenne
ihn halt nicht.

Im übrigen frage ich mich echt, was .tar und SFX mit dem Thema
(siehe Subject!) zu tun hat. Ob man's glaubt oder auch nicht, aber
ich habe den Betreff nicht zufälligerweise so gewählt, wie ich ihn
gewählt habe. Mir geht's nicht um die Frage wie Daten ausgetauscht
werden könnten, sondern wie Dateinamen so geändert werden
könnten, das sie zu Windows, UDF bzw. ISO9660 kompatibel sind.
Darum frug ich im OP:

| Kann jemand ein Tool/Script empfehlen, mit dem man die Dateienamen
| zum Brennen einfach umnennen kann und sie somit Windows, UDF (DVD)
| bzw. ISO-9660 (CD) kompatibel machen kann?

Vielen Dank,

Michael
Markus Kohm
2008-08-04 15:45:56 UTC
Permalink
Post by Michael Schmarck
Bei einem SFX muss der Anwender nur auf die Datei einen Doppelklick
machen, und es passiert was.
Genau diese Einstellung hat dazu geführt, dass jeden Tag irgendwelche
Rechner Mails an mich verschicken, die ich gar nicht haben will und dabei
Absender angeben, die damit gar nichts zu tun haben.

Wenn Du das mitmachen willst, vergiss nicht, eine autostart-Datei anzulegen,
die gleich beim Einlegen der CD/DVD dafür sorgt, dass das Archiv ausgepackt
wird.
Post by Michael Schmarck
Im übrigen frage ich mich echt, was .tar und SFX mit dem Thema
(siehe Subject!) zu tun hat.
Na schön, dann passen wir den Betreff eben an das inzwischen geänderte Thema
an. Dumm nur, dass ich oben eigentlich schon wieder auf das ursprüngliche
Thema zurückgekommen bin ...
Post by Michael Schmarck
Ob man's glaubt oder auch nicht, aber
ich habe den Betreff nicht zufälligerweise so gewählt, wie ich ihn
gewählt habe. Mir geht's nicht um die Frage wie Daten ausgetauscht
werden könnten, sondern wie Dateinamen so geändert werden
könnten, das sie zu Windows, UDF bzw. ISO9660 kompatibel sind.
Es ist immer wieder schön, wenn Leute, die eine Frage haben, danach auch
noch bestimmen wollen, was andere darauf antworten und aus der entstehenden
Diskussion machen dürfen. Willkommen im Usenet!
Post by Michael Schmarck
Und im übrigen ist natürlich auch das (also auspacken) schon eine
Installationsart.
Schade, ich muss jetzt doch nochmal auf das ursprüngliche Thema zurück
kommen: Das Auspacken kannst Du doch bereits machen. Einfach tar.exe,
gunzip.exe ausgepackt mit auf die CD/DVD packen. Dazu packst Du dann noch
ein readme.txt (natürlich mit CRLF als Zeilenenden) oder readme.html und
gut ist. Damit sollte die Länge der Dateinamen schon einmal kein Problem
mehr sein (zumindest, wenn der Anwender NTFS verwendet). Jetzt brauchst Du
nur noch die Dateinamen nach ASCII zu wandeln, damit deren Codierung keine
Rolle mehr spielt. Wenn nur Umlaute und ß umzuwandeln sind, dann kann man
das sogar mit sed machen. Man kann auch einfach jedes Zeichen außerhalb von
US-ASCII wegwerfen, wenn die Lesbarkeit der Dateinamen keine Rolle spielt.

Man kann auch etwas wie:

#!/bin/bash

# Zuerst die Verzeichnisse
find ./ -type d | sort > dateinamen.src
cp dateinamen.src dateinamen.dest
recode -f UTF-8..US-ASCII dateinamen.dest
exec 5<dateinamen.src
exec 6<dateinamen.dest
while read -u 5 srcname; do
read -u 6 destname
[ "$srcname" == "$destname" ] || echo mv "$srcname" "$destname"
done
exec 5<&-
exec 6<&-
rm dateinamen.src dateinamen.dest

# Dann die symlinks und Dateien
find ./ -type l -or -type f > dateinamen.src
cp dateinamen.src dateinamen.dest
recode -f UTF-8..US-ASCII dateinamen.dest
exec 5<dateinamen.src
exec 6<dateinamen.dest
while read -u 5 srcname; do
read -u 6 destname
[ "$srcname" == "$destname" ] || echo mv "$srcname" "$destname"
done
exec 5<&-
exec 6<&-
rm dateinamen.src dateinamen.dest

machen. Natürlich musst Du bei recode in dem Fall als Urprungscodierung das
angeben, was Du tatsächlich als Codierung hast. Wenn obiges funktioniert,
kannst Du anschließend die "echo" vor "mv" entfernen und bekommst so die
Umbenennung statt nur die Ausgabe derselben.

Gruß
Markus
Heiko Schlenker
2008-08-04 18:24:32 UTC
Permalink
Post by Markus Kohm
#!/bin/bash
# Zuerst die Verzeichnisse
find ./ -type d | sort > dateinamen.src
cp dateinamen.src dateinamen.dest
recode -f UTF-8..US-ASCII dateinamen.dest
Mithilfe von convmv(1) lässt sich das Unterfangen vereinfachen. ;-)

#v+
Post by Markus Kohm
whatis convmv
convmv (1) - converts filenames from one encoding to another
#v-

SCNR, Heiko
--
Neu im Usenet? -> http://www.kirchwitz.de/~amk/dni/
Linux-Anfänger(in)? -> http://www.dcoul.de/infos/
Fragen zu KDE/GNOME? -> de.comp.os.unix.apps.{kde,gnome}
Passende Newsgroup gesucht? -> http://groups.google.com/groups?as_umsgid=dcoul-***@luv.does-not-exist.org
Michael Schmarck
2008-08-05 07:28:28 UTC
Permalink
Post by Markus Kohm
Post by Michael Schmarck
Bei einem SFX muss der Anwender nur auf die Datei einen Doppelklick
machen, und es passiert was.
[...]
Post by Markus Kohm
Post by Michael Schmarck
Im übrigen frage ich mich echt, was .tar und SFX mit dem Thema
(siehe Subject!) zu tun hat.
Na schön, dann passen wir den Betreff eben an das inzwischen geänderte
Thema an.
Na, geht doch.
Post by Markus Kohm
Dumm nur, dass ich oben eigentlich schon wieder auf das
ursprüngliche Thema zurückgekommen bin ...
Dann solltest Du das Subject anpassen. Zumal Du "oben" nicht
auf das ursprüngliche Thema zurückgekommen bist (auch nicht
in dem Teil, den ich weggeschnitten habe, denn dort ging's um
die Malware Problematik, falls ich Dich recht verstanden habe).
Post by Markus Kohm
Post by Michael Schmarck
Ob man's glaubt oder auch nicht, aber
ich habe den Betreff nicht zufälligerweise so gewählt, wie ich ihn
gewählt habe. Mir geht's nicht um die Frage wie Daten ausgetauscht
werden könnten, sondern wie Dateinamen so geändert werden
könnten, das sie zu Windows, UDF bzw. ISO9660 kompatibel sind.
Es ist immer wieder schön, wenn Leute, die eine Frage haben, danach auch
noch bestimmen wollen, was andere darauf antworten und aus der
entstehenden Diskussion machen dürfen.
Blödsinn. Es ist ganz sicher nicht falsch, wenn versucht wird, eine
Diskussion so zu "lenken", das sie bei dem Thema bleibt, das man
selber braucht.
Post by Markus Kohm
Willkommen im Usenet!
So ein Schwachsinn. Worum es in der Diskussion geht, steht im Betreff.
Und im Betreff stand:"Dateinamen Windows, UDF (DVD) bzw. ISO9660 (CD)
kompatibel machen". Ich finde es hingegen immer wieder schön, wenn
irgendwelche Leute "Tipps" geben, die aber auch so rein gar nichts
mit dem Thema zu tun haben.

Und nein, Kathinkas Law ist kein Freibrief.

Und was ich auch "toll" finde, sind Verallgemeinerungen. Es geht/ging
mir nicht darum, ein Produkt für den "Massenmarkt" herzustellen. Was
ich wollte, habe ich ziemlich genau im OP dargelegt, wie ich denke. Wobei
ich die Zusatzeinschränkung "keine Installation von Drittprogrammen"
erst später genannt habe - anderseits ist die Zusatzinformation auch
überflüssig, da sie nichts mit der im OP gestellten Frage zu tun hat.
Post by Markus Kohm
Post by Michael Schmarck
Und im übrigen ist natürlich auch das (also auspacken) schon eine
Installationsart.
Schade, ich muss jetzt doch nochmal auf das ursprüngliche Thema zurück
kommen: Das Auspacken kannst Du doch bereits machen.
Wie?
Post by Markus Kohm
Einfach tar.exe,
gunzip.exe ausgepackt mit auf die CD/DVD packen. Dazu packst Du dann noch
ein readme.txt (natürlich mit CRLF als Zeilenenden) oder readme.html und
gut ist.
Und durch die readme.html/.txt entpackt sich das Zeugs?

Will sehen!

Das würde ich wirklich gerne sehen. Magst Du vlt. ein Video oder so
"drehen" (und bei YouTube oder was weiss ich uploaden), indem Du
zeigst, wie sich die Dateien von selbst entpacken, nur weil es eine
readme.txt bzw. readme.html gibt?
Post by Markus Kohm
Damit sollte die Länge der Dateinamen schon einmal kein Problem
mehr sein
Durch eine Textdatei hat man keine Probleme mehr mit Dateinamen?
Verstehe ich nicht.

Michael
Michael Schmarck
2008-08-04 13:59:53 UTC
Permalink
Post by Markus Kohm
tar, gunzip, bzip2 und ähnliche Werkzeuge muss man normalerweise nicht
installieren, sondern allenfalls auspacken
Und im übrigen ist natürlich auch das (also auspacken) schon eine
Installationsart.

Michael
Joerg Schilling
2008-08-05 08:10:18 UTC
Permalink
RAR ist kein Standard und daher nicht fᅵr Archivierung zu empfehlen.
Allerdings lÀsst sich RAR unter Windows auch DAU-kompatibel bedienen,
da man mit RAR auch SFX (selbstentpackende Dateien) erstellen kann.
Es wÃŒrde also keine .rar-Datei weiteregegeben werden, sondern eine
.exe-Datei.
Was wenig nützt, wenn der Empfänger das Archiv nicht auspacken kann weil
RAR kein Standard ist.

TAR gibt es hingegen überall.
--
EMail:***@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
***@cs.tu-berlin.de (uni)
***@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Michael Schmarck
2008-08-05 12:45:26 UTC
Permalink
Post by Michael Schmarck
RAR ist kein Standard und daher nicht f�r Archivierung zu empfehlen.
Allerdings lässt sich RAR unter Windows auch DAU-kompatibel bedienen,
da man mit RAR auch SFX (selbstentpackende Dateien) erstellen kann.
Es würde also keine .rar-Datei weiteregegeben werden, sondern eine
.exe-Datei.
Was wenig n�tzt, wenn der Empf�nger das Archiv nicht auspacken kann weil
RAR kein Standard ist.
Dh. Du hast nicht gelesen, was ich geschrieben habe?

Aber vlt. magst Du ja erläutern, warum ein Windows User eine .exe Datei
nicht ausführen kann. Kann Windows etwa .exe nicht mehr ausführen?
TAR gibt es hingegen �berall.
Nein, bei Windows XP nicht. Nur dann, wenn man es nachinstalliert.

Michael
Joerg Schilling
2008-08-05 14:47:43 UTC
Permalink
Post by Michael Schmarck
RAR ist kein Standard und daher nicht fᅵr Archivierung zu empfehlen.
Allerdings lÀsst sich RAR unter Windows auch DAU-kompatibel bedienen,
da man mit RAR auch SFX (selbstentpackende Dateien) erstellen kann.
Es wÃŒrde also keine .rar-Datei weiteregegeben werden, sondern eine
.exe-Datei.
Was wenig nᅵtzt, wenn der Empfᅵnger das Archiv nicht auspacken kann weil
RAR kein Standard ist.
Dh. Du hast nicht gelesen, was ich geschrieben habe?
Ich habe schon gelesen was Du geschrieben hast.....
Bei Dir bin ich mir da aber nicht so sicher.
--
EMail:***@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
***@cs.tu-berlin.de (uni)
***@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Michael Schmarck
2008-08-06 07:19:33 UTC
Permalink
Post by Joerg Schilling
Post by Michael Schmarck
Post by Michael Schmarck
RAR ist kein Standard und daher nicht f�r Archivierung zu empfehlen.
Allerdings lässt sich RAR unter Windows auch DAU-kompatibel bedienen,
da man mit RAR auch SFX (selbstentpackende Dateien) erstellen kann.
Es würde also keine .rar-Datei weiteregegeben werden, sondern eine
.exe-Datei.
Was wenig n�tzt, wenn der Empf�nger das Archiv nicht auspacken kann weil
RAR kein Standard ist.
Dh. Du hast nicht gelesen, was ich geschrieben habe?
Ich habe schon gelesen was Du geschrieben hast.....
Und wieso schreibst Du dann, was Du geschrieben hast?
Post by Joerg Schilling
Bei Dir bin ich mir da aber nicht so sicher.
Sei Dir sicher.

Michael
Arno Welzel
2008-08-05 19:09:18 UTC
Permalink
Post by Joerg Schilling
RAR ist kein Standard und daher nicht fᅵr Archivierung zu empfehlen.
Allerdings lÀsst sich RAR unter Windows auch DAU-kompatibel bedienen,
da man mit RAR auch SFX (selbstentpackende Dateien) erstellen kann.
Es wÃŒrde also keine .rar-Datei weiteregegeben werden, sondern eine
.exe-Datei.
Was wenig nützt, wenn der Empfänger das Archiv nicht auspacken kann weil
RAR kein Standard ist.
Ähm - Michael schrieb doch, dass er keine RAR-Datei weitergibt, sondern
eine ausführbare Datei, die sich selbst entpackt.
Post by Joerg Schilling
TAR gibt es hingegen überall.
Es geht um Windows. Da gibt es kein TAR, bestenfalls ZIP seit Windows
XP. Und es ging darum, dass man eben *nicht* zusätzlich Tools
herunterladen und einrichten muss.
--
http://arnowelzel.de
http://de-rec-fahrrad.de
Joerg Schilling
2008-08-05 21:44:29 UTC
Permalink
Post by Arno Welzel
Post by Joerg Schilling
TAR gibt es hingegen überall.
Es geht um Windows. Da gibt es kein TAR, bestenfalls ZIP seit Windows
XP. Und es ging darum, dass man eben *nicht* zusätzlich Tools
herunterladen und einrichten muss.
Weist Du, ob er dieses RAR Binary in 10 Jahren noch starten kann?

TAR wäre da sicherer und bist Du sicher, daß nicht Vista schon heute
oder in ein paar Monaten mit einem TAR kommt?

Abgesehen davon habe ich in einem anderen Artikel die eigentliche
Frage beantwortet:

mkisofs (das richtige Programm) kann durchaus problemlos
in Rock Ridge 255 Byte lange Dateinamen und in UDF 254 Buchstaben
lange Dateinamen. Beides sind Standards die man auch in 10 Jahren
noch lesen können wird.
--
EMail:***@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
***@cs.tu-berlin.de (uni)
***@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Arno Welzel
2008-08-05 23:39:45 UTC
Permalink
Post by Joerg Schilling
Post by Arno Welzel
Post by Joerg Schilling
TAR gibt es hingegen überall.
Es geht um Windows. Da gibt es kein TAR, bestenfalls ZIP seit Windows
XP. Und es ging darum, dass man eben *nicht* zusätzlich Tools
herunterladen und einrichten muss.
Weist Du, ob er dieses RAR Binary in 10 Jahren noch starten kann?
Man Kontext.

Es reicht, wenn es *jetzt* vom Empfänger gestartet werden kann, da eine
Archivierung für die nächsten 10 Jahre nicht beabsichtigt ist. Und das
Win32-Binaries innerhalb der nöchsten paar Monate von Vista nicht mehr
startbar sind, ist äusserst unwahrscheinlich.

Ich zitiere aus <***@mid.individual.net>

"Was allerdings wenig nützt, wenn der Empfänger die Datei nicht
entpacken kann, da kein installiertes Programm mit TAR umgehen kann und
da kein zusätzliches Programm installiert werden soll."
Post by Joerg Schilling
TAR wäre da sicherer und bist Du sicher, daß nicht Vista schon heute
oder in ein paar Monaten mit einem TAR kommt?
Abgesehen davon habe ich in einem anderen Artikel die eigentliche
mkisofs (das richtige Programm) kann durchaus problemlos
in Rock Ridge 255 Byte lange Dateinamen und in UDF 254 Buchstaben
lange Dateinamen. Beides sind Standards die man auch in 10 Jahren
noch lesen können wird.
Ja, das ist korrekt und wenn es *NUR* darum ging, welches Archivformat
prinzipiell die sicherste Lösung für die *Archivierung* wäre, hast Du
vollkommen recht. So, wie ich im weiteren Verlauf den OP verstanden
habe, braucht er zusätzlich noch die Möglichkeit, dem Empfänger das
Ganze als "DAU-kompatibles", selbstextrahierendes Binary für Windows in
die Hand zu drücken - also ohne Eingabe einer Kommandozeile etc..
--
http://arnowelzel.de
http://de-rec-fahrrad.de
Michael Schmarck
2008-08-06 07:24:16 UTC
Permalink
Post by Arno Welzel
Post by Joerg Schilling
Post by Arno Welzel
Post by Joerg Schilling
TAR gibt es hingegen überall.
Es geht um Windows. Da gibt es kein TAR, bestenfalls ZIP seit Windows
XP. Und es ging darum, dass man eben *nicht* zusätzlich Tools
herunterladen und einrichten muss.
Weist Du, ob er dieses RAR Binary in 10 Jahren noch starten kann?
Man Kontext.
Exakt.
Post by Arno Welzel
Es reicht, wenn es *jetzt* vom Empfänger gestartet werden kann, da eine
Archivierung für die nächsten 10 Jahre nicht beabsichtigt ist.
Ganz genau.
Post by Arno Welzel
Und das
Win32-Binaries innerhalb der nöchsten paar Monate von Vista nicht mehr
startbar sind, ist äusserst unwahrscheinlich.
Eben.

[...]
Post by Arno Welzel
Post by Joerg Schilling
TAR wäre da sicherer und bist Du sicher, daß nicht Vista schon heute
oder in ein paar Monaten mit einem TAR kommt?
Abgesehen davon habe ich in einem anderen Artikel die eigentliche
mkisofs (das richtige Programm) kann durchaus problemlos
in Rock Ridge 255 Byte lange Dateinamen und in UDF 254 Buchstaben
lange Dateinamen. Beides sind Standards die man auch in 10 Jahren
noch lesen können wird.
Ja, das ist korrekt und wenn es *NUR* darum ging, welches Archivformat
prinzipiell die sicherste Lösung für die *Archivierung* wäre, hast Du
vollkommen recht.
Sehe ich auch so.
Post by Arno Welzel
So, wie ich im weiteren Verlauf den OP verstanden
habe, braucht er zusätzlich noch die Möglichkeit, dem Empfänger das
Ganze als "DAU-kompatibles", selbstextrahierendes Binary für Windows in
die Hand zu drücken - also ohne Eingabe einer Kommandozeile etc..
ALSO eigentlich möchte ich gar keine Archivdatei (sei's nun RAR, ZIP,
TAR oder was auch immer...) weitergeben, sondern, man beachte das
Subject, Dateien. Und bei den Quelldateien habe ich das Problem,
das sie "ungute" Dateinamen haben, weshalb ich nach einer Lösung
gesucht habe, die Dateinamen so umzuändern, das sie auf CD/DVD
gebrannt werden können. Man soll's nicht glauben, aber ich habe mir
durchaus etwas gedacht, als ich das OP geschrieben habe. Nicht
ohne Grund habe ich im OP nicht von irgendwelchen Archivformaten
gesprochen. Und wie man ja sieht, war es sehr gut, das nicht ich
mit tar & co. angefangen habe, da es hierbei nunmal eben
Interoperabilitätsprobleme gibt. Klar, ist Windows schuld, da Windows
nix brauchbares on-board hat. Sehe ich ja auch so. Nur ist nun mal
leider die Realität so, wie sie ist.

Michael
Michael Schmarck
2008-08-06 07:18:01 UTC
Permalink
Post by Joerg Schilling
Post by Arno Welzel
TAR gibt es hingegen �berall.
Es geht um Windows. Da gibt es kein TAR, bestenfalls ZIP seit Windows
XP. Und es ging darum, dass man eben *nicht* zus�tzlich Tools
herunterladen und einrichten muss.
Weist Du, ob er dieses RAR Binary in 10 Jahren noch starten kann?
Irrelevant (in diesem Fall). Genau das ist's, was mich manchmal so nervt:
Diese unsinnigen, überzogenen Verallgemeinerungen. Natürlich hast
Du recht, das für Archivierungszwecke oder für die großflächige Verteilung
von Archiven ein offenes Format besser ist.

Nur davon war nie die Rede.
Post by Joerg Schilling
Abgesehen davon habe ich in einem anderen Artikel die eigentliche
Stimmt - und dafür bin ich Dir auch sehr dankbar!

Michael
Ansgar Strickerschmidt
2008-08-06 07:18:16 UTC
Permalink
Post by Joerg Schilling
TAR gibt es hingegen überall.
Es geht um Windows. Da gibt es kein TAR, bestenfalls ZIP seit Windows XP.
ICEOWS kann z.B. tar(.gz) lesen. Klar, muss man dazuinstallieren, trägt
aber überhaupt nicht auf, weil nur eine Handvoll KB groß und im
Kontextmenü verankert.

Ansgar
--
Mails an die angegebene Adresse erreichen mich - oder auch nicht.
Nützliche Adresse gibt's bei Bedarf!
Mail to the given address may or may not reach me - useful address will be
given when required!
Michael Schmarck
2008-08-06 07:27:34 UTC
Permalink
Post by Ansgar Strickerschmidt
Post by Joerg Schilling
TAR gibt es hingegen überall.
Es geht um Windows. Da gibt es kein TAR, bestenfalls ZIP seit Windows XP.
ICEOWS kann z.B. tar(.gz) lesen. Klar, muss man dazuinstallieren, trägt
Und damit ist iceows raus aus dem Spiel.

Weisst's, bei Anwendern die schon damit überforder sind Ordner
anzulegen, bei solchen Anwendern braucht man/brauche ich nicht
mit der Installation von irgendwelchen Zusatztools kommen.
Post by Ansgar Strickerschmidt
aber überhaupt nicht auf, weil nur eine Handvoll KB groß und im
Kontextmenü verankert.
Also versteckt, also nicht sichtbar, also unbrauchbar.

Ich verstehe nicht, warum die Prämisse "keine Zusatztools installieren"
so schwer verständlich zu sein scheint. Ist mir wirklich ein Rätsel.

Michael
Ansgar Strickerschmidt
2008-08-06 07:55:15 UTC
Permalink
Am 06.08.2008, 09:27 Uhr, schrieb Michael Schmarck
Post by Michael Schmarck
Post by Ansgar Strickerschmidt
aber überhaupt nicht auf, weil nur eine Handvoll KB groß und im
Kontextmenü verankert.
Also versteckt, also nicht sichtbar, also unbrauchbar.
Wäre es so schwer, einmal rechts statt doppelt links zu klicken?

Abgesehen davon ist wohl wirklich erstmal convmv Dein Freund.
Und eine sinnvolle Benamsung von Dateien mit kürzeren Namen einführen?
Ich meine, "Tante-Lisa-rutscht-auf
einer-ausgelutschten-Melonenschale-aus-und-reißt-Oma-rückwärts-mit-in-den-Swimmingpool.jpg"
ist zwar sicher ein hübscher und beschreibender Name für ein Bild,
sinnvollerweise würde man das aber mit einer geeigneten Bildverwaltung
samt Verschlagwortung besser erledigen. Also einen Ordner
"Gartenparty_2008" anlegen und das Bild z.B "platsch_1.jpg" nennen.

Ansgar
--
Mails an die angegebene Adresse erreichen mich - oder auch nicht.
Nützliche Adresse gibt's bei Bedarf!
Mail to the given address may or may not reach me - useful address will be
given when required!
Michael Schmarck
2008-08-06 08:11:03 UTC
Permalink
Post by Ansgar Strickerschmidt
Am 06.08.2008, 09:27 Uhr, schrieb Michael Schmarck
Post by Michael Schmarck
Post by Ansgar Strickerschmidt
aber überhaupt nicht auf, weil nur eine Handvoll KB groß und im
Kontextmenü verankert.
Also versteckt, also nicht sichtbar, also unbrauchbar.
Wäre es so schwer, einmal rechts statt doppelt links zu klicken?
Ja.
Post by Ansgar Strickerschmidt
Abgesehen davon ist wohl wirklich erstmal convmv Dein Freund.
Genau. Das ganz rumgehampel hier entstand ja nur, weil unbedingt
Archivformate diskutiert werden sollten, obwohl sie ganz bestimmt
nicht die Lösung des Problemes sind.
Post by Ansgar Strickerschmidt
Und eine sinnvolle Benamsung von Dateien mit kürzeren Namen einführen?
Nein, denn die gibt's schon, ist aber leider nicht zu Windows kompatibel.
Post by Ansgar Strickerschmidt
Ich meine, "Tante-Lisa-rutscht-auf
einer-ausgelutschten-Melonenschale-aus-und-reißt-Oma-rückwärts-mit-in-den-Swimmingpool.jpg"
ist zwar sicher ein hübscher und beschreibender Name für ein Bild,
sinnvollerweise würde man das aber mit einer geeigneten Bildverwaltung
samt Verschlagwortung besser erledigen.
Ich mache beides, um nicht voll und ganz auf ein Programm angewiesen
zu sein.
Post by Ansgar Strickerschmidt
Also einen Ordner
"Gartenparty_2008" anlegen und das Bild z.B "platsch_1.jpg" nennen.
Sinnvollerweise würde das Bild dann "[2008-08-01 13:34:02] Tante Lisa
rutscht auf 'ner Melonenschale aus & fällt dann hin.jpg" heissen, damit
man schon direkt beim Bildnamen erkennen kann, was das ist.

Michael
Christian Lorch
2008-08-06 10:04:36 UTC
Permalink
Post by Michael Schmarck
Post by Ansgar Strickerschmidt
Am 06.08.2008, 09:27 Uhr, schrieb Michael Schmarck
Post by Michael Schmarck
Post by Ansgar Strickerschmidt
aber überhaupt nicht auf, weil nur eine Handvoll KB groß und im
Kontextmenü verankert.
Also versteckt, also nicht sichtbar, also unbrauchbar.
Wäre es so schwer, einmal rechts statt doppelt links zu klicken?
Ja.
Post by Ansgar Strickerschmidt
Abgesehen davon ist wohl wirklich erstmal convmv Dein Freund.
Genau. Das ganz rumgehampel hier entstand ja nur, weil unbedingt
Archivformate diskutiert werden sollten, obwohl sie ganz bestimmt
nicht die Lösung des Problemes sind.
Post by Ansgar Strickerschmidt
Und eine sinnvolle Benamsung von Dateien mit kürzeren Namen einführen?
Nein, denn die gibt's schon, ist aber leider nicht zu Windows kompatibel.
Post by Ansgar Strickerschmidt
Ich meine, "Tante-Lisa-rutscht-auf
einer-ausgelutschten-Melonenschale-aus-und-reißt-Oma-rückwärts-mit-in-den-Swimmingpool.jpg"
Post by Michael Schmarck
Post by Ansgar Strickerschmidt
ist zwar sicher ein hübscher und beschreibender Name für ein Bild,
sinnvollerweise würde man das aber mit einer geeigneten Bildverwaltung
samt Verschlagwortung besser erledigen.
Ich mache beides, um nicht voll und ganz auf ein Programm angewiesen
zu sein.
Post by Ansgar Strickerschmidt
Also einen Ordner
"Gartenparty_2008" anlegen und das Bild z.B "platsch_1.jpg" nennen.
Sinnvollerweise würde das Bild dann "[2008-08-01 13:34:02] Tante Lisa
rutscht auf 'ner Melonenschale aus & fällt dann hin.jpg" heissen, damit
man schon direkt beim Bildnamen erkennen kann, was das ist.
nö. damits sinnvoll wird müsstest Du die ganzen Sonderzeichen weglassen.
Also auf jeden Fall die Doppelpunkte in der Uhrzeit (damit hatte ich auf
FAT32 letztens Probleme), ' & [ ] könnten auch problematisch sein. Aber
dass die Zeichen halt weg, dann gibts keine (nur noch sehr wenige)
Austauschprobleme.
Ich lege Ordner mit 2008-08-01 Gartenparty an, die Dateien darin heißen dann
ähnlich wie 2008-08-01 13:34:02-0.jpg. Die Null hinten ist wichtig falls
mal mehrere Dateien zur gleichen Sekunde geknipst werden (von schnellen
Apparaten oder falls man mehrere Kameras zusammenführen möchte.

Mir wäre das dateinamenmäßige "Verschlagworten" allerdings zu kompliziert,
ich mach das nur über Tags (die in der Datei selbst gespeichert werden),
also das kopieren überstehen.

Grüße

Christian
--
Christian Lorch - der nett.Zwerg-Berater
Thomas Kosch
2008-07-28 07:47:43 UTC
Permalink
Post by Niklaus Kuehnis
Post by Michael Schmarck
Und tar kann nicht so einfach
auf Windows XP verwendet werden (ohne Zusatztools).
Ja, da nimmt man z.B. cygwin.
Ich kann mir auch ein Loch ins Knie bohren. WinZip und 7-zip können
damit Problemlos umgehen.

ttyl8er, t.k.
--
Life is Xerox, and you're just a copy
Heiko Schlenker
2008-07-28 11:19:58 UTC
Permalink
Post by Thomas Kosch
Post by Niklaus Kuehnis
Post by Michael Schmarck
Und tar kann nicht so einfach
auf Windows XP verwendet werden (ohne Zusatztools).
Ja, da nimmt man z.B. cygwin.
Ich kann mir auch ein Loch ins Knie bohren. WinZip und 7-zip können
damit Problemlos umgehen.
Sie können auch nicht wissen, welcher Zeichensatz beim Einpacken
verwendet worden ist, weil die Spezifikation des ZIP-Formats kein
Feld vorsieht, dass entsprechende Informationen aufnehmen kann, IIRC.
Sie "raten", grob gesagt.

Dateinamen, die Zeichen jenseits des ASCII-Zeichensatzes enthalten,
sind ein steter Quell von /Interoperabilitätsproblemen/. Und wenn
dann auch noch verschiedene Anwendungen, z.B. zip(1) statt WinZip,
beim Ein- und Auspacken zum Einsatz kommen ...

Gruß, Heiko
--
Neu im Usenet? -> http://www.kirchwitz.de/~amk/dni/
Linux-Anfänger(in)? -> http://www.dcoul.de/infos/
Fragen zu KDE/GNOME? -> de.comp.os.unix.apps.{kde,gnome}
Passende Newsgroup gesucht? -> http://groups.google.com/groups?as_umsgid=dcoul-***@luv.does-not-exist.org
Thomas Kosch
2008-07-29 06:56:04 UTC
Permalink
Post by Heiko Schlenker
Post by Thomas Kosch
Post by Niklaus Kuehnis
Post by Michael Schmarck
Und tar kann nicht so einfach
auf Windows XP verwendet werden (ohne Zusatztools).
Ja, da nimmt man z.B. cygwin.
Ich kann mir auch ein Loch ins Knie bohren. WinZip und 7-zip können
damit Problemlos umgehen.
Sie können auch nicht wissen, welcher Zeichensatz beim Einpacken
verwendet worden ist, weil die Spezifikation des ZIP-Formats kein
Feld vorsieht, dass entsprechende Informationen aufnehmen kann, IIRC.
Sie "raten", grob gesagt.
Vielleich ließt du noch mal was hier 13 Zeilen weiter oben steht.

ttyl8er, t.k.
--
Life is Xerox, and you're just a copy
Heiko Schlenker
2008-07-29 11:32:14 UTC
Permalink
Post by Thomas Kosch
Post by Heiko Schlenker
Post by Thomas Kosch
Post by Niklaus Kuehnis
Post by Michael Schmarck
Und tar kann nicht so einfach
auf Windows XP verwendet werden (ohne Zusatztools).
Ja, da nimmt man z.B. cygwin.
Ich kann mir auch ein Loch ins Knie bohren. WinZip und 7-zip können
damit Problemlos umgehen.
Sie können auch nicht wissen, welcher Zeichensatz beim Einpacken
verwendet worden ist, weil die Spezifikation des ZIP-Formats kein
Feld vorsieht, dass entsprechende Informationen aufnehmen kann, IIRC.
Sie "raten", grob gesagt.
Vielleich ließt du noch mal was hier 13 Zeilen weiter oben steht.
Na, mal gucken:
| >>>>> Und tar kann nicht so einfach

Aha. ;-)

Ach, Du willst darauf hinaus, dass WinZip und 7-zip Tar-Archive
verarbeiten können? Im Zusammenhang mit dem Einsatz verschiedener
Anwendungen (auf verschiedenen Systemen) habe ich ja etwas
geschrieben. Und im Falle von Tar bekommt man u.U. bereits dann
Probleme, wenn der eine GNU-Tar (einer bestimmten Version) und der
Empfänger eine andere BSD- oder POSIX-konforme Tar-Implementierung
verwendet.

Auch in der Spezifikation des Tar-Formats gibt es kein Feld, dass
Informationen über den verwendeten Zeichensatz enthält, IIRC.

Der POSIX-Standard beschreibt, wie /portable/ Dateinamen aussehen
sollten
(<http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html#tag_03_276>):
| The set of characters from which portable filenames are constructed.
|
| A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
| a b c d e f g h i j k l m n o p q r s t u v w x y z
| 0 1 2 3 4 5 6 7 8 9 . _ -

Gruß, Heiko
--
Neu im Usenet? -> http://www.kirchwitz.de/~amk/dni/
Linux-Anfänger(in)? -> http://www.dcoul.de/infos/
Fragen zu KDE/GNOME? -> de.comp.os.unix.apps.{kde,gnome}
Passende Newsgroup gesucht? -> http://groups.google.com/groups?as_umsgid=dcoul-***@luv.does-not-exist.org
Joerg Schilling
2008-08-04 10:52:00 UTC
Permalink
Post by Heiko Schlenker
Ach, Du willst darauf hinaus, dass WinZip und 7-zip Tar-Archive
verarbeiten können? Im Zusammenhang mit dem Einsatz verschiedener
Anwendungen (auf verschiedenen Systemen) habe ich ja etwas
geschrieben. Und im Falle von Tar bekommt man u.U. bereits dann
Probleme, wenn der eine GNU-Tar (einer bestimmten Version) und der
Empfänger eine andere BSD- oder POSIX-konforme Tar-Implementierung
verwendet.
Von GNU tar muß man sowohl aus Gründen der Standardkonformität, als auch
wegen der großen Anzahl bekannter Implementierungsfehler abraten.
Besser ist star:

ftp://ftp.berlios.de/pub/star/
Post by Heiko Schlenker
Auch in der Spezifikation des Tar-Formats gibt es kein Feld, dass
Informationen über den verwendeten Zeichensatz enthält, IIRC.
Das ist falsch -> siehe POSIX "pax" Doku.
Post by Heiko Schlenker
Der POSIX-Standard beschreibt, wie /portable/ Dateinamen aussehen
sollten
| The set of characters from which portable filenames are constructed.
|
| A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
| a b c d e f g h i j k l m n o p q r s t u v w x y z
| 0 1 2 3 4 5 6 7 8 9 . _ -
Und POSIX sagt nur man soll diesen Zeichensatz als "Rückfall" vewenden.
--
EMail:***@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
***@cs.tu-berlin.de (uni)
***@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Heiko Schlenker
2008-08-04 12:42:34 UTC
Permalink
Post by Joerg Schilling
Post by Heiko Schlenker
Ach, Du willst darauf hinaus, dass WinZip und 7-zip Tar-Archive
verarbeiten können? Im Zusammenhang mit dem Einsatz verschiedener
Anwendungen (auf verschiedenen Systemen) habe ich ja etwas
geschrieben. Und im Falle von Tar bekommt man u.U. bereits dann
Probleme, wenn der eine GNU-Tar (einer bestimmten Version) und der
Empfänger eine andere BSD- oder POSIX-konforme Tar-Implementierung
verwendet.
Von GNU tar muß man sowohl aus Gründen der Standardkonformität, als auch
wegen der großen Anzahl bekannter Implementierungsfehler abraten.
Wenn schon Eigenwerbung, dann sollte sie wenigstens im betreffenden
Kontext (hier: Interoperabilitätsprobleme) einen Sinn ergeben.
Post by Joerg Schilling
Post by Heiko Schlenker
Auch in der Spezifikation des Tar-Formats gibt es kein Feld, dass
Informationen über den verwendeten Zeichensatz enthält, IIRC.
Das ist falsch -> siehe POSIX "pax" Doku.
Ich sprach nicht vom 'extended tar interchange format', sondern vom
kleinsten gemeinsamen Nenner hinsichtlich des Tar-Formats. Zudem
kann ich auf die Schnelle keinen entsprechenden Eintrag im
'Extended tar Header Block'
<http://www.opengroup.org/onlinepubs/007908799/xcu/pax.html#tag_001_014_1700_006>
finden.
Post by Joerg Schilling
Post by Heiko Schlenker
Der POSIX-Standard beschreibt, wie /portable/ Dateinamen aussehen
sollten
[...]
Post by Joerg Schilling
Und POSIX sagt nur man soll diesen Zeichensatz als "Rückfall" vewenden.
Aus <http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html#tag_03_170>:
| 3.170 Filename Portability
|
| Filenames should be constructed from the portable filename character
| set because the use of other characters can be confusing or
| ambiguous in certain contexts.

Aus <http://www.opengroup.org/onlinepubs/007908799/xcu/pax.html#tag_001_014_1700_006>:
| For maximum portability between implementations, names should be
| selected from characters represented by the portable filename
| character set as octets with the most significant bit zero.


Apropos Standardkonformität: Deine Postings sind nicht
standardkonform (Stichwort: MIME).

Gruß, Heiko
--
Neu im Usenet? -> http://www.kirchwitz.de/~amk/dni/
Linux-Anfänger(in)? -> http://www.dcoul.de/infos/
Fragen zu KDE/GNOME? -> de.comp.os.unix.apps.{kde,gnome}
Passende Newsgroup gesucht? -> http://groups.google.com/groups?as_umsgid=dcoul-***@luv.does-not-exist.org
Joerg Schilling
2008-08-05 08:21:26 UTC
Permalink
Post by Heiko Schlenker
Post by Joerg Schilling
Post by Heiko Schlenker
Auch in der Spezifikation des Tar-Formats gibt es kein Feld, dass
Informationen über den verwendeten Zeichensatz enthält, IIRC.
Das ist falsch -> siehe POSIX "pax" Doku.
Ich sprach nicht vom 'extended tar interchange format', sondern vom
kleinsten gemeinsamen Nenner hinsichtlich des Tar-Formats. Zudem
kann ich auf die Schnelle keinen entsprechenden Eintrag im
'Extended tar Header Block'
<http://www.opengroup.org/onlinepubs/007908799/xcu/pax.html#tag_001_014_1700_006>
finden.
Nun, wir leben im Jahr 2008 und nicht im Jahr 1988.
Heutzutage (seit 2001 verabschiedeter Standard) ist das von mir beschriebene
und 1998 definierte erweiterte TAR Format ein üblicher implementierter
Standard.

Hättest Du die aktuelle POSIX Doku (statt der UNIX-98 Version die kein POSIX
ist) gelesen, dann hättest Du gefunden daß die Dateinamen in UTF-8 kodiert
sind. Leider ist in der aktuellen Onlineversion noch nichts darüber enthalten,
das wie uns mal darauf geeinigt hatten das "RAW" auch als Datenamenkodierung
zulässig ist um Backups zu ermöglichen. Da muß ich wohl mal nachhaken.
--
EMail:***@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
***@cs.tu-berlin.de (uni)
***@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Arno Welzel
2008-08-04 17:41:03 UTC
Permalink
Post by Joerg Schilling
Post by Heiko Schlenker
Ach, Du willst darauf hinaus, dass WinZip und 7-zip Tar-Archive
verarbeiten können? Im Zusammenhang mit dem Einsatz verschiedener
Anwendungen (auf verschiedenen Systemen) habe ich ja etwas
geschrieben. Und im Falle von Tar bekommt man u.U. bereits dann
Probleme, wenn der eine GNU-Tar (einer bestimmten Version) und der
Empfänger eine andere BSD- oder POSIX-konforme Tar-Implementierung
verwendet.
Von GNU tar muß man sowohl aus Gründen der Standardkonformität, als auch
wegen der großen Anzahl bekannter Implementierungsfehler abraten.
ftp://ftp.berlios.de/pub/star/
Zumindest solltest Du dann auch bei deinen Postings auf
standardkonformität achten - ansonsten hinterlässt der Hinweis einen
komischen Nachgeschmack.
--
http://arnowelzel.de
http://de-rec-fahrrad.de
Michael Schmarck
2008-07-28 11:25:20 UTC
Permalink
Post by Thomas Kosch
Post by Niklaus Kuehnis
Post by Michael Schmarck
Und tar kann nicht so einfach
auf Windows XP verwendet werden (ohne Zusatztools).
Ja, da nimmt man z.B. cygwin.
Ich kann mir auch ein Loch ins Knie bohren. WinZip und 7-zip können
damit Problemlos umgehen.
Womit kann WinZip problemlos umgehen? Mit Dateinamen in einem
fremden Zeichensatz?

Wenn ja: Nein, damit kann Winzip nicht umgehen. Bzw. es kann damit
umgehen, aber es werden dann "verhunzte" Dateinamen erzeugt. Unschön.

Michael
Thomas Kosch
2008-07-29 06:56:04 UTC
Permalink
Post by Michael Schmarck
Post by Thomas Kosch
Post by Niklaus Kuehnis
Post by Michael Schmarck
Und tar kann nicht so einfach
auf Windows XP verwendet werden (ohne Zusatztools).
Ja, da nimmt man z.B. cygwin.
Ich kann mir auch ein Loch ins Knie bohren. WinZip und 7-zip können
damit Problemlos umgehen.
Womit kann WinZip problemlos umgehen? Mit Dateinamen in einem
fremden Zeichensatz?
Wie währe es mal mit lesen?

ttyl8er, t.k.
--
Life is Xerox, and you're just a copy
Michael Schmarck
2008-07-30 08:20:10 UTC
Permalink
Post by Thomas Kosch
Post by Michael Schmarck
Post by Thomas Kosch
Post by Niklaus Kuehnis
Post by Michael Schmarck
Und tar kann nicht so einfach
auf Windows XP verwendet werden (ohne Zusatztools).
Ja, da nimmt man z.B. cygwin.
Ich kann mir auch ein Loch ins Knie bohren. WinZip und 7-zip können
damit Problemlos umgehen.
Womit kann WinZip problemlos umgehen? Mit Dateinamen in einem
fremden Zeichensatz?
Wie währe es mal mit lesen?
Führst Du Selbstgespräche?

Wie gesagt:

Wenn ja: Nein, damit kann Winzip nicht umgehen. Bzw. es kann damit
umgehen, aber es werden dann "verhunzte" Dateinamen erzeugt. Unschön.
Post by Thomas Kosch
Wie währe es mal mit lesen?
Dito.

Aber vlt. magst Du ja noch erläutern, das Du mit "umgehen" meintest.

Und wie währe es, wenn Du mal liest, was ich schrieb: "*OHNE* *ZUSATZ-
TOOLS*". Mich würde dann noch interessieren, inwiefern WinZip oder
7-Zip diese Bedingung erfüllen.

MfG

Michael
Thomas Kosch
2008-07-30 10:53:53 UTC
Permalink
Post by Michael Schmarck
Post by Thomas Kosch
Post by Michael Schmarck
Post by Thomas Kosch
Post by Niklaus Kuehnis
Post by Michael Schmarck
Und tar kann nicht so einfach
auf Windows XP verwendet werden (ohne Zusatztools).
Ja, da nimmt man z.B. cygwin.
Ich kann mir auch ein Loch ins Knie bohren. WinZip und 7-zip können
damit Problemlos umgehen.
Womit kann WinZip problemlos umgehen? Mit Dateinamen in einem
fremden Zeichensatz?
Wie währe es mal mit lesen?
Führst Du Selbstgespräche?
Ich lasse jetzt extra das ganze stehen.
Post by Michael Schmarck
Wenn ja: Nein, damit kann Winzip nicht umgehen. Bzw. es kann damit
Du befauptest also WinZip kann nicht mit tar Archiven umgehen?
Post by Michael Schmarck
umgehen, aber es werden dann "verhunzte" Dateinamen erzeugt. Unschön.
Oder jetzt doch, aber niurgendwie auch nicht?
Post by Michael Schmarck
Post by Thomas Kosch
Wie währe es mal mit lesen?
Dito.
Aber vlt. magst Du ja noch erläutern, das Du mit "umgehen" meintest.
Und wie währe es, wenn Du mal liest, was ich schrieb: "*OHNE* *ZUSATZ-
TOOLS*". Mich würde dann noch interessieren, inwiefern WinZip oder
7-Zip diese Bedingung erfüllen.
Irgendwann wird dier vielleicht auffallen das ich nicht dir, sondern
Niklaus geantwortet habe.

ttyl8er, t.k.
--
Life is Xerox, and you're just a copy
Michael Schmarck
2008-07-31 07:43:24 UTC
Permalink
Post by Thomas Kosch
Post by Michael Schmarck
Post by Thomas Kosch
Post by Michael Schmarck
Post by Thomas Kosch
Post by Niklaus Kuehnis
Post by Michael Schmarck
Und tar kann nicht so einfach
auf Windows XP verwendet werden (ohne Zusatztools).
Ja, da nimmt man z.B. cygwin.
Ich kann mir auch ein Loch ins Knie bohren. WinZip und 7-zip können
damit Problemlos umgehen.
Womit kann WinZip problemlos umgehen? Mit Dateinamen in einem
fremden Zeichensatz?
Wie währe es mal mit lesen?
Führst Du Selbstgespräche?
Ich lasse jetzt extra das ganze stehen.
Okay.
Post by Thomas Kosch
Post by Michael Schmarck
Wenn ja: Nein, damit kann Winzip nicht umgehen. Bzw. es kann damit
Du befauptest also WinZip kann nicht mit tar Archiven umgehen?
Wie währe es mit lesen?
Post by Thomas Kosch
Post by Michael Schmarck
umgehen, aber es werden dann "verhunzte" Dateinamen erzeugt. Unschön.
Oder jetzt doch, aber niurgendwie auch nicht?
Lies einfach, was ich geschrieben habe.
Post by Thomas Kosch
Post by Michael Schmarck
Post by Thomas Kosch
Wie währe es mal mit lesen?
Dito.
Aber vlt. magst Du ja noch erläutern, das Du mit "umgehen" meintest.
Und wie währe es, wenn Du mal liest, was ich schrieb: "*OHNE* *ZUSATZ-
TOOLS*". Mich würde dann noch interessieren, inwiefern WinZip oder
7-Zip diese Bedingung erfüllen.
Irgendwann wird dier vielleicht auffallen das ich nicht dir, sondern
Niklaus geantwortet habe.
Welche Rolle spielt das? Ausser "keiner", meine ich?

Michael
Niklaus Kuehnis
2008-07-31 08:14:22 UTC
Permalink
Post by Michael Schmarck
Post by Thomas Kosch
Wie währe es mal mit lesen?
Wie währe es mit lesen?
Am besten den Rechtschreibe-Duden.

scnr,
Niklaus
Heike C. Zimmerer
2008-07-31 08:37:45 UTC
Permalink
Post by Niklaus Kuehnis
Post by Michael Schmarck
Post by Thomas Kosch
Wie währe es mal mit lesen?
Wie währe es mit lesen?
Am besten den Rechtschreibe-Duden.
:) Was lange währt ...
Juergen Ilse
2008-07-31 17:20:59 UTC
Permalink
Post by Heike C. Zimmerer
Post by Niklaus Kuehnis
Post by Michael Schmarck
Post by Thomas Kosch
Wie währe es mal mit lesen?
Wie währe es mit lesen?
Am besten den Rechtschreibe-Duden.
:) Was lange währt ...
Um zum restlichen Thread zu pssen, müsstest du jetzt aber schreiben:

:) Was lange wärt ...

Tschüss,
Jürgen Ilse (***@usenet-verwaltung.de)
--
Ein Domainname (auch wenn er Teil einer Mailadresse ist) ist nur ein Name,
nicht mehr und nicht weniger ...
Michael Schmarck
2008-07-31 08:39:44 UTC
Permalink
Post by Niklaus Kuehnis
Post by Michael Schmarck
Post by Thomas Kosch
Wie währe es mal mit lesen?
Wie währe es mit lesen?
Am besten den Rechtschreibe-Duden.
Ich habe ihn nur zitiert :)

Michael

PS: Dehn Duden könnte ich aber ächt ma' lesen, stimmt schon...
Martin Schnitkemper
2008-07-27 12:00:37 UTC
Permalink
Post by Michael Schmarck
Problem: tar hat keine Information darüber, welcher Zeichensatz
auf dem Quellsystem verwendet wurde. Und tar kann nicht so einfach
auf Windows XP verwendet werden (ohne Zusatztools).
Das sollte aber nicht das Problem sein, sich ein tar unter Windows zu
installieren.
Post by Michael Schmarck
Bei ZIP gibt's auch das Zeichensatzproblem. Und RAR ist auch
Mit den Optionen -K und -O kann man die Dateinamen auf ein Windows-
verträgliches Format konvertieren.

Im Zweifel die Dateien auf eine neue Partition kopieren und diese zuvor mit
dem richtigen Zeichensatz mounten. Dann stimmen auch die Dateinamen in TAR
und ZIP.

Martin.
--
OS: openSUSE 10.2 (i586)
Kernel: 2.6.18.8-0.10-default
KDE: 3.5.9 "release 65.1"
Michael Schmarck
2008-07-27 18:02:00 UTC
Permalink
Post by Martin Schnitkemper
Post by Michael Schmarck
Problem: tar hat keine Information darüber, welcher Zeichensatz
auf dem Quellsystem verwendet wurde. Und tar kann nicht so einfach
auf Windows XP verwendet werden (ohne Zusatztools).
Das sollte aber nicht das Problem sein, sich ein tar unter Windows zu
installieren.
Doch, ist es.
Post by Martin Schnitkemper
Post by Michael Schmarck
Bei ZIP gibt's auch das Zeichensatzproblem. Und RAR ist auch
Mit den Optionen -K und -O kann man die Dateinamen auf ein Windows-
verträgliches Format konvertieren.
Wovon sind -K und -O Optionen? Weder bei rar von RAR 3.80
beta 3 (also der akt. Version) noch bei zip (Infozip Zip 2.32 (June
19th 2006)) find ich -K und/oder -O in den Ausgaben von "--help" (bzw.
-h).
Post by Martin Schnitkemper
Im Zweifel die Dateien auf eine neue Partition kopieren und diese zuvor mit
dem richtigen Zeichensatz mounten. Dann stimmen auch die Dateinamen in TAR
und ZIP.
Nur das sich leider Dateien mit zu langen Dateinamen gar nicht erst
kopieren lassen... Und solche mit illegalen Zeichen (wie dem :)
auch nicht.

Michael
Martin Schnitkemper
2008-07-27 19:09:26 UTC
Permalink
Post by Michael Schmarck
Doch, ist es.
Und welches?
Post by Michael Schmarck
Wovon sind -K und -O Optionen? Weder bei rar von RAR 3.80
beta 3 (also der akt. Version) noch bei zip (Infozip Zip 2.32 (June
19th 2006)) find ich -K und/oder -O in den Ausgaben von "--help" (bzw.
-h).
Das ist in den manpages von zip beschrieben, --help gibt nur die wichtigsten
aber nicht alle Optionen aus.
Post by Michael Schmarck
Nur das sich leider Dateien mit zu langen Dateinamen gar nicht erst
kopieren lassen... Und solche mit illegalen Zeichen (wie dem :)
auch nicht.
Dann macht es auch keinen Sinn, Dateinamen mit unzulässigen Zeichen auf eine
CD/DVD oder in ein Archiv zu übernehmen, weil diese Dateien auf dem
Zielsystem in der Form sowieso nicht mehr angelegt werden können.

Das hat auch nichts mehr mit dem verwendeten Zeichensatz zu tun, sondern mit
den Eigenarten des Dateisystems.

Martin.
--
OS: openSUSE 10.2 (i586)
Kernel: 2.6.18.8-0.10-default
KDE: 3.5.9 "release 65.1"
Michael Schmarck
2008-07-28 06:36:32 UTC
Permalink
Post by Martin Schnitkemper
Post by Michael Schmarck
Doch, ist es.
Und welches?
Die Installation und das benutzen des Programmes.
Post by Martin Schnitkemper
Post by Michael Schmarck
Wovon sind -K und -O Optionen? Weder bei rar von RAR 3.80
beta 3 (also der akt. Version) noch bei zip (Infozip Zip 2.32 (June
19th 2006)) find ich -K und/oder -O in den Ausgaben von "--help" (bzw.
-h).
Das ist in den manpages von zip beschrieben, --help gibt nur die
wichtigsten aber nicht alle Optionen aus.
Danke.
Post by Martin Schnitkemper
Post by Michael Schmarck
Nur das sich leider Dateien mit zu langen Dateinamen gar nicht erst
kopieren lassen... Und solche mit illegalen Zeichen (wie dem :)
auch nicht.
Dann macht es auch keinen Sinn, Dateinamen mit unzulässigen Zeichen auf
eine CD/DVD oder in ein Archiv zu übernehmen, weil diese Dateien auf dem
Zielsystem in der Form sowieso nicht mehr angelegt werden können.
Exakt. Darum suche ich ja auch nach einem Weg, um "Dateinamen Windows,
UDF (DVD) bzw. ISO9660 (CD) kompatibel machen" zu können :)
Post by Martin Schnitkemper
Das hat auch nichts mehr mit dem verwendeten Zeichensatz zu tun, sondern
mit den Eigenarten des Dateisystems.
Unstrittig.

Michael
Bernd Mayer
2008-07-27 13:30:44 UTC
Permalink
Post by Michael Schmarck
Ich habe hier eine "Unmenge" von Dateien, die die "Dateisystemspezifika"
von Linux Dateisystemen ausnutzen - dh. sehr lange Dateinamen (zum Teil
mehr als 200 Zeichen im Dateinamen) und auch "Sonderzeichen" im
Dateinamen (insbesonders :).
Hallo,

gegen Sonderzeichen kann eine Vorbehandlung mit detox helfen:
http://detox.sourceforge.net/
http://sourceforge.net/projects/detox/

Bernd Mayer
--
Schäuble, wenns Dir hier nicht gefällt, dann geh doch nach drüben!
Stefan Reuther
2008-07-28 17:00:50 UTC
Permalink
Post by Michael Schmarck
Wenn ich einfach nur genisoimage ("mkisofs" von cdrkit) verwende,
so werden die Dateinamen die zu lang sind, einfach abgeschnitten.
Besonders ärgerlich ist das, weil dann auch die Extension verloren
geht und somit die betroffenen Dateien nicht mehr direkt unter
Windows verwendbar sind (sie sollen aus dem Explorer aus heraus
aufgerufen werden - es sind JPEG Bilder).
Also ich hab das vorhin mal ausprobiert: mein mkisofs (aus den Quellen
compiliert, Cygwin) kürzt die Dateinamen "sinnerhaltend" auf 8.3. Eine
Extension mit weniger als 3 Zeichen bleibt also erhalten.
Post by Michael Schmarck
Kann jemand ein Tool/Script empfehlen, mit dem man die Dateienamen
zum Brennen einfach umnennen kann und sie somit Windows, UDF (DVD)
bzw. ISO-9660 (CD) kompatibel machen kann?
UDF kann prinzipiell all die Sauereien eines Unix-FS. Die Frage ist, ob
Windows das dann auch lesen kann :-)


Stefan
Ulf Volmer
2008-07-28 18:31:26 UTC
Permalink
Post by Stefan Reuther
Post by Michael Schmarck
Wenn ich einfach nur genisoimage ("mkisofs" von cdrkit) verwende,
so werden die Dateinamen die zu lang sind, einfach abgeschnitten.
Besonders ärgerlich ist das, weil dann auch die Extension verloren
geht und somit die betroffenen Dateien nicht mehr direkt unter
Windows verwendbar sind (sie sollen aus dem Explorer aus heraus
aufgerufen werden - es sind JPEG Bilder).
Also ich hab das vorhin mal ausprobiert: mein mkisofs (aus den Quellen
compiliert, Cygwin) kürzt die Dateinamen "sinnerhaltend" auf 8.3. Eine
Extension mit weniger als 3 Zeichen bleibt also erhalten.
Es ging IMHO nicht um iso9660 Level 1 (8.3) sondern Level 2 (31) und
insbesondere Joliet (64 Zeichen).
RockRidge würde helfen (255), wird aber meines Wissens von Windows nicht
unterstützt.
Post by Stefan Reuther
Post by Michael Schmarck
Kann jemand ein Tool/Script empfehlen, mit dem man die Dateienamen
zum Brennen einfach umnennen kann und sie somit Windows, UDF (DVD)
bzw. ISO-9660 (CD) kompatibel machen kann?
UDF kann prinzipiell all die Sauereien eines Unix-FS. Die Frage ist, ob
Windows das dann auch lesen kann :-)
ext3 kann 255, UDF /nur/ 254 Zeichen.

cu
ulf
Joerg Schilling
2008-08-04 10:48:49 UTC
Permalink
Post by Ulf Volmer
Post by Stefan Reuther
Post by Michael Schmarck
Kann jemand ein Tool/Script empfehlen, mit dem man die Dateienamen
zum Brennen einfach umnennen kann und sie somit Windows, UDF (DVD)
bzw. ISO-9660 (CD) kompatibel machen kann?
UDF kann prinzipiell all die Sauereien eines Unix-FS. Die Frage ist, ob
Windows das dann auch lesen kann :-)
ext3 kann 255, UDF /nur/ 254 Zeichen.
UDF kann aber 254 UNICODE Zeichen, daß kann bei POSIX konformer
UTF-8 Kodierung _im_ Filesystem und Hirogana (Schreibweise ????)
Zeichen bis zu 762 Oktette bedeuten.

Ohne Joliet kann mkisofs aber unter UDF Dateinamen die länger als
103 Zeichen sind........ einfach das Original verwenden ;-)
--
EMail:***@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
***@cs.tu-berlin.de (uni)
***@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Stefan Reuther
2008-08-04 18:40:02 UTC
Permalink
Post by Joerg Schilling
Post by Ulf Volmer
Post by Stefan Reuther
Post by Michael Schmarck
Kann jemand ein Tool/Script empfehlen, mit dem man die Dateienamen
zum Brennen einfach umnennen kann und sie somit Windows, UDF (DVD)
bzw. ISO-9660 (CD) kompatibel machen kann?
UDF kann prinzipiell all die Sauereien eines Unix-FS. Die Frage ist, ob
Windows das dann auch lesen kann :-)
ext3 kann 255, UDF /nur/ 254 Zeichen.
UDF kann aber 254 UNICODE Zeichen
Ich komme ja nur auf 254 Bytes pro Dateiname. Das sind mit UCS-2-
Codierung irgendwas zwischen 63 und 126 Unicode-Zeichen; nach UTF-8
decodiert wäre das Maximum wohl mit Latin-1-Zeichen erreichbar (das
wären dann 508 Oktette).


Stefan
Michael Schmarck
2008-07-28 20:14:35 UTC
Permalink
Post by Stefan Reuther
Post by Michael Schmarck
Wenn ich einfach nur genisoimage ("mkisofs" von cdrkit) verwende,
so werden die Dateinamen die zu lang sind, einfach abgeschnitten.
Besonders ärgerlich ist das, weil dann auch die Extension verloren
geht und somit die betroffenen Dateien nicht mehr direkt unter
Windows verwendbar sind (sie sollen aus dem Explorer aus heraus
aufgerufen werden - es sind JPEG Bilder).
Also ich hab das vorhin mal ausprobiert: mein mkisofs (aus den Quellen
compiliert, Cygwin) kürzt die Dateinamen "sinnerhaltend" auf 8.3. Eine
Extension mit weniger als 3 Zeichen bleibt also erhalten.
Nicht wenn Joliet verwendet wird. Zumindest dann nicht, wenn man eine
so gebrannte CD/DVD in Windows verwendet.
Post by Stefan Reuther
Post by Michael Schmarck
Kann jemand ein Tool/Script empfehlen, mit dem man die Dateienamen
zum Brennen einfach umnennen kann und sie somit Windows, UDF (DVD)
bzw. ISO-9660 (CD) kompatibel machen kann?
UDF kann prinzipiell all die Sauereien eines Unix-FS. Die Frage ist, ob
Windows das dann auch lesen kann :-)
Zumindest Windows 2000 kann's nicht.

Michael
Joerg Schilling
2008-08-04 10:35:46 UTC
Permalink
Post by Michael Schmarck
Hallo.
Ich habe hier eine "Unmenge" von Dateien, die die "Dateisystemspezifika"
von Linux Dateisystemen ausnutzen - dh. sehr lange Dateinamen (zum Teil
mehr als 200 Zeichen im Dateinamen) und auch "Sonderzeichen" im
Dateinamen (insbesonders :).
Nun möchte ich das ganze auf DVD brennen und von Windows drauf
zugreifen.
Wenn ich einfach nur genisoimage ("mkisofs" von cdrkit) verwende,
so werden die Dateinamen die zu lang sind, einfach abgeschnitten.
Besonders Àrgerlich ist das, weil dann auch die Extension verloren
geht und somit die betroffenen Dateien nicht mehr direkt unter
Windows verwendbar sind (sie sollen aus dem Explorer aus heraus
aufgerufen werden - es sind JPEG Bilder).
Warum verwendest Du denn dieses allgemein als "defekt" bekannte Programm?

"mkisofs" von cdrkit basiert auf einem 3 Jahre alten mkisofs und
hat daher alle Bugs die mkisofs vor 3 Jahren hatte, zuzüglich der
diversen Bugs die Debian noch dazugebaut hat wie fehlerhafte
Jolietbehandlung und diverse UDF Probleme.
Post by Michael Schmarck
Kann jemand ein Tool/Script empfehlen, mit dem man die Dateienamen
zum Brennen einfach umnennen kann und sie somit Windows, UDF (DVD)
bzw. ISO-9660 (CD) kompatibel machen kann?
Mkisofs ist in den letzten 3 Jahren stark überarbeitet worden.
Es sind dabei einige dutzend alter Bugs beseitigt worden und es
ist eine große Menge neuer Eigenschaften dazugekommen.

Speziell kann mkisofs die volle Dateinamenlänge von 255 Zeichen
falls nicht gleichzeitig auch Joliet erzeugt wird. Darüberhinaus ist
nun eine deutlich stärkere Trennung der Joliet Dateinamen und der
UDF Dateinamen.

Statt stark veralteter und ungewarteter Forks ist es immer zu empfehlen
eine aktelle gewartete Originalsoftware zu verwenden:

ftp://ftp.berlios.de/pub/cdrecord/alpha/
--
EMail:***@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
***@cs.tu-berlin.de (uni)
***@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
frank paulsen
2008-08-04 13:20:20 UTC
Permalink
Post by Joerg Schilling
Post by Michael Schmarck
Nun möchte ich das ganze auf DVD brennen und von Windows drauf
zugreifen.
[...]
Post by Joerg Schilling
Warum verwendest Du denn dieses allgemein als "defekt" bekannte Programm?
du schreibst "defekt" da vorsichtiger- und richtigerweise selbst in
anfuehrungszeichen, benutzt dazu aber ein *nachweislich* defektes
programm, welches nicht mal vernuenftig mit umlauten umgehen kann.

wie soll man dich da ernstnehmen?
--
Slackwar! fight dependencies - install everything
Helmut Hullen
2008-08-04 15:06:00 UTC
Permalink
Hallo, frank,
Post by frank paulsen
Post by Joerg Schilling
Warum verwendest Du denn dieses allgemein als "defekt" bekannte Programm?
du schreibst "defekt" da vorsichtiger- und richtigerweise selbst in
anfuehrungszeichen, benutzt dazu aber ein *nachweislich* defektes
programm, welches nicht mal vernuenftig mit umlauten umgehen kann.
wie soll man dich da ernstnehmen?
Du vergleichst Rossäpfel mit Bessemerbirnen (und Du weisst das).
Oder meinst Du etwa, dass jemand, der schwerhörig ist, keine Bilder
beurteilen kann?

Viele Gruesse
Helmut

"Ubuntu" - an African word, meaning "Slackware is too hard for me".
Michael Schmarck
2008-08-11 11:53:10 UTC
Permalink
Post by Michael Schmarck
Hallo.
Ich habe hier eine "Unmenge" von Dateien, die die "Dateisystemspezifika"
von Linux Dateisystemen ausnutzen - dh. sehr lange Dateinamen (zum Teil
mehr als 200 Zeichen im Dateinamen) und auch "Sonderzeichen" im
Dateinamen (insbesonders :).
Nun möchte ich das ganze auf DVD brennen und von Windows drauf
zugreifen.
Wenn ich einfach nur genisoimage ("mkisofs" von cdrkit) verwende,
so werden die Dateinamen die zu lang sind, einfach abgeschnitten.
Besonders ärgerlich ist das, weil dann auch die Extension verloren
geht und somit die betroffenen Dateien nicht mehr direkt unter
Windows verwendbar sind (sie sollen aus dem Explorer aus heraus
aufgerufen werden - es sind JPEG Bilder).
[...]
Speziell kann mkisofs die volle Dateinamenl�nge von 255 Zeichen
falls nicht gleichzeitig auch Joliet erzeugt wird. Dar�berhinaus ist
nun eine deutlich st�rkere Trennung der Joliet Dateinamen und der
UDF Dateinamen.
Ich habe jetzt endlich cdrtools-2.01.01a45 installiert. Wie müsste ich
mkisofs aufrufen, so das Dateien ins ISO übernommen werden, deren
Dateiname bis zu 238 Zeichen lang ist und deren Pfad ca. 400 Zeichen
lang ist (also Verzeichnisnamen + Dateiname)? Und zwar so, das Windows
2000 und Windows XP eine mit diesem ISO gebrannte DVD einlesen
können und die Dateinamen komplett anzeigen?

Ich habe jetzt mal ein ISO durch folgenden Befehl erzeugt (der Befehl
ist etwas anders als in der Mail, die ich Dir geschickt habe):

$ ~/.software/cdrecord-2.01.01/bin/mkisofs -rational-rock -rrip112 \
-input-charset utf-8 -o bilder.iso -dir-mode 0755 -udf \
-volid 'Bilder 2008' -verbose .

$ ~/.software/cdrecord-2.01.01/bin/mkisofs -version
mkisofs 2.01.01a45 (i686-pc-linux-gnu) Copyright (C) 1993-1997 Eric Youngdale (C) 1997-2008 J�rg Schilling

Die so erstellte "bilder.iso" habe ich auf eine DVD gebrannt. Mit
Linux kann ich alles ohne Probleme von der DVD+RW lesen - Linux
mountet das als UDF und gut ist. Schiebe ich die DVD in einen
Windows 2000 Rechner, so wird mir in dem Verzeichnis mit den
sehr langen Dateinamen rein *gar* *nichts* angezeigt. Nichts.

Der Verzeichnisname ist (incl. übergeordneter Verzeichnisse) insg.
92 Zeichen lang. In dem Verzeichnis habe ich Dateien, deren Dateiname
zwischen 140 und 238 Zeichen hat. Mich wundert nun ein wenig,
das ich noch nichtmals die Dateien sehe, die einen "kurzen" Namen von
140 Zeichen haben.

Wobei... Auch mit Linux konnte ich nicht alle Dateien auslesen.
Irgendwann wird das Listing "abgebrochen":

$ ls -la *cimg
-r--r--r-- 1 mike root 2672501 6. Aug 14:24 [2008-06-29--08.39.46] (cimg

Eine solche Datei gibt's auf der Quelle nicht. Im Datienmane habe ich
auch einen Zeitstempel und kann somit die Datei auf der Quelle finden.
Dort heisst sie:

--($ ~/Desktop/My Pictures/Photos/dvd)-- find . -name "*2008-06-29--08.39.46*"
./Urlaub/Sommerurlaub 2008, El Ràfol d'Almúnia, Urbanización L'Almúnia, Pego, Spanien/2008-07-25/[2008-06-29--08.39.46] (cimg5553) Insekt “Karl Egon”, Wohnzimmer, Sommerurlaub 2008, El Ràfol d'Almúnia, Urbanización L'Almúnia, Pego, Spanien, {2.5 MB}.jpg

Dh. aus irgendeinem Grund wurde auch bei Linux etwas abgeschnitten.
Und es ist auch nicht nur die Anzeige dieses Namens - insg. gab es im
Quellverzeichnis 381 Dateien. Auf der DVD / im ISO finde ich in dem
entsprechenden Verzeichnis nur 338 Dateien.

Gibt's vlt. sowas wie Beschränkung des Platzes, den die Verzeichnis-
einträge einnehmen dürfen? Ist das zu viel?

$ ls -1 * | wc -c
67995

Gruß,
Michael
Michael Schmarck
2008-08-11 11:55:00 UTC
Permalink
Post by Michael Schmarck
Hallo.
Ich habe hier eine "Unmenge" von Dateien, die die "Dateisystemspezifika"
von Linux Dateisystemen ausnutzen - dh. sehr lange Dateinamen (zum Teil
mehr als 200 Zeichen im Dateinamen) und auch "Sonderzeichen" im
Dateinamen (insbesonders :).
Nun möchte ich das ganze auf DVD brennen und von Windows drauf
zugreifen.
Wenn ich einfach nur genisoimage ("mkisofs" von cdrkit) verwende,
so werden die Dateinamen die zu lang sind, einfach abgeschnitten.
Besonders ärgerlich ist das, weil dann auch die Extension verloren
geht und somit die betroffenen Dateien nicht mehr direkt unter
Windows verwendbar sind (sie sollen aus dem Explorer aus heraus
aufgerufen werden - es sind JPEG Bilder).
[...]
Speziell kann mkisofs die volle Dateinamenl�nge von 255 Zeichen
falls nicht gleichzeitig auch Joliet erzeugt wird. Dar�berhinaus ist
nun eine deutlich st�rkere Trennung der Joliet Dateinamen und der
UDF Dateinamen.
Ich habe jetzt endlich cdrtools-2.01.01a45 installiert. Wie müsste ich
mkisofs aufrufen, so das Dateien ins ISO übernommen werden, deren
Dateiname bis zu 238 Zeichen lang ist und deren Pfad ca. 100 Zeichen
lang ist (also Verzeichnisnamen + Dateiname)? Und zwar so, das Windows
2000 und Windows XP eine mit diesem ISO gebrannte DVD einlesen
können und die Dateinamen komplett anzeigen?

Ich habe jetzt mal ein ISO durch folgenden Befehl erzeugt (der Befehl
ist etwas anders als in der Mail, die ich Dir geschickt habe):

$ ~/.software/cdrecord-2.01.01/bin/mkisofs -rational-rock -rrip112 \
-input-charset utf-8 -o bilder.iso -dir-mode 0755 -udf \
-volid 'Bilder 2008' -verbose .

$ ~/.software/cdrecord-2.01.01/bin/mkisofs -version
mkisofs 2.01.01a45 (i686-pc-linux-gnu) Copyright (C) 1993-1997 Eric Youngdale (C) 1997-2008 J�rg Schilling

Die so erstellte "bilder.iso" habe ich auf eine DVD gebrannt. Mit
Linux kann ich alles ohne Probleme von der DVD+RW lesen - Linux
mountet das als UDF und gut ist. Schiebe ich die DVD in einen
Windows 2000 Rechner, so wird mir in dem Verzeichnis mit den
sehr langen Dateinamen rein *gar* *nichts* angezeigt. Nichts.

Der Verzeichnisname ist (incl. übergeordneter Verzeichnisse) insg.
92 Zeichen lang. In dem Verzeichnis habe ich Dateien, deren Dateiname
zwischen 140 und 238 Zeichen hat. Mich wundert nun ein wenig,
das ich noch nichtmals die Dateien sehe, die einen "kurzen" Namen von
140 Zeichen haben.

Wobei... Auch mit Linux konnte ich nicht alle Dateien auslesen.
Irgendwann wird das Listing "abgebrochen":

$ ls -la *cimg
-r--r--r-- 1 mike root 2672501 6. Aug 14:24 [2008-06-29--08.39.46] (cimg

Eine solche Datei gibt's auf der Quelle nicht. Im Datienmane habe ich
auch einen Zeitstempel und kann somit die Datei auf der Quelle finden.
Dort heisst sie:

--($ ~/Desktop/My Pictures/Photos/dvd)-- find . -name "*2008-06-29--08.39.46*"
./Urlaub/Sommerurlaub 2008, El Ràfol d'Almúnia, Urbanización L'Almúnia, Pego, Spanien/2008-07-25/[2008-06-29--08.39.46] (cimg5553) Insekt “Karl Egon”, Wohnzimmer, Sommerurlaub 2008, El Ràfol d'Almúnia, Urbanización L'Almúnia, Pego, Spanien, {2.5 MB}.jpg

Dh. aus irgendeinem Grund wurde auch bei Linux etwas abgeschnitten.
Und es ist auch nicht nur die Anzeige dieses Namens - insg. gab es im
Quellverzeichnis 381 Dateien. Auf der DVD / im ISO finde ich in dem
entsprechenden Verzeichnis nur 338 Dateien.

Gibt's vlt. sowas wie Beschränkung des Platzes, den die Verzeichnis-
einträge einnehmen dürfen? Ist das zu viel?

$ ls -1 * | wc -c
67995

Gruß,
Michael
Ansgar Strickerschmidt
2008-08-11 13:36:33 UTC
Permalink
Am 11.08.2008, 13:55 Uhr, schrieb Michael Schmarck
Post by Michael Schmarck
--($ ~/Desktop/My Pictures/Photos/dvd)-- find . -name
"*2008-06-29--08.39.46*"
./Urlaub/Sommerurlaub 2008, El Ràfol d'Almúnia, Urbanización L'Almúnia,
Pego, Spanien/2008-07-25/[2008-06-29--08.39.46] (cimg5553) Insekt “Karl
Egon”, Wohnzimmer, Sommerurlaub 2008, El Ràfol d'Almúnia, Urbanización
L'Almúnia, Pego, Spanien, {2.5 MB}.jpg
Wow, echt krank, der Dateiname...

OK, ich weiss, das löst Dein aktuelles Problem nicht.
Aber - hm, wie formuliere ich das schonend? Sagen wir's mal so:
Es wäre mMn dringend erwägenswert, den Workflow sinnvoll zu ändern. Und
wenn es nur ein Tabellenkalkulationsblatt (vulgo: Excel-Sheet) in Textform
(CSV) ist, das eine Referenztabelle enthält, welcher Dateiname welchem
Inhalt entspricht. Da die Dateinamen ja schon entsprechend hübsch ( =:-O )
aufbereitet sind, kann man das Erstellen von und das Verschlagworten in
solch einer Tabelle ganz einfach mit einem Skript automatisieren, das die
Dateinamen parst und die entsprechenden Felder separiert und entsprechend
einträgt, anschließend den Dateinamen auf etwas Genehmes einkürzt.
In so einer Textdatei kann man dann leicht 'greppen' (für Windozer:
suchen) und findet seine Bilder trotzdem wieder. So als Minimallösung. Ist
halt ein Zwischenschritt, aber ein einfacher.
Oder man lässt das Skript gleich HTML schreiben.
Komfortablere Verwaltungsmöglichkeiten existieren sowieso.
Post by Michael Schmarck
Dh. aus irgendeinem Grund wurde auch bei Linux etwas abgeschnitten.
Vermutlich dank der eckigen Klammern...

Ansgar
--
Mails an die angegebene Adresse erreichen mich - oder auch nicht.
Nützliche Adresse gibt's bei Bedarf!
Mail to the given address may or may not reach me - useful address will be
given when required!
Michael Schmarck
2008-08-11 17:54:55 UTC
Permalink
Post by Ansgar Strickerschmidt
Am 11.08.2008, 13:55 Uhr, schrieb Michael Schmarck
Post by Michael Schmarck
--($ ~/Desktop/My Pictures/Photos/dvd)-- find . -name
"*2008-06-29--08.39.46*"
./Urlaub/Sommerurlaub 2008, El Ràfol d'Almúnia, Urbanización L'Almúnia,
Pego, Spanien/2008-07-25/[2008-06-29--08.39.46] (cimg5553) Insekt “Karl
Egon”, Wohnzimmer, Sommerurlaub 2008, El Ràfol d'Almúnia, Urbanización
L'Almúnia, Pego, Spanien, {2.5 MB}.jpg
Wow, echt krank, der Dateiname...
Kannst Du das auch noch irgendwie begründen? Am Namen sieht man schon
recht gut, was "in" dem Bild ist. Was ist daran denn bitte "krank"?
Sprechende Dateinamen sind niemals krank, sondern immer nur gut. Und
ein Dateiname kann eigentlich nicht zu sprechend sein.
Post by Ansgar Strickerschmidt
Es wäre mMn dringend erwägenswert, den Workflow sinnvoll zu ändern. Und
Vielleicht. Allerdings würde das bedeuten, das der aktuelle Workflow
NICHT sinnvoll sei. Diese Grundannahme ist allerdings falsch (note:
nein, ich behaupte nicht, das andere unbedingt meinen Workflow
kopieren sollen. Wäre zwar sinnvoll, aber jeder so wie er will).
Post by Ansgar Strickerschmidt
wenn es nur ein Tabellenkalkulationsblatt (vulgo: Excel-Sheet) in Textform
(CSV) ist, das eine Referenztabelle enthält, welcher Dateiname welchem
Inhalt entspricht.
Würg. Dann brauche ich ja schon 2 "Datenbanken". Welchen Vorteil
hätte ich, wenn ich noch umständlich auf irgendein externes Programm
zurückgreifen müsste - zumal auch noch auf so eines wie eine
Tabellenkalkulation bzw. Textprogramm?
Post by Ansgar Strickerschmidt
Da die Dateinamen ja schon entsprechend hübsch ( =:-O )
aufbereitet sind, kann man das Erstellen von und das Verschlagworten in
solch einer Tabelle ganz einfach mit einem Skript automatisieren, das die
Und warum sollte man das überhaupt tun wollen?
Post by Ansgar Strickerschmidt
Dateinamen parst und die entsprechenden Felder separiert und entsprechend
einträgt, anschließend den Dateinamen auf etwas Genehmes einkürzt.
Für den "Online-Zugriff" auf Linux/Unix (dh. ext2, ext3, reiserfs 3&4,
JFS, xfs, UFS, zfs) ist der Dateiname schon genehm.
In einem Verzeichnis kann man leicht "find"'en. Warum den Handstand
mit einer externen Datei machen? Wenn man eine Datei löscht, muss man
so auch immer in der Datei herummachen. Oder beim verschieben müsste
man die Datei auch aktualisieren. Und was, wenn die Datei verloren
geht? Klar - Backup existiert, aber eleganter ist's, wenn man gar
nicht auf die Datei angewiesen ist.

IMO, zumindest.
Post by Ansgar Strickerschmidt
suchen) und findet seine Bilder trotzdem wieder. So als Minimallösung. Ist
Ja. Minimallösung ohne Mehrwert. IMO. Für Dich mag die Minimallösung
einen Mehrwert haben - ich mag keinen erkennen. Zumindest jetzt noch
nicht. Mal durch den Kopf gehen lassen, vlt. fällt mir dann noch einer
auf. Aber irgendwie finde ich es extrem unelegant, noch eine Daten-
bank zu führen - das wäre dann die dritte:

1) Verzeichnis auf Dateisystem
2) Excel-Tabelle
3) f-spot

3) mag man vlt. durch ein anderes Programm austauschen. 1) muss es
sowieso geben (wenn auch vlt. nicht mit einem so guten Inhalt wie
es ihn bei mir gibt). 2) - tja.
Post by Ansgar Strickerschmidt
halt ein Zwischenschritt, aber ein einfacher.
Oder man lässt das Skript gleich HTML schreiben.
Ob's glaubst oder auch nicht, aber HTML habe ich auch noch.
Post by Ansgar Strickerschmidt
Komfortablere Verwaltungsmöglichkeiten existieren sowieso.
ACK. Da verwende ich f-spot. Die f-spot Tags basieren (zum Teil) auf
den Bestandteilen des Dateinamens. So gibt's z.B. in f-spot bei mir
ein Tag "Sommerurlaub 2008". Und zwar lasse ich zuerst alle Bestand-
teile (also das, was zwischen 2 Kommas steht) als EXIF Keyword in die
Datei schreiben und dann liest f-spot die Dateien und somit die EXIF
Keywords ein.
Post by Ansgar Strickerschmidt
Post by Michael Schmarck
Dh. aus irgendeinem Grund wurde auch bei Linux etwas abgeschnitten.
Vermutlich dank der eckigen Klammern...
Es wäre schön, wenn Du bis ganz zum Ende durchgehalten hättest :)
Und nicht nur den ersten Satz des Absatzes gelesen hättest. *g*

Da folgte noch:
| Und es ist auch nicht nur die Anzeige dieses Namens - insg. gab es im
| Quellverzeichnis 381 Dateien. Auf der DVD / im ISO finde ich in dem
| entsprechenden Verzeichnis nur 338 Dateien.

Das erklärt sich kaum durch die eckigen Klammern. Gut, habe ich nicht
erwähnt, aber jetzt sei's gesagt: Die anderen 338 Dateien haben ein
identisches Dateinamensschema.

Gruß,
Michael
Bernd Mayer
2008-08-11 23:26:59 UTC
Permalink
Post by Michael Schmarck
Post by Ansgar Strickerschmidt
Am 11.08.2008, 13:55 Uhr, schrieb Michael Schmarck
Post by Michael Schmarck
--($ ~/Desktop/My Pictures/Photos/dvd)-- find . -name
"*2008-06-29--08.39.46*"
./Urlaub/Sommerurlaub 2008, El Ràfol d'Almúnia, Urbanización L'Almúnia,
Pego, Spanien/2008-07-25/[2008-06-29--08.39.46] (cimg5553) Insekt “Karl
Egon”, Wohnzimmer, Sommerurlaub 2008, El Ràfol d'Almúnia, Urbanización
L'Almúnia, Pego, Spanien, {2.5 MB}.jpg
Wow, echt krank, der Dateiname...
Kannst Du das auch noch irgendwie begründen? Am Namen sieht man schon
recht gut, was "in" dem Bild ist. Was ist daran denn bitte "krank"?
Sprechende Dateinamen sind niemals krank, sondern immer nur gut. Und
ein Dateiname kann eigentlich nicht zu sprechend sein.
Post by Ansgar Strickerschmidt
Es wäre mMn dringend erwägenswert, den Workflow sinnvoll zu ändern. Und
Vielleicht. Allerdings würde das bedeuten, das der aktuelle Workflow
nein, ich behaupte nicht, das andere unbedingt meinen Workflow
kopieren sollen. Wäre zwar sinnvoll, aber jeder so wie er will).
Hallo,

wenn man viele Digitalfotos zu verwalten hat kann man sich über deren
Organisation Gedanken machen. Profifotografen haben damit Erfahrung und
empfehlen dazu überwiegend *nicht* mit Dateinamen zu arbeiten sondern
mit Metainformationen im JPG (Exif, IPTC) oder mit Datenbanken. Der
Grund ist die erleichterte Such- und Sortiermöglichkeit. Du erkennst je
möglicherweise gerade selbst die Grenzen Deines Workflow.

Es gibt auch diverse Spezialprogramme zur Verwaltung von Digitalfotos
die sich aus der Praxis heraus entwickelt und bewährt haben.

http://de.wikipedia.org/wiki/Exchangeable_Image_File_Format
http://www.exif.org/specifications.html
http://netzreport.googlepages.com/versteckte_daten_in_jpeg_dateien.html

http://www.stern.de/media/presse/Ratgeber.pdf
http://www.keypix.de/data/deutsch/datenfacts.html
http://www.iptc.org/pages/index.php



Bernd Mayer
--
Schäuble, wenns Dir hier nicht gefällt, dann geh doch nach drüben!
Michael Schmarck
2008-08-12 06:08:01 UTC
Permalink
Post by Bernd Mayer
Post by Michael Schmarck
Post by Ansgar Strickerschmidt
Am 11.08.2008, 13:55 Uhr, schrieb Michael Schmarck
Post by Michael Schmarck
--($ ~/Desktop/My Pictures/Photos/dvd)-- find . -name
"*2008-06-29--08.39.46*"
./Urlaub/Sommerurlaub 2008, El Ràfol d'Almúnia, Urbanización L'Almúnia,
Pego, Spanien/2008-07-25/[2008-06-29--08.39.46] (cimg5553) Insekt “Karl
Egon”, Wohnzimmer, Sommerurlaub 2008, El Ràfol d'Almúnia, Urbanización
L'Almúnia, Pego, Spanien, {2.5 MB}.jpg
Wow, echt krank, der Dateiname...
Kannst Du das auch noch irgendwie begründen? Am Namen sieht man schon
recht gut, was "in" dem Bild ist. Was ist daran denn bitte "krank"?
Sprechende Dateinamen sind niemals krank, sondern immer nur gut. Und
ein Dateiname kann eigentlich nicht zu sprechend sein.
Post by Ansgar Strickerschmidt
Es wäre mMn dringend erwägenswert, den Workflow sinnvoll zu ändern. Und
Vielleicht. Allerdings würde das bedeuten, das der aktuelle Workflow
nein, ich behaupte nicht, das andere unbedingt meinen Workflow
kopieren sollen. Wäre zwar sinnvoll, aber jeder so wie er will).
Hallo,
wenn man viele Digitalfotos zu verwalten hat kann man sich über deren
Organisation Gedanken machen. Profifotografen haben damit Erfahrung und
empfehlen dazu überwiegend *nicht* mit Dateinamen zu arbeiten sondern
mit Metainformationen im JPG (Exif, IPTC) oder mit Datenbanken.
Was ich ja auch zusätzlich mache, wie ich schon mehrfach schrieb.
Post by Bernd Mayer
Der
Grund ist die erleichterte Such- und Sortiermöglichkeit. Du erkennst je
möglicherweise gerade selbst die Grenzen Deines Workflow.
Nein. Welche wären das?
Post by Bernd Mayer
Es gibt auch diverse Spezialprogramme zur Verwaltung von Digitalfotos
die sich aus der Praxis heraus entwickelt und bewährt haben.
Genau. Eines davon ist sicherlich f-spot. Mag vlt. nicht das beste
Programm auf Erden sein, aber für meine Zwecke mehr als ausreichend.

Michael

PS: Was hat das mit dem Problem zu tun, das mkisofs anscheinend
nicht in der Lage ist, UDF ISOs so zu erstellen, das Linux und Windows
damit gebrannte DVDs komplett einlesen können - denn darum geht's
ja in diesem Teil des Zweiges. Mir geht's nicht darum, wie ich meinen
Workflow ändern könnte, denn der Workflow ist so schon ganz in
Ordnung, schönen Dank auch :)
Sebastian Waschik
2008-08-12 08:22:22 UTC
Permalink
Hallo,
Post by Bernd Mayer
wenn man viele Digitalfotos zu verwalten hat kann man sich über deren
Organisation Gedanken machen. Profifotografen haben damit Erfahrung und
empfehlen dazu überwiegend *nicht* mit Dateinamen zu arbeiten sondern
mit Metainformationen im JPG (Exif, IPTC) oder mit Datenbanken.
wobei viele sicherlich es nicht sinnvoll erachten Zusatzinformationen
wie die Dateigröße, die jederzeit angezeigt werden kann, im Dateinamen
unterzubringen. Ich hoffe, dass du die Zusatzinformationen wenn du
sie schon erzeugen musst, mit einem Werkzeug erzeugst, denn sonst
schreit das ja nach Fehlern. Aber dieses Werkzeug müsste dann doch
auch alle Dateinamen mit den Zusatzinformationen einfach nur anzeigen
können und braucht die nicht in den Dateinamen auszugeben...

Hast du http://de.wikipedia.org/wiki/Joliet_(Dateisystem) gelesen?
| Im Joliet-Dateisystem darf ein Dateiname bis zu 64 Zeichen lang
| sein,

Zur eindeutigen Bezeichnung einer Datei sollte das meiner Meinung nach
auch Ausreichen...

Viele Grüße
Sebastian Waschik
Michael Schmarck
2008-08-12 08:54:14 UTC
Permalink
Hallo!
Post by Bernd Mayer
Hallo,
Post by Bernd Mayer
wenn man viele Digitalfotos zu verwalten hat kann man sich über deren
Organisation Gedanken machen. Profifotografen haben damit Erfahrung und
empfehlen dazu überwiegend *nicht* mit Dateinamen zu arbeiten sondern
mit Metainformationen im JPG (Exif, IPTC) oder mit Datenbanken.
(Das habe ich nicht geschrieben.)
Post by Bernd Mayer
wobei viele sicherlich es nicht sinnvoll erachten Zusatzinformationen
wie die Dateigröße, die jederzeit angezeigt werden kann, im Dateinamen
unterzubringen.
Schön. Wie gesagt, ich will keinem meinen Workflow aufdrängen. Von
daher ist mir nicht ganz einleuchtend, warum es irgendwie von Interesse
sein sollte, was viele für sinnvoll erachten mögen oder auch nicht.
Zwar denke ich nach wie vor, das mein Workflow sinnvoll ist und auch
von anderen aufgenommen werden könnte, aber wenn andere das
anders sehen, dann ist mir das auch recht. Ich komme mit meinem
Workflow klar und damit ist's doch auch schon gut, oder nicht?
Post by Bernd Mayer
Ich hoffe, dass du die Zusatzinformationen wenn du
sie schon erzeugen musst, mit einem Werkzeug erzeugst, denn sonst
schreit das ja nach Fehlern.
Ja, mit Gthumb ist das kein Problem.
Post by Bernd Mayer
Zur eindeutigen Bezeichnung einer Datei sollte das meiner Meinung nach
auch Ausreichen...
Deiner Meinung nach. Meiner Meinung nach nicht. Aber ich verstehe immer
noch nicht, was das mit dem Problem zu tun hat, das mkisofs von cdrtools
(und auch sicher genisoimage) ein UDF Image erstellt, welches danach
nicht fehlerfrei von Windows oder Linux eingelesen werden kann. Könnten
wir uns vlt. bitte mal endlich auf den Kern des Problemes konzentrieren
und diese uninteressanten Nebenkriegsschauplätze ignorieren? Wäre
wirklich toll! :)

Vielen Dank,
Michael
Bernd Mayer
2008-08-12 09:22:59 UTC
Permalink
Post by Michael Schmarck
Deiner Meinung nach. Meiner Meinung nach nicht. Aber ich verstehe immer
noch nicht, was das mit dem Problem zu tun hat, das mkisofs von cdrtools
(und auch sicher genisoimage) ein UDF Image erstellt, welches danach
nicht fehlerfrei von Windows oder Linux eingelesen werden kann. Könnten
wir uns vlt. bitte mal endlich auf den Kern des Problemes konzentrieren
und diese uninteressanten Nebenkriegsschauplätze ignorieren? Wäre
wirklich toll! :)
Hallo,

das ist ja genau der Kern des Problems: Wenn man etliche Digitalfotos
über längere Zeit sinnvoll abspeichern möchte und dann auf mehreren
Betriebssystemen dann gibt es ganz schnell starke bis unlösbare Probleme
wenn man versucht Metainformationen im Dateinamen unterzubringen.

Man Holzweg


Bernd Mayer
--
Schäuble, wenns Dir hier nicht gefällt, dann geh doch nach drüben!
Michael Schmarck
2008-08-12 09:26:13 UTC
Permalink
Post by Bernd Mayer
Post by Michael Schmarck
Deiner Meinung nach. Meiner Meinung nach nicht. Aber ich verstehe immer
noch nicht, was das mit dem Problem zu tun hat, das mkisofs von cdrtools
(und auch sicher genisoimage) ein UDF Image erstellt, welches danach
nicht fehlerfrei von Windows oder Linux eingelesen werden kann. Könnten
wir uns vlt. bitte mal endlich auf den Kern des Problemes konzentrieren
und diese uninteressanten Nebenkriegsschauplätze ignorieren? Wäre
wirklich toll! :)
Hallo,
das ist ja genau der Kern des Problems: Wenn man etliche Digitalfotos
über längere Zeit sinnvoll abspeichern möchte und dann auf mehreren
Betriebssystemen dann gibt es ganz schnell starke bis unlösbare Probleme
wenn man versucht Metainformationen im Dateinamen unterzubringen.
Nein, das akt. Problem ist, das mkisofs UDF Images erstellt, die sich
nicht problemlos auf Windows/Linux einlesen lassen, so sie denn auf
DVD gebrannt werden.

Zu dem vermeintlichen "Kern des Problemes": EXIF wird verwendet.
Können wir nun bitte endlich bei diesen Pseudokern ruhen lassen? Denn
darum geht es ja eben gerade nicht.

Michael
Markus Wichmann
2008-08-13 07:53:38 UTC
Permalink
Post by Michael Schmarck
Post by Bernd Mayer
Post by Michael Schmarck
Deiner Meinung nach. Meiner Meinung nach nicht. Aber ich verstehe immer
noch nicht, was das mit dem Problem zu tun hat, das mkisofs von cdrtools
(und auch sicher genisoimage) ein UDF Image erstellt, welches danach
nicht fehlerfrei von Windows oder Linux eingelesen werden kann. Könnten
wir uns vlt. bitte mal endlich auf den Kern des Problemes konzentrieren
und diese uninteressanten Nebenkriegsschauplätze ignorieren? Wäre
wirklich toll! :)
Hallo,
das ist ja genau der Kern des Problems: Wenn man etliche Digitalfotos
über längere Zeit sinnvoll abspeichern möchte und dann auf mehreren
Betriebssystemen dann gibt es ganz schnell starke bis unlösbare Probleme
wenn man versucht Metainformationen im Dateinamen unterzubringen.
Nein, das akt. Problem ist, das mkisofs UDF Images erstellt, die sich
nicht problemlos auf Windows/Linux einlesen lassen, so sie denn auf
DVD gebrannt werden.
UDF würde ich _immer_ mit dem dafür ausgelegten Tool erstellen:
mkudffs. Herangehensweise:

1. Erstelle eine Nullbyte-Datei von der Größe, die du letztlich
brennen kannst (wenn auf der DVD was von 4.7 GB drauf steht, mache
maximal 4.4 GB, sicherheitshalber aber noch etwas mehr Platz lassen):

dd if=/dev/zero of=udf.img bs=1M count=4096 #das werden dann 4 GB

2. Mache ein UDF drauf:

mkudffs --media-type=dvd --utf8 -r 0x0150 udf.img

Das erstellt ein UDF-Image für eine DVD, das UTF-8 für Dateinamen
verwendet und dank Revision 1.5 mit Windows 2000 kompatibel ist.

3. das ganze loopmounten:

mkdir tmproot
sudo mount -o loop,uid=$DEIN_USER udf.img tmproot

4. Dateien reinkopieren (das kriegste gerade noch so selbst hin, wa?)
4a. Image überprüfen (mit ls, ob das mit den Dateinamen stimmt)
5. umounten:

sudo umount tmproot
rmdir tmproot

6. Das Image brennen:
nimm eins von:

wodim udf.img
growisofs /dev/${BRENNER}=udf.img

oder nimm halt k3b oder xcdroast, oder weis der Kuckuck was.
Post by Michael Schmarck
Zu dem vermeintlichen "Kern des Problemes": EXIF wird verwendet.
Können wir nun bitte endlich bei diesen Pseudokern ruhen lassen? Denn
darum geht es ja eben gerade nicht.
Es wäre _eine_ mögliche Lösung des Problems, die Dateinamen auf 64
Unicode-Zeichen zu kürzen. Kannst du mit deinen Bildern versuchen,
unter 255 Zeichen pro Dateiname zu bleiben, und unter 1023 Zeichen für
den Pfadl zu bleiben? Wenn nicht, bringt auch UDF nix mehr.
Post by Michael Schmarck
Michael
Tschö,
Markus

P.S.: Falls du es hören willst: Ich habe hier eine ganze Menge Fotos.
Die haben alle den Dateinamen $NUMMER.jpg (momentan bin ich bei 870
Fotos). Für jedes Bild gibt es eine Textdatei gleicher Nummer, in der
ungeordnet Informationen stehen. Beim Verschieben oder Kopieren
benutze ich so eben immer nur die Nummer als Referenz und schließe
daran ein * an, dann geht schon alles.
--
Nur weil ein Genie nix reißt, muß ja nun nicht gleich jeder Idiot
pausieren... Bully hats ja auch geschafft.
-- gUnter nanonüm in de.alt.anime
Michael Schmarck
2008-08-13 08:58:08 UTC
Permalink
Post by Markus Wichmann
Post by Michael Schmarck
Post by Bernd Mayer
Post by Michael Schmarck
Deiner Meinung nach. Meiner Meinung nach nicht. Aber ich verstehe immer
noch nicht, was das mit dem Problem zu tun hat, das mkisofs von
cdrtools (und auch sicher genisoimage) ein UDF Image erstellt, welches
danach nicht fehlerfrei von Windows oder Linux eingelesen werden kann.
Könnten wir uns vlt. bitte mal endlich auf den Kern des Problemes
konzentrieren und diese uninteressanten Nebenkriegsschauplätze
ignorieren? Wäre wirklich toll! :)
Hallo,
das ist ja genau der Kern des Problems: Wenn man etliche Digitalfotos
über längere Zeit sinnvoll abspeichern möchte und dann auf mehreren
Betriebssystemen dann gibt es ganz schnell starke bis unlösbare Probleme
wenn man versucht Metainformationen im Dateinamen unterzubringen.
Nein, das akt. Problem ist, das mkisofs UDF Images erstellt, die sich
nicht problemlos auf Windows/Linux einlesen lassen, so sie denn auf
DVD gebrannt werden.
Danke. mkudffs kannte ich noch nicht. linux-udf scheint aber auch seit 2004
tot zu sein, oder trügt der Anschein?

[...]
Post by Markus Wichmann
4. Dateien reinkopieren (das kriegste gerade noch so selbst hin, wa?)
Nein, bekomme ich nicht :(

$ sudo cp -av *Karl* /tmp/d2/
„[2008-06-29--08.39.46] (cimg5553) Insekt \“Karl Egon”, Wohnzimmer, Sommerurlaub 2008, El Ràfol d'Almúnia, Urbanización L'Almúnia, Pego, Spanien, {2.5 MB}.jpg“ -> „/tmp/d2/[2008-06-29--08.39.46] (cimg5553) Insekt \“Karl Egon”, Wohnzimmer, Sommerurlaub 2008, El Ràfol d'Almúnia, Urbanización L'Almúnia, Pego, Spanien, {2.5 MB}.jpg“
cp: reguläre Datei „/tmp/d2/[2008-06-29--08.39.46] (cimg5553) Insekt \“Karl Egon”, Wohnzimmer, Sommerurlaub 2008, El Ràfol d'Almúnia, Urbanización L'Almúnia, Pego, Spanien, {2.5 MB}.jpg“ kann nicht angelegt werden: Das Dateisystem ist nur lesbar

08-07-25)-- mount | grep d2
/data/bilder.img on /tmp/d2 type udf (rw,loop=/dev/loop0,uid=10001)

Warum "nur lesbar"?

$ sudo cp ~/SEMDEBUG.TXT /tmp/d2/
cp: reguläre Datei „/tmp/d2/SEMDEBUG.TXT“ kann nicht angelegt werden: Das Dateisystem ist nur lesbar

Es hat also nichts mit dem "interessanten" Dateinamen zu tun.

Bis zu "4." habe ich Deine Befehle übernommen (und nur die Pfade
sowie die Imagegröße angepasst).

--($ ~)-- uname -a
Linux sys488 2.6.25-ARCH #1 SMP PREEMPT Mon Jul 14 15:25:51 UTC 2008 i686 Genuine Intel(R) CPU T2400 @ 1.83GHz GenuineIntel GNU/Linux

Ist ein ArchLinux x86 System.
Post by Markus Wichmann
Post by Michael Schmarck
Zu dem vermeintlichen "Kern des Problemes": EXIF wird verwendet.
Können wir nun bitte endlich bei diesen Pseudokern ruhen lassen? Denn
darum geht es ja eben gerade nicht.
Es wäre _eine_ mögliche Lösung des Problems, die Dateinamen auf 64
Unicode-Zeichen zu kürzen.
Ja.
Post by Markus Wichmann
Kannst du mit deinen Bildern versuchen,
unter 255 Zeichen pro Dateiname zu bleiben, und unter 1023 Zeichen für
den Pfadl zu bleiben?
Das bin ich ja jetzt schon :) Meine Dateinamen sind max. 240 Zeichen
lang - allerdings nicht nur ASCII, sondern auch "Sonderzeichen".

Beispiel:

./Urlaub/Sommerurlaub 2008, El Ràfol d'Almúnia, Urbanización L'Almúnia, Pego, Spanien/2008-07-25/[2008-06-29--08.39.46] (cimg5553) Insekt “Karl Egon”, Wohnzimmer, Sommerurlaub 2008, El Ràfol d'Almúnia, Urbanización L'Almúnia, Pego, Spanien, {2.5 MB}.jpg

Michael
Markus Wichmann
2008-08-13 13:21:05 UTC
Permalink
Post by Michael Schmarck
Danke. mkudffs kannte ich noch nicht. linux-udf scheint aber auch seit 2004
tot zu sein, oder trügt der Anschein?
Kann sein. Mein mkudffs ist von 2002. Macht aber nix, es kann ja
trotzdem alle wichtigen Revisionen.
Post by Michael Schmarck
[...]
Post by Markus Wichmann
4. Dateien reinkopieren (das kriegste gerade noch so selbst hin, wa?)
Nein, bekomme ich nicht :(
[...]
Post by Michael Schmarck
Warum "nur lesbar"?
Siehste, das kommt davon, wenn man denkt, dass das so klappt. Ich
habe es jetzt mal ausprobiert: Wenn man das Image ohne
--media-type=dvd erstellt, dann kann man es auch befüllen. Aber ob es
dann noch auf Windows läuft, weiß ich leider nicht.

Also Asche auf mein Haupt...

[...]
Post by Michael Schmarck
Post by Markus Wichmann
Kannst du mit deinen Bildern versuchen,
unter 255 Zeichen pro Dateiname zu bleiben, und unter 1023 Zeichen für
den Pfadl zu bleiben?
Das bin ich ja jetzt schon :) Meine Dateinamen sind max. 240 Zeichen
lang - allerdings nicht nur ASCII, sondern auch "Sonderzeichen".
./Urlaub/Sommerurlaub 2008, El Ràfol d'Almúnia, Urbanización L'Almúnia, Pego, Spanien/2008-07-25/[2008-06-29--08.39.46] (cimg5553) Insekt “Karl Egon”, Wohnzimmer, Sommerurlaub 2008, El Ràfol d'Almúnia, Urbanización L'Almúnia, Pego, Spanien, {2.5 MB}.jpg
Warum baust du eigentlich noch zusätzlich redundante Infos ein? Also,
dass das Bild aus dem Urlaub 08 stammt, steht sowohl in Datei- als
auch Verzeichnisname. Und wo El Ràfol d'Almúnia politisch einzuordnen
ist, kann man erstens ganz leicht nachgucken und zweitens ist das eh
instabil (wenn die dort ihre "Urbanización"s genauso oft ändern wie
wir unsere Kreise...).
Post by Michael Schmarck
Michael
Tschö,
Markus
--
Nur weil ein Genie nix reißt, muß ja nun nicht gleich jeder Idiot
pausieren... Bully hats ja auch geschafft.
-- gUnter nanonüm in de.alt.anime
Michael Schmarck
2008-08-13 14:30:50 UTC
Permalink
Post by Markus Wichmann
Siehste, das kommt davon, wenn man denkt, dass das so klappt. Ich
habe es jetzt mal ausprobiert: Wenn man das Image ohne
--media-type=dvd erstellt, dann kann man es auch befüllen.
Diese "komische" Datei bekomme ich aber trotzdem nicht rein :(

--($ ~/Desktop/My Pictures/Photos/dvd/_test_/Urlaub/Sommerurlaub 2008, El Ràfol d'Almúnia, Urbanización L'Almúnia, Pego, Spanien/2008-07-25)-- cp *Karl* /tmp/d4
Speicherzugriffsfehler

Andere, normale Dateien kann ich da rein kopieren.

Vermutlich störte auch hier die Länge und/oder die “”.

Michael
Ansgar Strickerschmidt
2008-08-13 08:14:57 UTC
Permalink
Am 12.08.2008, 11:26 Uhr, schrieb Michael Schmarck
Post by Michael Schmarck
Zu dem vermeintlichen "Kern des Problemes": EXIF wird verwendet.
Können wir nun bitte endlich bei diesen Pseudokern ruhen lassen? Denn
darum geht es ja eben gerade nicht.
Indianische Weisheit: Wenn Du bemerkst, dass Du ein totes Perd reitest,
steig ab.

:)

Ansgar
--
Mails an die angegebene Adresse erreichen mich - oder auch nicht.
Nützliche Adresse gibt's bei Bedarf!
Mail to the given address may or may not reach me - useful address will be
given when required!
Bernd Mayer
2008-08-12 09:26:02 UTC
Permalink
Post by Michael Schmarck
Deiner Meinung nach. Meiner Meinung nach nicht. Aber ich verstehe immer
noch nicht, was das mit dem Problem zu tun hat, das mkisofs von cdrtools
(und auch sicher genisoimage) ein UDF Image erstellt, welches danach
nicht fehlerfrei von Windows oder Linux eingelesen werden kann. Könnten
wir uns vlt. bitte mal endlich auf den Kern des Problemes konzentrieren
und diese uninteressanten Nebenkriegsschauplätze ignorieren? Wäre
wirklich toll! :)
Hallo,

das ist ja genau der Kern des Problems: Wenn man eine grössere Anzahl
etliche Digitalfotos über längere Zeit sinnvoll abspeichern möchte und
dann auf mehreren Betriebssystemen nutzen möchte, dann gibt es ganz
schnell starke bis unlösbare Probleme wenn man versucht
Metainformationen im Dateinamen unterzubringen.


Bernd Mayer
--
Schäuble, wenns Dir hier nicht gefällt, dann geh doch nach drüben!
Bernd Mayer
2008-08-12 09:27:04 UTC
Permalink
Post by Michael Schmarck
Deiner Meinung nach. Meiner Meinung nach nicht. Aber ich verstehe immer
noch nicht, was das mit dem Problem zu tun hat, das mkisofs von cdrtools
(und auch sicher genisoimage) ein UDF Image erstellt, welches danach
nicht fehlerfrei von Windows oder Linux eingelesen werden kann. Könnten
wir uns vlt. bitte mal endlich auf den Kern des Problemes konzentrieren
und diese uninteressanten Nebenkriegsschauplätze ignorieren? Wäre
wirklich toll! :)
Hallo,

das ist ja genau der Kern des Problems: Wenn man eine grössere Anzahl
Digitalfotos über längere Zeit sinnvoll abspeichern möchte und dann auf
mehreren Betriebssystemen nutzen möchte, dann gibt es ganz schnell
starke bis unlösbare Probleme wenn man versucht Metainformationen im
Dateinamen unterzubringen.


Bernd Mayer
--
Schäuble, wenns Dir hier nicht gefällt, dann geh doch nach drüben!
Helmut Hullen
2008-08-12 09:21:00 UTC
Permalink
Hallo, Sebastian,
Post by Sebastian Waschik
Post by Bernd Mayer
wenn man viele Digitalfotos zu verwalten hat kann man sich über
deren Organisation Gedanken machen.
| Im Joliet-Dateisystem darf ein Dateiname bis zu 64 Zeichen lang
| sein,
Zur eindeutigen Bezeichnung einer Datei sollte das meiner Meinung
nach auch Ausreichen...
Zur eindeutigen Bezeichnung jedes Menschen sollte eine 12-stellige
Dezimalzahl ausreichen ... und bei Büchern sollte die ISBN zur
Identifizierung auch ausreichen - Titel und Verfasser sind überflüssig!

Viele Gruesse
Helmut

"Ubuntu" - an African word, meaning "Slackware is too hard for me".
Michael Schmarck
2008-08-12 10:20:16 UTC
Permalink
Post by Michael Schmarck
Wobei... Auch mit Linux konnte ich nicht alle Dateien auslesen.
$ ls -la *cimg
-r--r--r-- 1 mike root 2672501 6. Aug 14:24 [2008-06-29--08.39.46] (cimg
Eine solche Datei gibt's auf der Quelle nicht. Im Datienmane habe ich
auch einen Zeitstempel und kann somit die Datei auf der Quelle finden.
--($ ~/Desktop/My Pictures/Photos/dvd)-- find . -name
"*2008-06-29--08.39.46*" ./Urlaub/Sommerurlaub 2008, El Ràfol d'Almúnia,
Urbanización L'Almúnia, Pego, Spanien/2008-07-25/[2008-06-29--08.39.46]
(cimg5553) Insekt “Karl Egon”, Wohnzimmer, Sommerurlaub 2008, El Ràfol
d'Almúnia, Urbanización L'Almúnia, Pego, Spanien, {2.5 MB}.jpg
Dh. aus irgendeinem Grund wurde auch bei Linux etwas abgeschnitten.
Könnte jemand mal bitte verifizieren, ob er eine Datei mit *EXAKT* dem
o.g. Namen in ein UDF Image packen kann und dann von Linux/Windows
die Datei lesen kann?

Testcase:

cd /tmp
mkdir -p _test_/Urlaub/Sommerurlaub\ 2008\,\ El\ Ràfol\ d\'Almúnia\,\ Urbanización\ L\'Almúnia\,\ Pego\,\ Spanien/2008-07-25
date > "_test_/Urlaub/Sommerurlaub 2008, El Ràfol d'Almúnia, Urbanización L'Almúnia, Pego, Spanien/2008-07-25/[2008-06-29--08.39.46] (cimg5553) Insekt “Karl Egon”, Wohnzimmer, Sommerurlaub 2008, El Ràfol d'Almúnia, Urbanización L'Almúnia, Pego, Spanien, {2.5 MB}.jpg"
mkisofs -rational-rock -rrip112 -input-charset utf-8 -o /tmp/test.iso -dir-mode 0755 -udf -verbose _test_/U*/S*/2*/*2*
mkdir /tmp/d
mount -o loop,ro /tmp/test.iso /tmp/d

Wenn ich das mache, so hat zum einen das Verzeichnis /tmp/d die Rechte
"0000" (das habe ich Jörg vor ein paar Tagen per Mail geschickt) und zum
anderen:

$ sudo ls -la /tmp/d
insgesamt 2616
d--------- 2 root root 392 12. Aug 12:05 .
drwxrwxrwt 15 root root 4096 12. Aug 12:07 ..
-r--r--r-- 1 root root 2672501 6. Aug 14:24 [2008-06-29--08.39.46] (cimg

In dem ISO Image befindet sich exakt 1 Datei. Das ISO Image habe ich
auf <http://michael-schmarck.share.s3.amazonaws.com/dcoulm/udf-test.iso>
zugänglich gemacht. Größe: 3.532.800 Bytes.

$ ~/.software/cdrecord-2.01.01/bin/mkisofs -version
mkisofs 2.01.01a45 (i686-pc-linux-gnu) Copyright (C) 1993-1997 Eric Youngdale (C) 1997-2008 J�rg Schilling

Kann jemand das Problem nachvollziehen?

Und mit Daemon Tools Lite bzw. dem Windows XP Virtual CD Control Panel
von MS kann ich das so erstellte Image auf Windows 2000 auch nicht
mounten - “Invalid Image”, sagen mir die Tools. Andere Images sind
hingegen mountbar.

Michael
Joerg Schilling
2008-08-13 13:12:03 UTC
Permalink
Könnte jemand mal bitte verifizieren, ob er eine Datei mit *EXAKT* dem
o.g. Namen in ein UDF Image packen kann und dann von Linux/Windows
die Datei lesen kann?
cd /tmp
mkdir -p _test_/Urlaub/Sommerurlaub\ 2008\,\ El\ Ràfol\ d\'Almúnia\,\ Urbanización\ L\'Almúnia\,\ Pego\,\ Spanien/2008-07-25
date > "_test_/Urlaub/Sommerurlaub 2008, El Ràfol d'Almúnia, Urbanización L'Almúnia, Pego, Spanien/2008-07-25/[2008-06-29--08.39.46] (cimg5553) Insekt “Karl Egon”, Wohnzimmer, Sommerurlaub 2008, El Ràfol d'Almúnia, Urbanización L'Almúnia, Pego, Spanien, {2.5 MB}.jpg"
mkisofs -rational-rock -rrip112 -input-charset utf-8 -o /tmp/test.iso -dir-mode 0755 -udf -verbose _test_/U*/S*/2*/*2*
mkdir /tmp/d
mount -o loop,ro /tmp/test.iso /tmp/d
Woher weist Du daß die Schabe Karl Egon heißt? Hatte die einen
Ausweis dabei?
Wenn ich das mache, so hat zum einen das Verzeichnis /tmp/d die Rechte
"0000" (das habe ich Jörg vor ein paar Tagen per Mail geschickt) und zum
$ sudo ls -la /tmp/d
insgesamt 2616
d--------- 2 root root 392 12. Aug 12:05 .
drwxrwxrwt 15 root root 4096 12. Aug 12:07 ..
-r--r--r-- 1 root root 2672501 6. Aug 14:24 [2008-06-29--08.39.46] (cimg
Das ist ein anderes Problem das ich noch untersuchen muß....
In dem ISO Image befindet sich exakt 1 Datei. Das ISO Image habe ich
auf <http://michael-schmarck.share.s3.amazonaws.com/dcoulm/udf-test.iso>
zugÀnglich gemacht. Größe: 3.532.800 Bytes.
$ ~/.software/cdrecord-2.01.01/bin/mkisofs -version
mkisofs 2.01.01a45 (i686-pc-linux-gnu) Copyright (C) 1993-1997 Eric Youngdale (C) 1997-2008 Jᅵrg Schilling
Kann jemand das Problem nachvollziehen?
Ja, und unter Solaris kommt auch eine Fehlermeldung in /var/adm/messages
mit der ich das Problem einkreisen konnte.
--
EMail:***@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
***@cs.tu-berlin.de (uni)
***@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Michael Schmarck
2008-08-13 13:25:22 UTC
Permalink
Post by Michael Schmarck
Könnte jemand mal bitte verifizieren, ob er eine Datei mit *EXAKT* dem
o.g. Namen in ein UDF Image packen kann und dann von Linux/Windows
die Datei lesen kann?
cd /tmp
mkdir -p _test_/Urlaub/Sommerurlaub\ 2008\,\ El\ Ràfol\ d\'Almúnia\,\
Urbanización\ L\'Almúnia\,\ Pego\,\ Spanien/2008-07-25 date >
"_test_/Urlaub/Sommerurlaub 2008, El Ràfol d'Almúnia, Urbanización
L'Almúnia, Pego, Spanien/2008-07-25/[2008-06-29--08.39.46] (cimg5553)
Insekt “Karl Egon”, Wohnzimmer, Sommerurlaub 2008, El Ràfol d'Almúnia,
Urbanización L'Almúnia, Pego, Spanien, {2.5 MB}.jpg" mkisofs
-rational-rock -rrip112 -input-charset utf-8 -o /tmp/test.iso -dir-mode
0755 -udf -verbose _test_/U*/S*/2*/*2* mkdir /tmp/d mount -o loop,ro
/tmp/test.iso /tmp/d
Woher weist Du da� die Schabe Karl Egon hei�t? Hatte die einen
Ausweis dabei?
Sie sagte mir den Namen bei der "Eingangskontrolle". Glaubst Du
ernsthaft, ich würde jemanden in die Wohnung lassen, die mir nicht
einen/ihren Namen sagt? :)
Post by Michael Schmarck
Wenn ich das mache, so hat zum einen das Verzeichnis /tmp/d die Rechte
"0000" (das habe ich Jörg vor ein paar Tagen per Mail geschickt) und zum
$ sudo ls -la /tmp/d
insgesamt 2616
d--------- 2 root root 392 12. Aug 12:05 .
drwxrwxrwt 15 root root 4096 12. Aug 12:07 ..
-r--r--r-- 1 root root 2672501 6. Aug 14:24 [2008-06-29--08.39.46] (cimg
Das ist ein anderes Problem das ich noch untersuchen mu�....
Falls Dein mkisofs auf Grund "schlechter" Eingangswerte Müll baut, dann
würde es mich nicht wundern, wenn Linux dann mit dem Müll nicht klar
kommt...
Post by Michael Schmarck
In dem ISO Image befindet sich exakt 1 Datei. Das ISO Image habe ich
auf <http://michael-schmarck.share.s3.amazonaws.com/dcoulm/udf-test.iso>
zugänglich gemacht. Größe: 3.532.800 Bytes.
$ ~/.software/cdrecord-2.01.01/bin/mkisofs -version
mkisofs 2.01.01a45 (i686-pc-linux-gnu) Copyright (C) 1993-1997 Eric
Youngdale (C) 1997-2008 J�rg Schilling
Kann jemand das Problem nachvollziehen?
Ja, und unter Solaris kommt auch eine Fehlermeldung in /var/adm/messages
mit der ich das Problem einkreisen konnte.
Schön. Nur so interessehalber: Liegt es an Zeichen “ und ”? Du hast
also die ISO Datei? Dann kann ich sie ja wieder löschen.

Michael
Joerg Schilling
2008-08-13 13:33:15 UTC
Permalink
Post by Michael Schmarck
Woher weist Du daᅵ die Schabe Karl Egon heiᅵt? Hatte die einen
Ausweis dabei?
Sie sagte mir den Namen bei der "Eingangskontrolle". Glaubst Du
ernsthaft, ich wÃŒrde jemanden in die Wohnung lassen, die mir nicht
einen/ihren Namen sagt? :)
Also ich hätte sie trotzdem nicht reingelassen ;-)
Post by Michael Schmarck
Post by Michael Schmarck
insgesamt 2616
d--------- 2 root root 392 12. Aug 12:05 .
drwxrwxrwt 15 root root 4096 12. Aug 12:07 ..
-r--r--r-- 1 root root 2672501 6. Aug 14:24 [2008-06-29--08.39.46] (cimg
Das ist ein anderes Problem das ich noch untersuchen muᅵ....
Falls Dein mkisofs auf Grund "schlechter" Eingangswerte MÃŒll baut, dann
wÃŒrde es mich nicht wundern, wenn Linux dann mit dem MÃŒll nicht klar
kommt...
Dieses Problem kann eigentlich nicht auftreten wein Du -udf
statt -UDF verwendet hast und weil die Directory unter Rock Ridge korrekte
Rechte hat. Ich weis nicht wie aufwendig das zu untersuchen ist.
Post by Michael Schmarck
Post by Michael Schmarck
Kann jemand das Problem nachvollziehen?
Ja, und unter Solaris kommt auch eine Fehlermeldung in /var/adm/messages
mit der ich das Problem einkreisen konnte.
Schön. Nur so interessehalber: Liegt es an Zeichen “ und ”? Du hast
also die ISO Datei? Dann kann ich sie ja wieder löschen.
Sagen wir maal so: wenn Du diese Zeichen wegläßt, dann wird das Problem
bei Dir weggehen, genauso wenn Du den Filenamen kürzt.

UDF kann nach neuesten Erkenntnissen 254 Buchstaben in ISO-8859-1
und 127 Buchstaben in Hiragana oder was sonst nicht in ISO-8859-1
paßt.
--
EMail:***@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
***@cs.tu-berlin.de (uni)
***@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Michael Schmarck
2008-08-13 14:24:26 UTC
Permalink
Post by Michael Schmarck
Woher weist Du da� die Schabe Karl Egon hei�t? Hatte die einen
Ausweis dabei?
Sie sagte mir den Namen bei der "Eingangskontrolle". Glaubst Du
ernsthaft, ich würde jemanden in die Wohnung lassen, die mir nicht
einen/ihren Namen sagt? :)
Also ich h�tte sie trotzdem nicht reingelassen ;-)
Dummerweise wollte sie sich nicht so recht davon überzeugen lassen,
das sie doch bitte *JETZT* gehen solle :)
Post by Michael Schmarck
Post by Michael Schmarck
insgesamt 2616
d--------- 2 root root 392 12. Aug 12:05 .
drwxrwxrwt 15 root root 4096 12. Aug 12:07 ..
-r--r--r-- 1 root root 2672501 6. Aug 14:24 [2008-06-29--08.39.46] (cimg
Das ist ein anderes Problem das ich noch untersuchen mu�....
Falls Dein mkisofs auf Grund "schlechter" Eingangswerte Müll baut, dann
würde es mich nicht wundern, wenn Linux dann mit dem Müll nicht klar
kommt...
Dieses Problem kann eigentlich nicht auftreten wein Du -udf
statt -UDF verwendet hast und weil die Directory unter Rock Ridge korrekte
Rechte hat.
$ ~/.software/cdrecord-2.01.01/bin/mkisofs -rational-rock -rrip112 \
-input-charset utf-8 -o bilder.iso -dir-mode 0755 -udf \
-volid 'Bilder 2008' -verbose .

Ist das Problem irgendwie mit dem Problem verwandt, das ich Dir per
Mail geschildert hatte? Da ging's darum, das ich "mkisofs ... -find ..."
aufgerufen hatte und mkisofs sich dann Berechtigungen für die
Verzeichnisse "ausdenken" musste, die gefunden wurden. Auch dabei
hatten die Verzeichnisse (incl. /) ja "0000" als Berechtigung.
Ich weis nicht wie aufwendig das zu untersuchen ist.
Hapert es an einem Testcase? Oder soll ich Dir auch ein Test-ISO
zur Verfügung stellen?
Post by Michael Schmarck
Post by Michael Schmarck
Kann jemand das Problem nachvollziehen?
Ja, und unter Solaris kommt auch eine Fehlermeldung in /var/adm/messages
mit der ich das Problem einkreisen konnte.
Schön. Nur so interessehalber: Liegt es an Zeichen “ und ”? Du hast
also die ISO Datei? Dann kann ich sie ja wieder löschen.
Sagen wir maal so: wenn Du diese Zeichen wegl��t, dann wird das Problem
bei Dir weggehen, genauso wenn Du den Filenamen k�rzt.
Ok.
UDF kann nach neuesten Erkenntnissen 254 Buchstaben in ISO-8859-1
und 127 Buchstaben in Hiragana oder was sonst nicht in ISO-8859-1
pa�t.
Achso. 254 Byte für Namen. Dank dieser Sonderzeichen in meinem Dateinamen
mag der Name länger als 254 Zeichen sein.

Unklar ist mir allerdings, warum der Name/die Anzeige des Namens, so früh
abgebrochen wird. Kannst Du das verstehen?

Michael
Joerg Schilling
2008-08-13 15:01:29 UTC
Permalink
Post by Joerg Schilling
UDF kann nach neuesten Erkenntnissen 254 Buchstaben in ISO-8859-1
und 127 Buchstaben in Hiragana oder was sonst nicht in ISO-8859-1
paᅵt.
Achso. 254 Byte fÃŒr Namen. Dank dieser Sonderzeichen in meinem Dateinamen
mag der Name lÀnger als 254 Zeichen sein.
Unklar ist mir allerdings, warum der Name/die Anzeige des Namens, so frÃŒh
abgebrochen wird. Kannst Du das verstehen?
Ich dachte das wäre nun klar:

Die Filenamenlänge ist 127 es sei denn _alle_ Buchstaben passen
in ISO-8859-1
--
EMail:***@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
***@cs.tu-berlin.de (uni)
***@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Michael Schmarck
2008-08-13 15:35:12 UTC
Permalink
Die Filenamenl�nge ist 127 es sei denn _alle_ Buchstaben passen
in ISO-8859-1
Ohne mich blöde stellen zu wollen: Nein, das ist mir nicht klar. Warum
ist

00000000011111111112222222222333333333344444444445555555555666666666677777777788888888889999999999aaaaaaaaaabbbbbbbbbbcccccccccc

legal (hat 129 iso-8859-1 Zeichen), aber

¤€00000000011111111112222222222333333333344444444445555555555666666666677777777788888888889999999999aaaaaaaaaabbbbbbbbbbcccccccccc

nicht? Da hats auch 129 iso-8859-1 Zeichen + ¤ + €, weshalb dann auf
jeden Fall UTF-8 zu verwenden wäre.

Oder lassen wir mal das "warum" außen vor - verstehe ich Dich richtig,
das der 2. String (der mit "¤€" beginnt) bei UDF ein ungültiger Dateiname
wäre?

Wird bei UDF dann, wenn's min. 1 UTF-8 Zeichen gibt, alles in 2 Byte
gespeichert? Aber "a" braucht doch auch in UTF-8 nur 8 Bit / 1 Byte.
Werden dann bei UDF etwa 2 Byte für ein "a" veranschlagt, obwohl nur
1 Byte benötigt würde? Und wie steht's mit Zeichen, die in UTF-8 3 Byte
brauchen? Könnte man dann etwa auch 127 von diesen 3 Byte Zeichen
verwenden?

Beste Grüße,

Michael
Stefan Reuther
2008-08-13 17:50:06 UTC
Permalink
Post by Michael Schmarck
Wird bei UDF dann, wenn's min. 1 UTF-8 Zeichen gibt, alles in 2 Byte
gespeichert?
Genauso ist das.
Post by Michael Schmarck
Aber "a" braucht doch auch in UTF-8 nur 8 Bit / 1 Byte.
Werden dann bei UDF etwa 2 Byte für ein "a" veranschlagt, obwohl nur
1 Byte benötigt würde?
Ja. Ein Zeichen 16 Bit - alle Zeichen 16 Bit.
Post by Michael Schmarck
Und wie steht's mit Zeichen, die in UTF-8 3 Byte brauchen? Könnte man
dann etwa auch 127 von diesen 3 Byte Zeichen verwenden?
Ja.

Unicode ist eine Zeichentabelle mit momentan um die 70000 Zeichen. Um
diese abzuspeichern, gibt es nun mehrere Möglichkeiten. Einfache
Möglichkeiten sind "wenn alle Zeichen Codes < 256 haben, ein Oktett pro
Zeichen" (vulgo Latin-1) und "wenn alle Zeichen Codes < 65536 haben,
zwei Oktette pro Zeichen" (vulgo UCS-2). Das sind die Codierungen, die
UDF erlaubt.

Dann gibt es eben noch komplexere Kodierungen wie UTF-8, die man
normalerweise nimmt, wenn man nur Oktette speichern kann. Zum Beispiel
in einem Unix-Dateisystem.

Du kannst natürlich nun auch bescheißen. Wenn du dem mkisofs bzw. bei
Nutzung über Loopback-Mount dem Kernel sagst, deine Dateinamen seien
Latin-1, wird er die unverändert übernehmen (bei mkisofs müsste das über
die Locale-Einstellungen gehen, würde ich mal annehmen). Damit bekommst
du dann jeden Dateinamen mit bis zu 254 Oktetten auf das UDF-Datei-
system. Das kannst du dann aber eben nur auf dem gleichen Weg wieder
auslesen, Windows und alle anderen Systeme werden dir dann statt der
Nicht-ASCII-Zeichen die codierten UTF-8-Strings zeigen.

Aber sag bitte niemandem, dass ich das vorgeschlagen habe. Da ich für
unseren Medienplayer den ISO9660-Parser entwickelt habe, kommen nämlich
zu mir die User, die genau das gemacht haben, und maulen, dass ich die
Sonderzeichen falsch anzeigen würde :-)


Stefan
Michael Schmarck
2008-08-13 18:52:52 UTC
Permalink
(Ich lese und antworte von oben nach unten.)
Post by Stefan Reuther
Post by Michael Schmarck
Wird bei UDF dann, wenn's min. 1 UTF-8 Zeichen gibt, alles in 2 Byte
gespeichert?
Genauso ist das.
Aber dann ist's nicht UTF-8, oder?
Post by Stefan Reuther
Post by Michael Schmarck
Aber "a" braucht doch auch in UTF-8 nur 8 Bit / 1 Byte.
Werden dann bei UDF etwa 2 Byte für ein "a" veranschlagt, obwohl nur
1 Byte benötigt würde?
Ja. Ein Zeichen 16 Bit - alle Zeichen 16 Bit.
Welcher Zeichensatz ist das denn dann? Bei UTF-16 belegen "ASCII
Zeichen" (also z.B. "a") auch nur 1 Byte.
Post by Stefan Reuther
Post by Michael Schmarck
Und wie steht's mit Zeichen, die in UTF-8 3 Byte brauchen? Könnte man
dann etwa auch 127 von diesen 3 Byte Zeichen verwenden?
Ja.
Unicode ist eine Zeichentabelle mit momentan um die 70000 Zeichen. Um
diese abzuspeichern, gibt es nun mehrere Möglichkeiten. Einfache
Möglichkeiten sind "wenn alle Zeichen Codes < 256 haben, ein Oktett pro
Zeichen" (vulgo Latin-1) und "wenn alle Zeichen Codes < 65536 haben,
zwei Oktette pro Zeichen" (vulgo UCS-2). Das sind die Codierungen, die
UDF erlaubt.
Dh., bei UDF gibt's folgende Logik?

If "Alle Zeichen Codes < 256"; then
iso-8859-1 (also ein Oktett pro Zeichen)
else
ucs-2 (also 2 Oktette pro Zeichen)
end

So in etwa?
Post by Stefan Reuther
[ Erklärung ]
Danke. So einigermaßen habe ich das, glaube ich, kapiert.

Michael
Joerg Schilling
2008-08-13 21:07:05 UTC
Permalink
Post by Michael Schmarck
Post by Stefan Reuther
Ja. Ein Zeichen 16 Bit - alle Zeichen 16 Bit.
Welcher Zeichensatz ist das denn dann? Bei UTF-16 belegen "ASCII
Zeichen" (also z.B. "a") auch nur 1 Byte.
Das ist definitiv falsch
Post by Michael Schmarck
Dh., bei UDF gibt's folgende Logik?
If "Alle Zeichen Codes < 256"; then
iso-8859-1 (also ein Oktett pro Zeichen)
else
ucs-2 (also 2 Oktette pro Zeichen)
end
Ja
--
EMail:***@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
***@cs.tu-berlin.de (uni)
***@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Joerg Schilling
2008-08-13 20:17:27 UTC
Permalink
Post by Stefan Reuther
Unicode ist eine Zeichentabelle mit momentan um die 70000 Zeichen. Um
Zur Zeit nutzt Unicode 21 Bit, das wären dann 2097151 mögliche Kodierungen.
Post by Stefan Reuther
diese abzuspeichern, gibt es nun mehrere Möglichkeiten. Einfache
Möglichkeiten sind "wenn alle Zeichen Codes < 256 haben, ein Oktett pro
Zeichen" (vulgo Latin-1) und "wenn alle Zeichen Codes < 65536 haben,
zwei Oktette pro Zeichen" (vulgo UCS-2). Das sind die Codierungen, die
UDF erlaubt.
Das klappt deshalb, weil nahezu alle möglichen sinnvollen Kodierungen
in den Berich passen der mit nur 16 Bit darstellbar ist.
Post by Stefan Reuther
Dann gibt es eben noch komplexere Kodierungen wie UTF-8, die man
normalerweise nimmt, wenn man nur Oktette speichern kann. Zum Beispiel
in einem Unix-Dateisystem.
UTF-8 ist ein Standard der, wie vieles häufig benutzte, auf einer Serviette
in einem Abendessen von Ken Thompson entworfen wurde.

Er durfte "in" einem Buchstaben kein '/' und kein '\0' kodieren und sollte
Fehlkodierungen erkennbar machen sowie das "ende" eine Buchstabens auffindbar
machen.

UTF-8 kodiert bis zu 32 Bit in bis zu 6 Oktetten.
Post by Stefan Reuther
Du kannst natÃŒrlich nun auch bescheißen. Wenn du dem mkisofs bzw. bei
Nutzung ÃŒber Loopback-Mount dem Kernel sagst, deine Dateinamen seien
Latin-1, wird er die unverÀndert Ìbernehmen (bei mkisofs mÌsste das Ìber
die Locale-Einstellungen gehen, wÃŒrde ich mal annehmen). Damit bekommst
du dann jeden Dateinamen mit bis zu 254 Oktetten auf das UDF-Datei-
system. Das kannst du dann aber eben nur auf dem gleichen Weg wieder
auslesen, Windows und alle anderen Systeme werden dir dann statt der
Nicht-ASCII-Zeichen die codierten UTF-8-Strings zeigen.
Das mag unter Linux funktionieren, es wird aber nicht unter
MS-Win oder Solaris funktionieren. So wie Linux das mit der Mount-Option
zur Kodierung der Dateinamen macht ist es definitiv falsch. Wenn
überhaupt, dann müßte der Kern für jeden Prozess eine Prozesskodierung
kennen. UDF hat aber eine festgelegte Kodierung mit UNICODE.
Post by Stefan Reuther
Aber sag bitte niemandem, dass ich das vorgeschlagen habe. Da ich fÃŒr
unseren Medienplayer den ISO9660-Parser entwickelt habe, kommen nÀmlich
zu mir die User, die genau das gemacht haben, und maulen, dass ich die
Sonderzeichen falsch anzeigen wÃŒrde :-)
Wenn Linux mal repariert wird, dann wird das auch nicht mehr funktionieren ;-)
--
EMail:***@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
***@cs.tu-berlin.de (uni)
***@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Michael Schmarck
2008-08-13 15:43:06 UTC
Permalink
Die Filenamenl�nge ist 127 es sei denn _alle_ Buchstaben passen
in ISO-8859-1
Ach - mir ist noch was unklar: Bei meinem "komischen" Dateinamen werden
weit weniger als 127 Zeichen angezeigt. Oder wird dann der komplette
Pfadname (also Verzeichnisnamen + Dateiname) berücksichtigt?

Michael
Thomas Kosch
2008-08-12 10:07:22 UTC
Permalink
Post by Michael Schmarck
ch habe jetzt endlich cdrtools-2.01.01a45 installiert. Wie müsste ich
mkisofs aufrufen, so das Dateien ins ISO übernommen werden, deren
Dateiname bis zu 238 Zeichen lang ist und deren Pfad ca. 100 Zeichen
lang ist (also Verzeichnisnamen + Dateiname)? Und zwar so, das Windows
2000 und Windows XP eine mit diesem ISO gebrannte DVD einlesen
können und die Dateinamen komplett anzeigen?
Wenn ich mir die man page von mkisofs durchlese, wahrscheinlich gar
nicht.

-UDF Include UDF support in the generated filesystem image.
UDF support is currently in alpha status and for this
reason, it is not possible to create UDF only images.
UDF data structures are currently coupled to the Joliet
structures, so there are many pitfalls with the current
implementation.
--
Life is Xerox, and you're just a copy
Loading...