Dateinamen Windows, UDF (DVD) bzw. ISO9660 (CD) kompatibel machen
Michael Schmarck
Ich habe hier eine "Unmenge" von Dateien, die die Dateisyst
Michael
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 :).
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
Michael Schmarck
> · Michael Schmarck <michael....@here.la> schrieb:
>
>> 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
Niklaus Kuehnis
> 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
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
> > Michael Schmarck <michael....@here.la> wrote:
> >
> >> 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.
> Und tar kann nicht so einfach
> auf Windows XP verwendet werden (ohne Zusatztools).
Ja, da nimmt man z.B. cygwin.
> Zumal: Könnte man ein solches Tar dann überhaupt auf Windows
> schmerzfrei entpacken?
Ich denke schon, falls NTFS mit solchen Pfadlängen umgehen kann.
> 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
> Michael Schmarck <michael....@here.la> wrote:
>> · Niklaus Kuehnis <kuehni...@gmx-topmail.de>:
>
>> > Michael Schmarck <michael....@here.la> wrote:
>> >
>> >> 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.
>> 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.
>> 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)
Danke, mal antesten!
Michael
Bernd Mayer
>
> 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!
Michael Schmarck
> · Michael Schmarck <michael....@here.la> schrieb:
>
>> 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.
>> 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).
> 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
Michael Schmarck
> · Michael Schmarck <michael....@here.la> schrieb:
>
>>> 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 :)
>> 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.
> Den vollen Dateinamen wird man damit aber auch nicht retten können.
Klar.
Vielen Dank,
Michael
Michael Schmarck
> · Michael Schmarck <michael....@here.la> schrieb:
>
>> Doch, ist es.
>
> Und welches?
Die Installation und das benutzen des Programmes.
>> 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.
>> 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 :)
> Das hat auch nichts mehr mit dem verwendeten Zeichensatz zu tun, sondern
> mit den Eigenarten des Dateisystems.
Unstrittig.
Michael
Juergen Ilse
Michael Schmarck <michael....@here.la> wrote:
> · Martin Schnitkemper <news.trash...@spamgourmet.com>:
>> · Michael Schmarck <michael....@here.la> schrieb:
>>>> 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 (jue...@usenet-verwaltung.de)
--
Ein Domainname (auch wenn er Teil einer Mailadresse ist) ist nur ein Name,
nicht mehr und nicht weniger ...
Thomas Kosch
> Michael Schmarck <michael....@here.la> wrote:
> > 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
Thomas Kosch
> > 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.
Michael Schmarck
> Hallo,
>
> Michael Schmarck <michael....@here.la> wrote:
>> · Martin Schnitkemper <news.trash...@spamgourmet.com>:
>>> · Michael Schmarck <michael....@here.la> schrieb:
>>>>> 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
Michael Schmarck
> Michael Schmarck <michael....@here.la> wrote:
>
>> > 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
Michael Schmarck
> Niklaus Kuehnis <kuehni...@gmx-topmail.de> wrote:
>
>> Michael Schmarck <michael....@here.la> wrote:
>
>> > 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
Juergen Ilse
Michael Schmarck <usenet-...@schmarck.cn> wrote:
> Thomas Kosch <no_...@schuckeduster.org> wrote:
>> Michael Schmarck <michael....@here.la> wrote:
>>> > 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 ...).
Stefan Reuther
> 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.
> 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
> Michael Schmarck wrote:
>> 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.
>> 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
Michael Schmarck
> Michael Schmarck wrote:
>> 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.
>> 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
Thomas Kosch
> * Thomas Kosch <no_...@schuckeduster.org> schrieb:
>
> > Niklaus Kuehnis <kuehni...@gmx-topmail.de> wrote:
> >
> >> Michael Schmarck <michael....@here.la> wrote:
> >
> >> > 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.
Thomas Kosch
> Thomas Kosch <no_...@schuckeduster.org> wrote:
>
> > Niklaus Kuehnis <kuehni...@gmx-topmail.de> wrote:
> >
> >> Michael Schmarck <michael....@here.la> wrote:
> >
> >> > 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?
Thomas Kosch
> Hallo,
>
> Michael Schmarck <usenet-...@schmarck.cn> wrote:
> > Thomas Kosch <no_...@schuckeduster.org> wrote:
> >> Michael Schmarck <michael....@here.la> wrote:
> >>> > 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
Michael Schmarck
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.
> 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
> Thomas Kosch <no_...@schuckeduster.org> wrote:
>
> > Michael Schmarck <usenet-...@schmarck.cn> wrote:
> >
> >> Thomas Kosch <no_...@schuckeduster.org> wrote:
> >>
> >> > Niklaus Kuehnis <kuehni...@gmx-topmail.de> wrote:
> >> >
> >> >> Michael Schmarck <michael....@here.la> wrote:
> >> >
> >> >> > 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:
Ich lasse jetzt extra das ganze stehen.
> Wenn ja: Nein, damit kann Winzip nicht umgehen. Bzw. es kann damit
Du befauptest also WinZip kann nicht mit tar Archiven umgehen?
> umgehen, aber es werden dann "verhunzte" Dateinamen erzeugt. Unschön.
Oder jetzt doch, aber niurgendwie auch nicht?
> > 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.
Michael Schmarck
> Michael Schmarck <usenet-...@schmarck.cn> wrote:
>
>> Thomas Kosch <no_...@schuckeduster.org> wrote:
>>
>> > Michael Schmarck <usenet-...@schmarck.cn> wrote:
>> >
>> >> Thomas Kosch <no_...@schuckeduster.org> wrote:
>> >>
>> >> > Niklaus Kuehnis <kuehni...@gmx-topmail.de> wrote:
>> >> >
>> >> >> Michael Schmarck <michael....@here.la> wrote:
>> >> >
>> >> >> > 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:
>
> Ich lasse jetzt extra das ganze stehen.
Okay.
>
>> 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?
>> umgehen, aber es werden dann "verhunzte" Dateinamen erzeugt. Unschön.
>
> Oder jetzt doch, aber niurgendwie auch nicht?
Lies einfach, was ich geschrieben habe.
>> > 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
> Thomas Kosch <no_...@schuckeduster.org> wrote:
> > Michael Schmarck <usenet-...@schmarck.cn> wrote:
> >> Thomas Kosch <no_...@schuckeduster.org> wrote:
> >> > Michael Schmarck <usenet-...@schmarck.cn> wrote:
> >> >> Thomas Kosch <no_...@schuckeduster.org> wrote:
> >> >> > Niklaus Kuehnis <kuehni...@gmx-topmail.de> wrote:
> >> >> >> Michael Schmarck <michael....@here.la> wrote:
> >> >
> >> > Wie währe es mal mit lesen?
> Wie währe es mit lesen?
Am besten den Rechtschreibe-Duden.
scnr,
Niklaus
Heike C. Zimmerer
Michael Schmarck
> Michael Schmarck <usenet-...@schmarck.cn> wrote:
>> Thomas Kosch <no_...@schuckeduster.org> wrote:
>> > Michael Schmarck <usenet-...@schmarck.cn> wrote:
>> >> Thomas Kosch <no_...@schuckeduster.org> wrote:
>> >> > Michael Schmarck <usenet-...@schmarck.cn> wrote:
>> >> >> Thomas Kosch <no_...@schuckeduster.org> wrote:
>> >> >> > Niklaus Kuehnis <kuehni...@gmx-topmail.de> wrote:
>> >> >> >> Michael Schmarck <michael....@here.la> wrote:
>> >> >
>> >> > 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...
Juergen Ilse
Um zum restlichen Thread zu pssen, müsstest du jetzt aber schreiben:
:) Was lange wärt ...
Tschüss,
Jürgen Ilse (jue...@usenet-verwaltung.de)
Joerg Schilling
Michael Schmarck <michael....@emailbase.de> wrote:
>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.
>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.
>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:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni)
schi...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Joerg Schilling
Michael Schmarck <michael....@emailbase.de> wrote:
>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.
Joerg Schilling
Michael Schmarck <usenet-...@schmarck.cn> wrote:
>Thomas Kosch <no_...@schuckeduster.org> wrote:
>
>> Michael Schmarck <michael....@here.la> wrote:
>>
>>>
>>> Ich glaube nicht, das NTFS damit umgehen könnte.
>>
>> Glauben kannst du in der Kirche. Die Maximale Pfadlänge bei NTFS ist
>
>Okay. Interessanterweise meldet RAR eine Fehlermeldung, die besagt,
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.
Joerg Schilling
Ulf Volmer <u.vo...@u-v.de> wrote:
>>> 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 ;-)
Joerg Schilling
Heiko Schlenker <hsc...@gmx.de> wrote:
>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/
>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.
>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 . _ -
Und POSIX sagt nur man soll diesen Zeichensatz als "Rückfall" vewenden.
Michael Schmarck
> In article <6f5g6tF...@mid.individual.net>,
> Michael Schmarck <usenet-...@schmarck.cn> wrote:
>>Thomas Kosch <no_...@schuckeduster.org> wrote:
>>
>>> Michael Schmarck <michael....@here.la> wrote:
>>>
>>>> > 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
frank paulsen
> In article <6f2rnnF...@mid.individual.net>,
> Michael Schmarck <michael....@emailbase.de> wrote:
>>
>>Nun möchte ich das ganze auf DVD brennen und von Windows drauf
>>zugreifen.
[...]
> 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
Markus Kohm
> Es würde also keine .rar-Datei weiteregegeben werden, sondern eine
> .exe-Datei.
...
> 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
> Michael Schmarck wrote:
>
>> Es würde also keine .rar-Datei weiteregegeben werden, sondern eine
>> .exe-Datei.
> ...
>> 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?
> <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
Michael Schmarck
> 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
Helmut Hullen
Du meintest am 04.08.08:
>> 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".
Markus Kohm
> 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.
> 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 ...
> 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!
> 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
Arno Welzel
> In article <slrng8tvtu....@humbert.ddns.org>,
> Heiko Schlenker <hsc...@gmx.de> wrote:
>
>> 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/
Zumindest solltest Du dann auch bei deinen Postings auf
standardkonformität achten - ansonsten hinterlässt der Hinweis einen
komischen Nachgeschmack.
Stefan Reuther
> In article <slrng8s43u....@x2-5.u-v.de>,
>>>>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
> Michael Schmarck wrote:
>
>> Bei einem SFX muss der Anwender nur auf die Datei einen Doppelklick
>> machen, und es passiert was.
>
[...]
>
>> 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.
> 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).
>> 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.
> 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.
>> 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?
> 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?
> 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
Joerg Schilling
Michael Schmarck <usenet-...@schmarck.cn> wrote:
>> 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.
Joerg Schilling
Heiko Schlenker <hsc...@gmx.de> wrote:
>>>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.
Michael Schmarck
> In article <6fo6vnF...@mid.individual.net>,
> Michael Schmarck <usenet-...@schmarck.cn> wrote:
>
>>> 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
Michael Schmarck <usenet-...@schmarck.cn> wrote:
>Joerg Schilling <j...@cs.tu-berlin.de> wrote:
>
>> In article <6fo6vnF...@mid.individual.net>,
>> Michael Schmarck <usenet-...@schmarck.cn> wrote:
>>
>>>> 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.
Arno Welzel
> In article <6fo6vnF...@mid.individual.net>,
> Michael Schmarck <usenet-...@schmarck.cn> wrote:
>
>>> 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.
> 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.
Joerg Schilling
Arno Welzel <use...@arnowelzel.de> wrote:
>> 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.
Arno Welzel
> In article <g7a8gu$gg1$1...@registered.motzarella.org>,
> Arno Welzel <use...@arnowelzel.de> wrote:
>
>>> 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 <6fo6vnF...@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."
> 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.
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..
Michael Schmarck
> In article <g7a8gu$gg1$1...@registered.motzarella.org>,
> Arno Welzel <use...@arnowelzel.de> wrote:
>
>>> 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.
> Abgesehen davon habe ich in einem anderen Artikel die eigentliche
> Frage beantwortet:
Stimmt - und dafür bin ich Dir auch sehr dankbar!
Michael
Ansgar Strickerschmidt
>> 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
> In article <6fr0c6F...@mid.individual.net>,
> Michael Schmarck <usenet-...@schmarck.cn> wrote:
>>Joerg Schilling <j...@cs.tu-berlin.de> wrote:
>>
>>> In article <6fo6vnF...@mid.individual.net>,
>>> Michael Schmarck <usenet-...@schmarck.cn> wrote:
>>>
>>>>> 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?
> Bei Dir bin ich mir da aber nicht so sicher.
Sei Dir sicher.
Michael
Michael Schmarck
> Joerg Schilling schrieb:
>
>> In article <g7a8gu$gg1$1...@registered.motzarella.org>,
>> Arno Welzel <use...@arnowelzel.de> wrote:
>>
>>>> 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.
> 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.
> Und das
> Win32-Binaries innerhalb der nöchsten paar Monate von Vista nicht mehr
> startbar sind, ist äusserst unwahrscheinlich.
Eben.
[...]
>> 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.
>
> 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.
> 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
> Am 05.08.2008, 21:09 Uhr, schrieb Arno Welzel <use...@arnowelzel.de>:
>
>>> 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.
> 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
<usenet-...@schmarck.cn>:
>> 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.
Michael Schmarck
> Am 06.08.2008, 09:27 Uhr, schrieb Michael Schmarck
> <usenet-...@schmarck.cn>:
>
>>> 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.
> 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.
> 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.
> 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.
> 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
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
Michael Schmarck
> In article <6f2rnnF...@mid.individual.net>,
> Michael Schmarck <michael....@emailbase.de> wrote:
>>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
> In article <6f2rnnF...@mid.individual.net>,
> Michael Schmarck <michael....@emailbase.de> wrote:
>>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
Ansgar Strickerschmidt
<usenet-...@schmarck.cn>:
> --($ ~/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.
> Dh. aus irgendeinem Grund wurde auch bei Linux etwas abgeschnitten.
Vermutlich dank der eckigen Klammern...
Michael Schmarck
> Am 11.08.2008, 13:55 Uhr, schrieb Michael Schmarck
> <usenet-...@schmarck.cn>:
>
>> --($ ~/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.
> 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
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).
> 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?
> 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?
> 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 so einer Textdatei kann man dann leicht 'greppen' (für Windozer:
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.
> 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.
> 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.
> 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.
>> 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
> · Ansgar Strickerschmidt <dropsp...@onlinehome.de>:
>
>> Am 11.08.2008, 13:55 Uhr, schrieb Michael Schmarck
>> <usenet-...@schmarck.cn>:
>>
>>> --($ ~/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.
>
>> 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
>
> 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).
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
Was ich ja auch zusätzlich mache, wie ich schon mehrfach schrieb.
> 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?
> 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
Michael Schmarck <usenet-...@schmarck.cn> writes:
> > 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
Sebastian Waschik <sebastia...@gmx.de> wrote:
> Hallo,
>
> Michael Schmarck <usenet-...@schmarck.cn> writes:
>> > 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.)
> 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?
> 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.
> 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
>
> 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
>
> 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
>
> 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.
Michael Schmarck
> Michael Schmarck schrieb:
>>
>> 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
Helmut Hullen
Du meintest am 12.08.08:
>>> 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
> 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.
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
Thomas Kosch
> 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
Markus Wichmann
> Bernd Mayer <beam.b...@knuut.de> wrote:
>
>> Michael Schmarck schrieb:
>>>
>>> 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.
> 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.
> 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
Ansgar Strickerschmidt
<usenet-...@schmarck.cn>:
> 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.
:)
Michael Schmarck
> Michael Schmarck <usenet-...@schmarck.cn> schrieb:
>> Bernd Mayer <beam.b...@knuut.de> wrote:
>>
>>> Michael Schmarck schrieb:
>>>>
>>>> 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:
Danke. mkudffs kannte ich noch nicht. linux-udf scheint aber auch seit 2004
tot zu sein, oder trügt der Anschein?
[...]
> 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.
>> 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.
> 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
Joerg Schilling
Michael Schmarck <usenet-...@schmarck.cn> wrote:
>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
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
>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
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:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni)
schi...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Michael Schmarck
> In article <6gd6evF...@mid.individual.net>,
> Michael Schmarck <usenet-...@schmarck.cn> wrote:
>
>>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
>
> 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? :)
>>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
>
> 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...
>>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
Markus Wichmann
> Markus Wichmann <null...@gmx.net> wrote:
>
>> UDF würde ich _immer_ mit dem dafür ausgelegten Tool erstellen:
>> mkudffs. Herangehensweise:
>
> 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.
> [...]
>> 4. Dateien reinkopieren (das kriegste gerade noch so selbst hin, wa?)
>
> Nein, bekomme ich nicht :(
>
[...]
> 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...
[...]
>> 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
>
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...).
> Michael
Tschö,
Markus
Joerg Schilling
Michael Schmarck <usenet-...@schmarck.cn> wrote:
>> 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 ;-)
>>>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.
>>>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.
Michael Schmarck
> In article <6gg5lvF...@mid.individual.net>,
> Michael Schmarck <usenet-...@schmarck.cn> wrote:
>
>>> 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 :)
>>>>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?
>>>>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
Michael Schmarck
> 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
Joerg Schilling
Michael Schmarck <usenet-...@schmarck.cn> wrote:
>> 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
Michael Schmarck
> Ich dachte das w�re nun klar:
>
> 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
Michael Schmarck
> 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
Stefan Reuther
> Wird bei UDF dann, wenn's min. 1 UTF-8 Zeichen gibt, alles in 2 Byte
> gespeichert?
Genauso ist das.
> 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.
> 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
· Stefan Reuther <stefa...@arcor.de>:
> Michael Schmarck wrote:
>> 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?
>> 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.
>> 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?
> [ Erklärung ]
Danke. So einigermaßen habe ich das, glaube ich, kapiert.
Michael
Joerg Schilling
Stefan Reuther <stefa...@arcor.de> wrote:
>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.
>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.
>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.
>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.
>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 ;-)