Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comp.os.unix.linux.misc > #124679 > unrolled thread

rsync und vfat

Back to article view | Back to de.comp.os.unix.linux.misc

Contents

  rsync und vfat Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2022-09-03 14:53 +0000
    Re: rsync und vfat Kay Martinen <usenet@martinen.de> - 2022-09-03 17:42 +0200
      Re: rsync und vfat Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2022-09-03 18:15 +0000
    Re: rsync und vfat Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-09-03 17:59 +0200
      Re: rsync und vfat Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2022-09-03 18:16 +0000
        Re: rsync und vfat Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-09-04 01:47 +0200
          Re: rsync und vfat Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2022-09-04 09:18 +0000
            Re: rsync und vfat Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-09-04 14:34 +0200
              Re: rsync und vfat Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-09-04 15:03 +0200
              Re: rsync und vfat Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2022-09-04 23:02 +0000
                Re: rsync und vfat Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-09-05 22:06 +0200
    Re: rsync und vfat Tim Landscheidt <tim@tim-landscheidt.de> - 2022-09-03 16:50 +0000
      Re: rsync und vfat Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2022-09-03 18:17 +0000
        Re: rsync und vfat Tim Landscheidt <tim@tim-landscheidt.de> - 2022-09-03 23:21 +0000
          Re: rsync und vfat Stefan Reuther <stefan.news@arcor.de> - 2022-09-04 08:36 +0200
            Re: rsync und vfat Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2022-09-04 09:21 +0000
              Re: rsync und vfat Stefan Reuther <stefan.news@arcor.de> - 2022-09-05 11:24 +0200
                Re: rsync und vfat Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-09-05 13:05 +0200
    Re: rsync und vfat Tim Ritberg <tim@server.invalid> - 2022-09-03 20:33 +0200
      Re: rsync und vfat Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2022-09-03 19:35 +0000
        Re: rsync und vfat Tim Ritberg <tim@server.invalid> - 2022-09-04 11:08 +0200
          Re: rsync und vfat Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2022-09-04 09:47 +0000
            Re: rsync und vfat Tim Ritberg <tim@server.invalid> - 2022-09-04 12:07 +0200
              Re: rsync und vfat Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2022-09-04 22:56 +0000
            Re: rsync und vfat Tim Landscheidt <tim@tim-landscheidt.de> - 2022-09-04 13:29 +0000
            Re: rsync und vfat Laurenz Trossel <me@example.invalid> - 2022-09-04 14:47 +0000
    Re: rsync und vfat Arno Welzel <usenet@arnowelzel.de> - 2022-09-03 23:07 +0200
      Re: rsync und vfat Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2022-09-03 21:14 +0000
    Re: rsync und vfat Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2022-09-04 23:24 +0000
      Re: rsync und vfat Marcel Mueller <news.5.maazl@spamgourmet.org> - 2022-09-07 11:09 +0200
        Re: rsync und vfat Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2022-09-07 21:35 +0000
    Re: rsync und vfat Marcel Mueller <news.5.maazl@spamgourmet.org> - 2022-09-07 10:54 +0200
      Re: rsync und vfat Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2022-09-07 21:39 +0000
    Re: rsync und vfat Matthias Gerds <m.gerds@posteo.de> - 2022-09-07 13:26 +0200
      Re: rsync und vfat Marcel Mueller <news.5.maazl@spamgourmet.org> - 2022-09-07 15:57 +0200

Page 1 of 2  [1] 2  Next page →

#124679 — rsync und vfat

Ich hab oefters das Problem, dass ich Dateien auf vfat kopieren will und
dann mit dessen Dateinamen-Einschraenkungen zu kaempfen hab, weshalb rsync
nicht anwendbar ist.

Mir wuerde es voellig reichen, wenn die Dateien waehrend des Kopierens
umgenannt werden, als zB s/:/_/

rsync bietet so was aber nicht an.

Also selber ein rsync-aehnliches tool schreiben?

Aber da muss es doch was fertiges geben, ich bin doch nicht der Erste mit
dem Problem?


-- 
Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum TIK         
Universitaet Stuttgart         E-Mail: horlacher@tik.uni-stuttgart.de
Allmandring 30a                Tel:    ++49-711-68565868
70569 Stuttgart (Germany)      WWW:    http://www.tik.uni-stuttgart.de/

[toc] | [next] | [standalone]

#124682

Am 03.09.22 um 16:53 schrieb Ulli Horlacher:
> Ich hab oefters das Problem, dass ich Dateien auf vfat kopieren will und
> dann mit dessen Dateinamen-Einschraenkungen zu kaempfen hab, weshalb rsync
> nicht anwendbar ist.

Wo und wie liegen denn die Quelldateien vor? Könnte man das Medium
direkt als vfat einrichten? Müßte im Ergebnis eine 1:1 Kopie möglich
machen, ohne Konvertierung.

