[linux-l] Zusammenfassung: Dateien mit '/' im Dateinamen

[Stefan Bund]

Oswald Buddenhagen <ossi at kde.org> writes:
> für mich hört sich das erstmal nach humbug an. wieso sollte man es bei
> reiserfs nicht auch einfach '/' -> '_' umschreiben können? so lange die
> offsets stimmen, ist alles ok. das würde natürlich nicht mehr gelten,
> wenn reiserfs zusätzlich checksums auf die daten legt, aber davon weiß
> ich nichts (verändern, reiserfsck read-only ausführen - wenn er meckert,
> weiß ich wieder was neues). 

So weit ich reiserfs verstanden habe, ist das Problem ein anderes: Die
Verzeichnisse werden eben nicht wie bei ext2 als einfache Listen
angelegt sondern in einer Baumstruktur. Aus diesem Grund kann reiserfs
auch sehr performant mit großen Verzeichnissen umgehen. Wenn ich jetzt
einen Dateinamen verändere, muss stimmt die Sortierung im Baum nicht
mehr, vom Suchalgorithmus wird die Datei also nicht mehr gefunden.

Habe gerade mal im reiserfs source code nachgesehen. In
linux/fs/reiserfs/namei.c findet sich folgeder Kommentar:

  // directory item contains array of entry headers. This performs
  // binary search through that array

Das bedeutet, das ein directory item ein *sortiertes* array von keys
ist. In der obigen Funktion findet sich

  // this is not name found, but matched third key component
  de->de_entry_num = j;
  return NAME_FOUND;

Also ist die Liste nach 'third key component' sortiert. Weiter unten
in namei.c:

  /* Keyed 32-bit hash function using TEA in a Davis-Meyer function */
  
  /* The third component is hashed, and you can choose from more than
     one hash function.  Per directory hashes are not yet implemented
     but are thought about. This function should be moved to hashes.c
     Jedi, please do so.  -Hans */
  
  static __u32 get_third_component (struct super_block * s, 
                                    const char * name, int len)
  {
      [...]  
      res = s->u.reiserfs_sb.s_hash_function (name, len);
      [...]
      return res + MAX_GENERATION_NUMBER;
  } 

woraus ich schließe, das die 'third component' ein Hash aus dem
Dateinamen ist. Ich bin mir garantiert nicht hundertprozentig sicher,
ob meine obige Analyse stimmt, aber ich komme erst mal zu dem Schluss,
das sehr warscheinlich die Verzeichniss von reiserfs Hashtabellen sind
(ok, keine Bäume, das war die Datenstruktur ...). Wenn ich einen
Dateinamen ändere, findet er sich in einer anderen slot der
Hashtabelle wieder. Passe ich die Sortierung nicht an, so werde ich
den Namen nicht mehr finden, da ich ja im falschen slot suche.

Auf jeden Fall reicht obige Analyse für mich, das ich es nicht
versuchen werde. Außerdem habe ich den Eindruck, dass zumindestens das
alte reserfsck solche fehler nicht findet. Vieleicht die neue Version,
müsste ich mal testen. Auf jeden Fall habe ich nach oben gesagten
nicht mehr versucht, mit einem Dieskeditor das Problem zu lösen ...

> ansonsten ist es für mich eher die frage, ob
> es einen disk-editor gibt, der die struktur richtig interpretiert, so
> daß man auch gleich die stelle findet, die man verändern muß. als ich
> vor zwei oder so jahren nach intelligenten linux-diskeditoren gesucht
> habe, sah es recht duster aus.

Für ext2 scheint es lde zu geben, und der kennt die interne Struktur
von ext2. Für reiserfs habe ich nichts gefunden. Ich hätte mit einfach
die Partition komplett nach dem betreffenden Dateinamen durchsucht.

Tschüß, Stefan.

-- 
Stefan Bund, Dipl.Phys.                   a   r   T   e  c      _____
Entwicklung, Administration               visual solutions     / |  /|
                                                              |----/_|
sbund at artec-berlin.com                                        | /  | /
Fon: 030 / 884684-0 | Fax: 030 / 884684-15                    |/___|/

Gottfried-von-Cramm-Weg 35-37 | Berlin | 14193 | http://www.artec-berlin.com