Aktualisierung von hart verlinkten Dateien

[Dalai]

Hallo Leute ,

ich möchte mir mal wieder Rat und Anregungen holen für ein Thema, das mir seit einiger Zeit keine Ruhe lässt, und das nebenbei auch noch lästig ist.

Situation: Ich habe auf meiner Platte an mehreren Stellen Dateien hart verlinkt. Diese Verlinkung habe ich mittels NTFS Links erstellt, da kann man nun nichts falsch machen, andererseits auch nichts weiter einstellen; sei's drum.

Ein Problem entsteht nun, sobald ich eine der "Kopien" der hart verlinkten Dateien aktualisiere. Konkret sind hier Virensignaturen für ClamWin im Spiel, die ich mit wget neu aus dem Internet runterlade, aber das nur am Rande, denn dasselbe lässt sich natürlich auch mit einer Aktualisierung von lokaler Quelle reproduzieren. Die im aktiven Verzeichnis liegende Datei zeigt TC korrekt mit den neuen Informationen (Größe, Datum usw.) an. Aber die Informationen ausnahmslos aller verlinkter Dateien desselben Namens in anderen Verzeichnissen werden nicht aktualisiert, egal wie oft ich Strg+R drücke. Ich muss immer erst

• Alt+Enter auf die verlinkten Dateien machen
• die Datei mit F3 im Lister anzeigen
• Win32-artige Tips einschalten und die Maus über die Datei halten

damit danach auch TC die neuen Informationen anzeigt . Das ist lästig und müsste IMO gar nicht sein.

Leider hat sich auch mit TC 8.5 daran nichts geändert; ich habe vorhin gerade die Beta 12 probiert (mit frischer INI natürlich).

Ist das Verhalten bekannt? Kann man etwas dagegen tun? Gibt's noch jemanden hier, der das ebenfalls kennt? Kann das jemand nachvollziehen?

MfG Dalai

[GoFi]

Das Verhalten ist normal. NTFS aktualisiert die Metadaten erst mit dem Öffnen der Datei (z.B. F3).

[Dalai]

Ja, das habe ich mir gedacht, nachdem ich eine Nacht darüber geschlafen habe. Das erklärt auch, warum mkisofs beim Verarbeiten beide Dateien nicht als identisch erkennt, solange man nicht die Infos zu beiden Exemplaren von Hand erneuert hat.

OK, es ist also eine Eigenart von NTFS. Aber wie kann ich mir das Leben damit einfacher machen, also das Öffnen der verlinkten Dateien automatisieren? Bislang ist mir nur eingefallen, alle von im separaten Lister öffnen zu lassen, um die Lister-Prozesse im Anschluss (nach einer kleinen Verzögerung) zu töten. Gibt's da was besseres?

MfG Dalai

[sqa_wizard]

Gibt's da was besseres?

Vielleicht eine Inhalts-Plugin in einer "Benutzerdefinierte Spalte", das die Datei "ein bisschen" öffnet?

[Dalai]

Ich hab eine für mich brauchbare Lösung gefunden: ein Durchsuchen der Dateien mittels grep, mit Abbruch nach dem ersten Treffer. Da ich den Download sowieso per Skript erledigen lasse, bietet sich das an, und es bedarf keiner weiteren Interaktion.

Trotzdem ist das wieder so ein Feature von Windows, das MS deutlich besser implementieren hätte können und müssen. Witzigerweise hab ich Hardlinks auf einem Linux-System noch nie benutzen müssen, weil sich alles, was ich bislang brauchte, mit Symlinks lösen ließ. Aber Windows brät da wieder ne Extrawurst und erlaubt/ermöglicht keine Symlinks auf Dateien . Oder hab ich diesbzgl. etwas übersehen?

MfG Dalai

[sqa_wizard]

erlaubt/ermöglicht keine Symlinks auf Dateien Mad. Oder hab ich diesbzgl. etwas übersehen?

Ein bisschen vielleicht

Ich benutze Link Shell Extension.
Damit lassen sich auch Symlinks auf Dateien erzeugen.
(Nativ auf Windows 7, mit extra Treiber auch auf Windows XP)
Nachteil: Ein Symlink hat immer 0 Byte und das Erstellungsdatum.

[Dalai]

Nachteil: Ein Symlink hat immer 0 Byte und das Erstellungsdatum.

Genau das meinte ich mit ordentlicher Implementation. OK, auf einem Linux-System hat ein Symlink auch immer das Erstellungsdatum (und eine Größe entsprechend des Zielpfads), aber wenigstens sieht man, wohin das Ding zeigt. Selbst mit dem Plugin nl_info sehe ich nicht, wohin der Symlink einer Datei zeigt, und auch nicht, dass es ein Symlink ist. MS hat hier den Lauf mittendrin abgebrochen, wahrscheinlich weil sie meinten, die Hürden wären zu hoch...

TC kann die symbolisch verlinkten Dateien auch nicht (vernünftig) kopieren - das resultiert in einer normalen Datei mit 0 Byte Größe. Kopiert man (aus Versehen) bei einer Verzeichnissynchronisierung den Symlink mit, ergibt das irgendwelchen Wirrwarr (Originaldatei mit 0 Byte). Also müsste man den davon ausschließen, was nahezu unmöglich ist, da beide denselben Dateinamen haben; und absolute Pfade auszuschließen kann auch nicht die Lösung sein.

Um nochmal auf das nl_info zurückzukommen und warum mir das wichtig ist: Ich möchte in der Lage sein, verlinkte Dateien/Verzeichnisse (mit TC) zu finden. Dafür braucht es natürlich Plugins, die irgendeinen Unterschied zu normalen Dateien aufzuspüren in der Lage sind.

Fassen wir zusammen: Symbolische Links auf Dateien sind möglich, aber man kauft sich damit ganz erhebliche Nachteile ein, weil die Tools damit nicht umgehen können. Hätte MS die Implementation von Anfang an ordentlich gemacht, gäbe es auch passende Tools und man könnte Verlinkungen deutlich stressfreier nutzen.

Danke fürs Mitdenken , aber ich bleib bei Hardlinks, die XP auch nativ unterstützt.

MfG Dalai

[sqa_wizard]

Selbst mit dem Plugin nl_info sehe ich nicht, wohin der Symlink einer Datei zeigt, und auch nicht, dass es ein Symlink ist.

Doch, das geht gut (nl_info 1.20):

Code: Select all

UNACEV2.DLL	Symbolic Link:	C:\WinTools\TotalCmdBeta\UNACEV2.DLL

[Dalai]

Selbst mit dem Plugin nl_info sehe ich nicht, wohin der Symlink einer Datei zeigt, und auch nicht, dass es ein Symlink ist.

Doch, das geht gut (nl_info 1.20):

Code: Select all

UNACEV2.DLL	Symbolic Link:	C:\WinTools\TotalCmdBeta\UNACEV2.DLL

Du hast Recht. Ich sollte erst die Plugins aktualisieren, bevor ich Unsinn poste . Dennoch bleiben die anderen genannten Nachteile bestehen.

MfG Dalai