> Aber da muss es doch was fertiges geben, ich bin doch nicht der Erste mit
> dem Problem?

Wäre eine Lösung denkbar die dateien auf dem Quellmedium direkt
vfat-kompatibel zu speichern und dann ggf. eine eher DOS-Typische
Kopiermethode zu verwenden? Alternative wäre auch noch das auf dem
Quellmedium durch ein script o.a. konvertierung an zu passen um beim
eigentlichen Kopieren dieses Problem nicht mehr zu bekommen.

Ｂｙｅ／
   ／Ｋａｙ

-- 
"Kann ein Wurstbrot die Welt retten?" :-)

[toc] | [prev] | [next] | [standalone]

#124692

Kay Martinen <usenet@martinen.de> wrote:
> Am 03.09.22 um 16:53 schrieb Ulli Horlacher:
> > Ich hab oefters das Problem, dass ich Dateien auf vfat kopieren will und
> > dann mit dessen Dateinamen-Einschraenkungen zu kaempfen hab, weshalb rsync
> > nicht anwendbar ist.
> 
> Wo und wie liegen denn die Quelldateien vor?

Auf einem (bzw diversen) POSIX filesystemen.


> Könnte man das Medium direkt als vfat einrichten? 

Nein.


> Wäre eine Lösung denkbar die dateien auf dem Quellmedium direkt
> vfat-kompatibel zu speichern

Nein.


-- 
Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum TIK         
Universitaet Stuttgart         E-Mail: horlacher@tik.uni-stuttgart.de
Allmandring 30a                Tel:    ++49-711-68565868
70569 Stuttgart (Germany)      WWW:    http://www.tik.uni-stuttgart.de/

[toc] | [prev] | [next] | [standalone]

#124683

 Ulli Horlacher <framstag@rus.uni-stuttgart.de>:
> Ich hab oefters das Problem, dass ich Dateien auf vfat kopieren 
> will und dann mit dessen Dateinamen-Einschraenkungen zu kaempfen 
> hab, weshalb rsync nicht anwendbar ist.
>
> Mir wuerde es voellig reichen, wenn die Dateien waehrend des 
> Kopierens umgenannt werden, als zB s/:/_/
>
> rsync bietet so was aber nicht an. 
>
>
> Also selber ein rsync-aehnliches tool schreiben? 
>
>
> Aber da muss es doch was fertiges geben, ich bin doch nicht der 
> Erste mit dem Problem?

 Wenn sich GNU‐Tar für die Kopieraufgabe eignet, wäre die Option 
 «--transform=SED-EXPR» vielleicht eine Möglichkeit, Dateinamen im 
 Vorübergehen umzubenennen:


   ( cd -- "$quelle" && tar cf - . ) |
   ( cd -- "$ziel" && tar xf - --transform=s/:/_/g )

 Wie sieht es mit Hard‐ und Symlinks aus?  Da streckt doch VFAT 
 auch die Waffen, richtig?

[toc] | [prev] | [next] | [standalone]

#124693

Helmut Waitzmann <nn.throttle@xoxy.net> wrote:
> Ulli Horlacher <framstag@rus.uni-stuttgart.de>:
> > Ich hab oefters das Problem, dass ich Dateien auf vfat kopieren 
> > will und dann mit dessen Dateinamen-Einschraenkungen zu kaempfen 
> > hab, weshalb rsync nicht anwendbar ist.
> >
> > Mir wuerde es voellig reichen, wenn die Dateien waehrend des 
> > Kopierens umgenannt werden, als zB s/:/_/
> >
> > rsync bietet so was aber nicht an. 
> >
> >
> > Also selber ein rsync-aehnliches tool schreiben? 
> >
> >
> > Aber da muss es doch was fertiges geben, ich bin doch nicht der 
> > Erste mit dem Problem?
> 
> Wenn sich GNU?Tar für die Kopieraufgabe eignet, wäre die Option 
> «--transform=SED-EXPR» vielleicht eine Möglichkeit, Dateinamen im 
> Vorübergehen umzubenennen:
> 
> 
>   ( cd -- "$quelle" && tar cf - . ) |
>   ( cd -- "$ziel" && tar xf - --transform=s/:/_/g )

Das kopiert IMMER ALLES.
Ich brauch inkrementeles copy.


> Wie sieht es mit Hard? und Symlinks aus?  Da streckt doch VFAT 
> auch die Waffen, richtig?

Brauch ich nicht.


-- 
Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum TIK         
Universitaet Stuttgart         E-Mail: horlacher@tik.uni-stuttgart.de
Allmandring 30a                Tel:    ++49-711-68565868
70569 Stuttgart (Germany)      WWW:    http://www.tik.uni-stuttgart.de/

[toc] | [prev] | [next] | [standalone]

