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

Groups > de.comp.os.unix.linux.misc > #124734

Re: rsync und vfat

Show all headers | View raw

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.

Back to de.comp.os.unix.linux.misc | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

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

csiph-web