#124720

 Ulli Horlacher <framstag@rus.uni-stuttgart.de>:
> Helmut Waitzmann <nn.throttle@xoxy.net> wrote:
>> Ulli Horlacher <framstag@rus.uni-stuttgart.de>:
>>> Ich hab oefters das Problem, dass ich Dateien auf 
>>> vfat kopieren will und dann mit dessen 
>>> Dateinamen-Einschraenkungen zu kaempfen hab, 
>>> weshalb rsync nicht anwendbar ist.
>>>
>>> Mir wuerde es voellig reichen, wenn die Dateien 
>>> waehrend des Kopierens umgenannt werden, als zB 
>>> s/:/_/
>>>
>>> rsync bietet so was aber nicht an. 
>>>
>>>
>>> Also selber ein rsync-aehnliches tool schreiben? 
>>>
>>>
>>> Aber da muss es doch was fertiges geben, ich bin 
>>> doch nicht der Erste mit dem Problem?
>>
>> Wenn sich GNU?Tar für die Kopieraufgabe eignet, 
>> wäre die Option «--transform=SED-EXPR» vielleicht 
>> eine Möglichkeit, Dateinamen im Vorübergehen 
>> umzubenennen:
>>
>>
>>   ( cd -- "$quelle" && tar cf - . ) |
>>   ( cd -- "$ziel" && tar xf - --transform=s/:/_/g )
>
> Das kopiert IMMER ALLES. 
> Ich brauch inkrementeles copy.
>

 Mit den entsprechenden Optionen tut es das nicht.  Du 
 hast bisher nichts dazu geschrieben, nach welchen 
 Kriterien du entscheiden möchtest, ob eine Datei 
 (erneut) kopiert werden soll oder nicht.  Deshalb 
 kann man dir auch keine konkreten «tar»‐Optionen 
 nennen, die da hilfreich wären.

 Schau im «tar»‐Handbuch nach, was «tar» dir an 
 Optionen zur Dateiauswahl und zur Einschränkung nach 
 Zeitstempeln bietet.  Ich werf' mal ein paar in den 
 Ring: «--after» «--no-recursion», «--files-from», 
 «--null», «--listed-incremental».


 Ansonsten kannst du auch «find» verwenden:  Geh den 
 Quell‐Dateibaum durch:  Berechne für jede Quelldatei 
 den Zieldateinamen gemäß der von dir festgelegten 
 Dateinamenumsetzung, dann finde (anhand der 
 Zeitstempel oder sonst wie – du hast bisher nichts 
 dazu geschrieben –) heraus, ob eine (erneute) Kopie 
 notwendig ist.  Ist das der Fall, kopiere die Datei; 
 ansonsten geh zur nächsten weiter.

 Am besten kommst du dabei vermutlich zurecht, wenn du 
 auf jeden Dateinamen ein Shell‐Skript, das gemäß der 
 gewählten Kriterien geschrieben sein muss, aufrufst:

 (
   cd -- "$quelle" &&
   find . -type f -exec das_Skript "$ziel" '{}' \;
 )

[toc] | [prev] | [next] | [standalone]

#124729

Helmut Waitzmann <nn.throttle@xoxy.net> wrote:

> >> Wenn sich GNU?Tar für die Kopieraufgabe eignet, 
> >> wäre die Option «--transform=SED-EXPR» vielleicht 
> >> eine Möglichkeit, Dateinamen im Vorübergehen 
> >> umzubenennen:
> >>
> >>
> >>   ( cd -- "$quelle" && tar cf - . ) |
> >>   ( cd -- "$ziel" && tar xf - --transform=s/:/_/g )
> >
> > Das kopiert IMMER ALLES. 
> > Ich brauch inkrementeles copy.
> >
> 
> Mit den entsprechenden Optionen tut es das nicht.  Du 
> hast bisher nichts dazu geschrieben, nach welchen 
> Kriterien du entscheiden möchtest, ob eine Datei 
> (erneut) kopiert werden soll oder nicht. 

Wenn Datei mit gleichem oder neuerem Datum vorhanden ist, soll nicht
kopiert werden.


> Schau im «tar»?Handbuch nach, was «tar» dir an 
> Optionen zur Dateiauswahl und zur Einschränkung nach 
> Zeitstempeln bietet.  Ich werf' mal ein paar in den 
> Ring: «--after» «--no-recursion», «--files-from», 
> «--null», «--listed-incremental».

Ah, ok --keep-newer-files waers.

Das bezieht sich aufs auspacken. Somit werden die Dateien aber auch
gelesen, was laestig ist, weil es zu lange dauert.


> Ansonsten kannst du auch «find» verwenden:  Geh den 
> Quell?Dateibaum durch:  Berechne für jede Quelldatei 
> den Zieldateinamen gemäß der von dir festgelegten 
> Dateinamenumsetzung, dann finde (anhand der 
> Zeitstempel oder sonst wie ? du hast bisher nichts 
> dazu geschrieben ?) heraus, ob eine (erneute) Kopie 
> notwendig ist.  Ist das der Fall, kopiere die Datei; 
> ansonsten geh zur nächsten weiter.
> 
> Am besten kommst du dabei vermutlich zurecht, wenn du 
> auf jeden Dateinamen ein Shell?Skript, das gemäß der 
> gewählten Kriterien geschrieben sein muss, aufrufst:
> 
> (
>   cd -- "$quelle" &&
>   find . -type f -exec das_Skript "$ziel" '{}' \;
> )

Programmieren kann ich :-)
Ich MUSS aber nicht alles selber neu machen, wenn es schon wo eine Loesung
fuer das Problem gibt.


-- 
Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum TIK         
Universitaet Stuttgart         E-Mail: horlacher@tik.uni-stuttgart.de
Allmandring 30a                Tel:    ++49-711-68565868
70569 Stuttgart (Germany)      WWW:    http://www.tik.uni-stuttgart.de/

[toc] | [prev] | [next] | [standalone]

#124734

Ulli Horlacher <framstag@rus.uni-stuttgart.de>:
>Helmut Waitzmann <nn.throttle@xoxy.net> wrote:
>
>>>> Wenn sich GNU?Tar für die Kopieraufgabe eignet, 
>>>> wäre die Option «--transform=SED-EXPR» vielleicht 
>>>> eine Möglichkeit, Dateinamen im Vorübergehen 
>>>> umzubenennen:
>>>>
>>>>
>>>>   ( cd -- "$quelle" && tar cf - . ) |
>>>>   ( cd -- "$ziel" && tar xf - --transform=s/:/_/g )
>>>
>>> Das kopiert IMMER ALLES.
>>> Ich brauch inkrementeles copy.
>>>
>>
>> Mit den entsprechenden Optionen tut es das nicht.  Du 
>> hast bisher nichts dazu geschrieben, nach welchen 
>> Kriterien du entscheiden möchtest, ob eine Datei 
>> (erneut) kopiert werden soll oder nicht. 
>
>Wenn Datei mit gleichem oder neuerem Datum vorhanden ist, soll nicht 
>kopiert werden.

Da beginnt der Spaß bereits:  Welcher Zeitstempel 
soll verglichen werden?

Zum Archivieren ist eigentlich nur der Zeitstempel 
der letzten Inode‐Änderung sinnvoll – der Zeitstempel 
der letzten Dateiinhaltsänderung genügt im 
Allgemeinen nicht.  Andererseits gibt es aber im 
VFAT‐Dateisystem keinen Zeitstempel der letzten 
Inode‐Änderung.  Es müsste also zunächst festgelegt 
werden, wie man in diesem Spezialfall entscheidet, 
welche Dateien (aufs Neue) zu kopieren sind.

>> Schau im «tar»?Handbuch nach, was «tar» dir an 
>> Optionen zur Dateiauswahl und zur Einschränkung nach 
>> Zeitstempeln bietet.  Ich werf' mal ein paar in den 
>> Ring: «--after» «--no-recursion», «--files-from», 
>> «--null», «--listed-incremental».
>
>Ah, ok --keep-newer-files waers. 
>
>
>Das bezieht sich aufs auspacken. Somit werden die Dateien aber auch 
>gelesen, was laestig ist, weil es zu lange dauert.
>

Ja, absolut.  Das ist inakzeptabel.  Aber 
«--after-date» (auch «--newer» genannt) bezieht sich 
aufs Einpacken.  Vielleicht ist aber 
«--listed-incremental» besser.

>
>> Ansonsten kannst du auch «find» verwenden:  Geh den 
>> Quell?Dateibaum durch:  Berechne für jede Quelldatei 
>> den Zieldateinamen gemäß der von dir festgelegten 
>> Dateinamenumsetzung, dann finde (anhand der 
>> Zeitstempel oder sonst wie ? du hast bisher nichts 
>> dazu geschrieben ?) heraus, ob eine (erneute) Kopie 
>> notwendig ist.  Ist das der Fall, kopiere die Datei; 
>> ansonsten geh zur nächsten weiter.
>>
>> Am besten kommst du dabei vermutlich zurecht, wenn du 
>> auf jeden Dateinamen ein Shell?Skript, das gemäß der 
>> gewählten Kriterien geschrieben sein muss, aufrufst:
>>
>> (
>>   cd -- "$quelle" &&
>>   find . -type f -exec das_Skript "$ziel" '{}' \;
>> )
>
>Programmieren kann ich :-) 
>
>Ich MUSS aber nicht alles selber neu machen, wenn es schon wo 
>eine Loesung fuer das Problem gibt.

Ich vermute, genau das ist das Problem:  Es gibt 
keine Lösung für das Problem (jedenfalls nicht im 
allgemeinen Fall), weil dem VFAT‐Dateisystem die 
Zeitstempel der letzten Inode‐Änderung, die 
Eigentümerschaft und Gruppenzugehörigkeit sowie deren 
Zugriffsrechte fehlen, und, weil das 
Dateinamensproblem nicht gelöst ist.

Je nach Spezialfall kann man um beide Probleme 
herumkommen, indem man sich in den Dateinamen 
beschränkt und sich nicht alle Dateioperationen in 
den beteiligten Dateisystemen erlaubt (Wie will man 
das jeweils technisch sicherstellen?); aber diese 
Lösung verdient dann ihren Namen nicht mehr.

Ich meine, mich zu erinnern, dass man GNU‐Tar statt 
den Zeitstempel der letzten Inode‐Änderung den 
Zeitstempel der letzten Dateiinhaltsänderung 
verwenden lassen kann.  Um dann noch korrekte 
Ergebnisse zu erhalten, muss man sich verbieten, 
einem Inode oder einem Dateinamen jemals einen 
älteren Zeitstempel der letzten Inhaltsänderung zu 
verpassen als er zuvor hatte:  Damit muss man sich 
Operationen wie

  cp -p -- …

  cp --preserve=timestamps -- …

  mv -- …

  ln -- …

  chmod -- …

  chown -- …

  chgrp -- …

verbieten.

[toc] | [prev] | [next] | [standalone]

#124735

Helmut Waitzmann <nn.throttle@xoxy.net>:
>Ulli Horlacher <framstag@rus.uni-stuttgart.de>:
>>Wenn Datei mit gleichem oder neuerem Datum vorhanden ist, soll nicht 
>>kopiert werden.
>
>Da beginnt der Spaß bereits:  Welcher Zeitstempel 
>soll verglichen werden?
>
>Zum Archivieren ist eigentlich nur der Zeitstempel 
>der letzten Inode‐Änderung sinnvoll – der Zeitstempel 
>der letzten Dateiinhaltsänderung genügt im 
>Allgemeinen nicht.  Andererseits gibt es aber im 
>VFAT‐Dateisystem keinen Zeitstempel der letzten 
>Inode‐Änderung.  Es müsste also zunächst festgelegt 
>werden, wie man in diesem Spezialfall entscheidet, 
>welche Dateien (aufs Neue) zu kopieren sind.

[…]

>Ich vermute, genau das ist das Problem:  Es gibt 
>keine Lösung für das Problem (jedenfalls nicht im 
>allgemeinen Fall), weil dem VFAT‐Dateisystem die 
>Zeitstempel der letzten Inode‐Änderung, die 
>Eigentümerschaft und Gruppenzugehörigkeit sowie deren 
>Zugriffsrechte fehlen, und, weil das 
>Dateinamensproblem nicht gelöst ist.
>
>Je nach Spezialfall kann man um beide Probleme 
>herumkommen, indem man sich in den Dateinamen 
>beschränkt und sich nicht alle Dateioperationen in 
>den beteiligten Dateisystemen erlaubt (Wie will man 
>das jeweils technisch sicherstellen?); aber diese 
>Lösung verdient dann ihren Namen nicht mehr.
>
>Ich meine, mich zu erinnern, dass man GNU‐Tar statt 
>den Zeitstempel der letzten Inode‐Änderung den 
>Zeitstempel der letzten Dateiinhaltsänderung 
>verwenden lassen kann.  Um dann noch korrekte 
>Ergebnisse zu erhalten, muss man sich verbieten, 
>einem Inode oder einem Dateinamen jemals einen 
>älteren Zeitstempel der letzten Inhaltsänderung zu 
>verpassen als er zuvor hatte:  Damit muss man sich 
>Operationen wie
>
>  cp -p -- …
>
>  cp --preserve=timestamps -- …
>
>  mv -- …
>
>  ln -- …
>
>  chmod -- …
>
>  chown -- …
>
>  chgrp -- …
>
>verbieten.

Man kann das Verbot einschränken:  Wenn man nach so 
einer «verbotenen» Dateioperation allen beteiligten 
Dateien, die dabei einen neuen Zeitstempel der 
letzten Inode‐Änderung erfahren haben – im Fall des 
VFAT‐Dateisystems: erfahren hätten – noch den 
Zeitstempel der letzten Dateiinhaltsänderung 
etwa mit dem Kommando

   touch -m -- …

erneuert, dann ist die «verbotene» Dateioperation 
erlaubt.

[toc] | [prev] | [next] | [standalone]

#124742

Helmut Waitzmann <nn.throttle@xoxy.net> wrote:

> >Wenn Datei mit gleichem oder neuerem Datum vorhanden ist, soll nicht 
> >kopiert werden.
> 
> Da beginnt der Spaß bereits:  Welcher Zeitstempel 
> soll verglichen werden?

modification time


> Zum Archivieren

Ich will nichts Archivieren.


(tar)
> >Ah, ok --keep-newer-files waers. 
> >
> >
> >Das bezieht sich aufs auspacken. Somit werden die Dateien aber auch 
> >gelesen, was laestig ist, weil es zu lange dauert.
> 
> Ja, absolut.  Das ist inakzeptabel.  Aber 
> «--after-date» (auch «--newer» genannt) bezieht sich 
> aufs Einpacken.

Dann muesste ich erst die Datei mit dem juengsten Datum auf dem Zielmedium
ermitteln. Ok, das waere machbar.


> >Ich MUSS aber nicht alles selber neu machen, wenn es schon wo 
> >eine Loesung fuer das Problem gibt.
> 
> Ich vermute, genau das ist das Problem:  Es gibt 
> keine Lösung für das Problem (jedenfalls nicht im 
> allgemeinen Fall), weil dem VFAT?Dateisystem die 
> Zeitstempel der letzten Inode?Änderung, die 
> Eigentümerschaft und Gruppenzugehörigkeit sowie deren 
> Zugriffsrechte fehlen

Brauch ich alles nicht.


> und, weil das Dateinamensproblem nicht gelöst ist.

Fuer mich gibts eine akzeptable Loesung :-)
Mein Problem ist: ich bin wohl der Einzige der das so akzeptabel findet :-}


-- 
Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum TIK         
Universitaet Stuttgart         E-Mail: horlacher@tik.uni-stuttgart.de
Allmandring 30a                Tel:    ++49-711-68565868
70569 Stuttgart (Germany)      WWW:    http://www.tik.uni-stuttgart.de/

[toc] | [prev] | [next] | [standalone]

#124752

 Ulli Horlacher <framstag@rus.uni-stuttgart.de>:
> Helmut Waitzmann <nn.throttle@xoxy.net> wrote:
>
>>>Wenn Datei mit gleichem oder neuerem Datum vorhanden ist, soll 
>>>nicht kopiert werden.
>>
>> Da beginnt der Spaß bereits:  Welcher Zeitstempel soll 
>> verglichen werden?
>
> modification time
>

 Nimm lieber inode change time.  Das ist sicherer. 

>
>> Zum Archivieren 
>
> Ich will nichts Archivieren.
>

 Du willst aber wissen, was neu ist und deshalb kopiert 
 werden muss, und, was seit dem letzten Kopieren unverändert 
 geblieben ist und deshalb nicht noch einmal kopiert werden 
 soll.  Das ist dieselbe Aufgabe wie die, die beim 
 Archivieren zu erledigen ist.

>> «--after-date» (auch «--newer» genannt) bezieht sich aufs 
>> Einpacken.
>
> Dann muesste ich erst die Datei mit dem juengsten Datum auf dem Zielmedium 
> ermitteln. Ok, das waere machbar.
>

 Du müsstest ermitteln, ob du seit dem letzten Kopieren vom 
 Quellmedium auf dem Quellmedium Änderungen (die aufs 
 Zielmedium sollen) gemacht hast.  Dazu musst du dir bei 
 jedem Kopieren den Zeitpunkt des Kopierens merken und dann 
 beim nächsten Kopieren alle die Dateien kopieren, deren 
 Inode‐Change‐Zeitpunkt neuer ist als der gemerkte 
 Zeitpunkt.  GNU‐Tar kann das.

>
>>> Ich MUSS aber nicht alles selber neu machen, wenn es schon wo 
>>> eine Loesung fuer das Problem gibt.
>>

 Ich vermute, GNU‐Tar kommt einer fertigen Lösung schon 
 ziemlich nahe.

 Ich würde folgendes versuchen:  GNU‐Tar kann inkrementelle 
 Backups erstellen, indem es mit der Option 
 «--listed-incremental» eine Snapshot‐Datei erstellt, in der 
 er sich merkt, wann er jede Datei (ins Archiv) kopiert 
 hat, und, welche Zeitstempel sie dabei gehabt hat. Wenn 
 sie beim nächsten Kopieren immer noch den selben Zeitstempel 
 trägt, muss sie nicht neu kopiert werden.

   quelle='hier das Quellverzeichnis angeben'
   ziel='hier das Zielverzeichnis angeben'
   quelle="${quelle%/}" &&
   tar cf - --listed-incremental "${quelle:?}".tarss \
     -C "${quelle:?}" -- . |
   tar xf - --incremental --transform 's/:/_/g' \
     --show-transformed-names -C "${ziel:?}" --


 Nebenbei:  Kannst du deinen Newsreader so konfigurieren, 
 dass er kürzere Zeilen macht?  75 Zeichen lange Zeilen 
 werden bei mehrmaligem Zitieren schnell zu lang.

 Des weiteren fügt er zum Zitieren an die Zeilenanfänge ein 
 Größer‐als‐Zeichen gefolgt von einem Leerzeichen ein, also 
 so, wie das Kommando

   sed -e 's/^/> /'

 es tut.  Das ist für zitierte Zitate schlecht, weil es das
 händische Neuumbrechen der Zitate erschwert:  Zwischen 
 den Größer‐als‐Zeichen sollten keine Leerzeichen sein, weil 
 beim Neuumbrechen die Leerzeichen sonst Umbruchstellen 
 werden können.  Richtig gemacht, sollte der Newsreader beim 
 Zitieren wie

   sed -e 's/^/>/'

 verfahren.  Wenn ein Leerzeichen nach der Reihe der 
 Zitatmarkierungen gewünscht ist, kann er anschließend noch 
 wie

   sed -E -e 's/^(>+)([^> ])/\1 \2/'

 vorgehen.  Also: 


 Aus beispielsweise 


   >>>eins
   >>zwei
   >drei
   vier

 sollte beim Zitieren nicht 


   > >>>eins
   > >>zwei
   > >drei
   > vier

 sondern

   >>>>eins
   >>>zwei
   >>drei
   >vier

 oder

   >>>> eins
   >>> zwei
   >> drei
   > vier

 werden.

[toc] | [prev] | [next] | [standalone]

#124687

Ulli Horlacher <framstag@rus.uni-stuttgart.de> wrote:

> Ich hab oefters das Problem, dass ich Dateien auf vfat kopieren will und
> dann mit dessen Dateinamen-Einschraenkungen zu kaempfen hab, weshalb rsync
> nicht anwendbar ist.

> Mir wuerde es voellig reichen, wenn die Dateien waehrend des Kopierens
> umgenannt werden, als zB s/:/_/

> rsync bietet so was aber nicht an.

> Also selber ein rsync-aehnliches tool schreiben?

> Aber da muss es doch was fertiges geben, ich bin doch nicht der Erste mit
> dem Problem?

https://askubuntu.com/questions/11634/how-can-i-substitute-colons-when-i-rsync-on-a-usb-key/11762#11762
verweist auf ein FUSE-Modul posixovl, das Dateinamen
umschreibt.

Wenn es wirklich nur um ein einzelnes Zeichen geht und man
wagemutig ist, könnte ich mir vorstellen, dass man eine Kon-
vertierung mittels „--iconv“ und „//TRANSLIT“ oder gegebe-
nenfalls einem eigenen iconv-Modul hinbekäme. Aber das wäre
sehr viel Arbeit für ein sehr kleines Problem.

Tim

[toc] | [prev] | [next] | [standalone]

#124694

Tim Landscheidt <tim@tim-landscheidt.de> wrote:

> https://askubuntu.com/questions/11634/how-can-i-substitute-colons-when-i-rsync-on-a-usb-key/11762#11762
> verweist auf ein FUSE-Modul posixovl, das Dateinamen
> umschreibt.

Ich kann nicht ueberall Kernel-Module laden. Es muss mit User-Rechten gehen.


-- 
Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum TIK         
Universitaet Stuttgart         E-Mail: horlacher@tik.uni-stuttgart.de
Allmandring 30a                Tel:    ++49-711-68565868
70569 Stuttgart (Germany)      WWW:    http://www.tik.uni-stuttgart.de/

[toc] | [prev] | [next] | [standalone]

#124719

Ulli Horlacher <framstag@rus.uni-stuttgart.de> wrote:

>> https://askubuntu.com/questions/11634/how-can-i-substitute-colons-when-i-rsync-on-a-usb-key/11762#11762
>> verweist auf ein FUSE-Modul posixovl, das Dateinamen
>> umschreibt.

> Ich kann nicht ueberall Kernel-Module laden. Es muss mit User-Rechten gehen.

Und posixovl braucht mehr?

Tim

[toc] | [prev] | [next] | [standalone]

#124723

Am 04.09.2022 um 01:21 schrieb Tim Landscheidt:
> Ulli Horlacher <framstag@rus.uni-stuttgart.de> wrote:
>>> https://askubuntu.com/questions/11634/how-can-i-substitute-colons-when-i-rsync-on-a-usb-key/11762#11762
>>> verweist auf ein FUSE-Modul posixovl, das Dateinamen
>>> umschreibt.
> 
>> Ich kann nicht ueberall Kernel-Module laden. Es muss mit User-Rechten gehen.
> 
> Und posixovl braucht mehr?

Na erstmal fuse-Unterstützung im Kernel, und vorzugsweise noch User
Namespaces (oder ein suid fusermount binary), damit man als User
überhaupt mounten kann.

Die nachhaltige Lösung dürfte dennoch sein, entweder auf der Ziel-Seite
ein richtiges POSIX-Filesystem hinzusetzen (ist dann auch schneller!),
oder die Dateinamen auf der Quelle zu ändern. Ich hab hier noch ein paar
Dateien rumliegen, die zu Zeiten von ISO-8859-1 oder gar CP437 als
Systemzeichensatz erstellt wurden. Da schimpft der rsync vom
Systembackup auch immer, weil das Zielsystem (NTFS) nur UTF-8 frisst.
Wirklich gut hilft da nur umbenennen.


  Stefan

[toc] | [prev] | [next] | [standalone]

#124730

Stefan Reuther <stefan.news@arcor.de> wrote:

> Die nachhaltige Lösung dürfte dennoch sein, entweder auf der Ziel-Seite
> ein richtiges POSIX-Filesystem hinzusetzen (ist dann auch schneller!),

Die Zielhardware versteht ausschliesslich vfat.


> oder die Dateinamen auf der Quelle zu ändern.

Der Kluegere gibt so lange nach, bis er der Doofe ist?
NO WAY.


-- 
Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum TIK         
Universitaet Stuttgart         E-Mail: horlacher@tik.uni-stuttgart.de
Allmandring 30a                Tel:    ++49-711-68565868
70569 Stuttgart (Germany)      WWW:    http://www.tik.uni-stuttgart.de/

[toc] | [prev] | [next] | [standalone]

#124746

Am 04.09.2022 um 11:21 schrieb Ulli Horlacher:
> Stefan Reuther <stefan.news@arcor.de> wrote:
>> oder die Dateinamen auf der Quelle zu ändern.
> 
> Der Kluegere gibt so lange nach, bis er der Doofe ist?
> NO WAY.

Das mag vielleicht spannend sein, einen Spezial-Workaround für genau
deinen Anwendungsfall zu hacken, aber nachhaltig ist das halt nicht.

Ich meine, es würde ja auch keiner auf die Idee kommen, sein Backup auf
5.25" Disketten zu machen, weil hat man ja schon immer gemacht, und dann
nach Möglichkeiten zu suchen, wo man noch Laufwerke herbekommt. Und auch
für Browser, die nur SSL3 können, bauen wir hoffentlich keine Proxies
als Workaround, damit die wieder mit Google reden können.


  Stefan

[toc] | [prev] | [next] | [standalone]

#124748

Stefan Reuther <stefan.news@arcor.de> wrote:
>Und auch
>für Browser, die nur SSL3 können, bauen wir hoffentlich keine Proxies
>als Workaround, damit die wieder mit Google reden können.

Aber wenn wir mit einem modernen Browser mit einem fünf Jahre alten
LOM-Modul sprechen wollen, tun wir das. Oder haben irgendwo doch noch
ein Windows XP rumfliegen, weil das Ziel leider ein Java-Plugin
erwartet.

Grüße
Marc
-- 
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber         |   " Questions are the         | Mailadresse im Header
Mannheim, Germany  |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[toc] | [prev] | [next] | [standalone]

#124695

Am 03.09.22 um 16:53 schrieb Ulli Horlacher:
> Ich hab oefters das Problem, dass ich Dateien auf vfat kopieren will und
> dann mit dessen Dateinamen-Einschraenkungen zu kaempfen hab, weshalb rsync
> nicht anwendbar ist.
> 
> Mir wuerde es voellig reichen, wenn die Dateien waehrend des Kopierens
> umgenannt werden, als zB s/:/_/
> 
> rsync bietet so was aber nicht an.
> 
> Also selber ein rsync-aehnliches tool schreiben?
> 
> Aber da muss es doch was fertiges geben, ich bin doch nicht der Erste mit
> dem Problem?
Ist das für ein Backup?
Wie wärs damit?

https://www.gnu.org/software/tar/manual/html_node/Incremental-Dumps.html

Tim

[toc] | [prev] | [next] | [standalone]

#124699

Tim Ritberg <tim@server.invalid> wrote:
> Am 03.09.22 um 16:53 schrieb Ulli Horlacher:
> > Ich hab oefters das Problem, dass ich Dateien auf vfat kopieren will und
> > dann mit dessen Dateinamen-Einschraenkungen zu kaempfen hab, weshalb rsync
> > nicht anwendbar ist.
> > 
> Ist das für ein Backup?

Nein.

Audio und Video Dateien.

-- 
Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum TIK         
Universitaet Stuttgart         E-Mail: horlacher@tik.uni-stuttgart.de
Allmandring 30a                Tel:    ++49-711-68565868
70569 Stuttgart (Germany)      WWW:    http://www.tik.uni-stuttgart.de/

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | de.comp.os.unix.linux.misc

csiph-web