Hallo zusammen, ich möchte euch mal fragen, wie ihr das Problem löst. Es geht um die sinnvolle/sinnvollste Vergabe von Verzeichnissen. Verzeichnisse, die als X abgelegt sind, aber auch in Y interessant sind. Beispiel: Verzeichnis: "Bewerbungsunterlagen" ->> "Zeugnisse" Verzeichnis: "Dokumente" -------------------^ Das Verzeichnis "Bewerbungsunterlagen" beinhaltet das Verzeichnis "Zeugnisse". Unter "Dokumente" sollte aber auch "Zeugnisse" liegen, der Logik wegen.. Ich stoße da manchmal auf Probleme, wo ich was am Besten ablege, damit es sinnvoll ist.. Löst ihr das mit Verlinkungen oder habt ihr eine andere Lösung? Grüße
Johannes K. schrieb: > Löst ihr das mit Verlinkungen oder habt ihr eine andere Lösung? Unter Windows würde ich eine Verknüpfung zum Zeugnis-Ordner im Dokumente-Order anlegen. Unter Linux geht das wohl als (symbolischer) Link (noch nie benutzt).
Dateien kopieren, und frei über die Ordner verteilen. Bewerbungsunterlagen z.B. braucht man nur für einen begrenzten Zeitraum, danach kommt der Ordner ins Archiv oder in Ablage P. Die „Originale“ der Zeugnisse bleiben weiter unter Dokumente. Und weil das dann trotzdem garantiert in einem unüberschaubaren Ordner-Wust endet, gibts Dokumentenverwaltungssysteme. Damit sucht man nicht mehr nach Dokumenten, damit findet man die. Oliver
:
Bearbeitet durch User
Rahul D. schrieb: > Unter Linux geht das wohl als (symbolischer) Link (noch nie benutzt). Symbolic Links gibt es seit 4BSD bei Unixen. :-) Man kann dabei sowohl einzelne Dateien als auch ganze Verzeichnisse verlinken. Ansonsten könnte man natürlich auch alles in ein Git-Repo schieben und den Verweis als externes Repo linken.
Kommt auf die Menge der Dokumente an. Wirft man den Begriff "DMS" (document management system) in den Raum, zucken immer alle zusammen und stöhnen wegen des Aufwandes. Damit kann man nach Metadaten und Inhalten suchen, muss nicht (kann aber) wie Lieschen Müller auf Ordner verteilen. Es gibt auch "kleine" Lösungen bzw. Open Source, die entweder auf dem PC/Mac laufen oder einem NAS ... Beispiel: https://www.bitfarm-archiv.de/downloads-support/#downloads
Johannes K. schrieb: > ich möchte euch mal fragen, wie ihr das Problem löst. Hard-Links. Ein und dasselbe Dokument kann beliebig oft an verschiedenen Stellen im Filesystem erscheinen, verbraucht aber nur an einer Stelle Platz für den eigentlichen Inhalt der Datei. Ändert man den Inhalt an einer Stelle, ändert er sich automagisch auch an allen anderen Stellen. Das ist sehr schick, hat aber auch einen riesengroßen Nachteil: Das Löschen so eines Dokuments ist ein mehrstufiger (nichtatomarer) Prozess. Man muss alle Vorkommen finden und löschen, um am Ende wirklich das Dokument gelöscht zu haben.
Die Dateien sinnvoll benennen. Dann findet man die auch wieder wenn alles nur in einem Zeugnisse-Ordner liegt.
Ob S. schrieb: > Hard-Links. Ein und dasselbe Dokument kann beliebig oft an verschiedenen > Stellen im Filesystem erscheinen, verbraucht aber nur an einer Stelle > Platz für den eigentlichen Inhalt der Datei. Das ist natürlich DAS Argument. So ab einer Milliarde Dokumente könnte man drüber nachdenken… > Ändert man den Inhalt an > einer Stelle, ändert er sich automagisch auch an allen anderen Stellen. Kommt bei Zeugnissen u.ä. regulär eher selten vor. > Das ist sehr schick, hat aber auch einen riesengroßen Nachteil: Das > Löschen so eines Dokuments ist ein mehrstufiger (nichtatomarer) Prozess. > Man muss alle Vorkommen finden und löschen, um am Ende wirklich das > Dokument gelöscht zu haben. So isses. Praktisch nicht machbar. Oliver
Oliver S. schrieb: > Praktisch nicht machbar. Doch, natürlich ist das machbar. Die sinnvolle Benutzung der Locking-Mechanismen des FS helfen dabei enorm...
Oliver S. schrieb: > So isses. Praktisch nicht machbar. Hä? Dateisuche "xyz" -> Alle Ergebnisse löschen
Martin S. schrieb: > Oliver S. schrieb: >> So isses. Praktisch nicht machbar. > > Hä? Dateisuche "xyz" -> Alle Ergebnisse löschen So einfach ist es dann doch nicht. Solche primitiven Ansätze funktionieren nur, so lange es nur EINEN Nutzer des Datenbestands gibt.
Martin S. schrieb: > Hä? Dateisuche "xyz" -> Alle Ergebnisse löschen Zur Erinnerung: Ein Hardlink ist eine einzige Datei, die als „xyz“, „abc“, „def“, „ghi“, …, gleichzeitig im Dateisystem existiert. Wenn du da „xyz“ löschst, ist die Datei unter den anderen Namen immer noch da. Unter Unixoiden kann man da was mit ›find‹ bauen, wie es bei Windows aussieht, weiß ich nicht.
Jack V. schrieb: > Martin S. schrieb: >> Hä? Dateisuche "xyz" -> Alle Ergebnisse löschen > > Zur Erinnerung: Ein Hardlink ist eine einzige Datei, die als „xyz“, > „abc“, „def“, „ghi“, …, gleichzeitig im Dateisystem existiert. Wenn du > da „xyz“ löschst, ist die Datei unter den anderen Namen immer noch da. Es ist natürlich tatsächlich möglich, eine Datei als Hardlink unter verschiedenen Dateinamen erscheinen zu lassen, war aber hier ganz eindeutig nicht Designziel. Es ging vielmehr darum, sie mit demselben Dateinamen in verschiedenen Verzeichnissen erscheinen zu lassen.
Ob S. schrieb: > Es ging vielmehr darum, sie mit demselben > Dateinamen in verschiedenen Verzeichnissen erscheinen zu lassen. Tatsächlich ging es darum, ein Verzeichnis an verschiedenen Stellen im Verzeichnisbaum zu haben. An der Stelle sind Hardlinks sowieso raus. Alle gleichnamigen Files in verschiedenen Verzeichnissen löschen und hoffen, dass alle auf die Zieldatei zeigen, erscheint mir ansonsten auch etwas … aufregend ;)
Jack V. schrieb: > wie es bei Windows aussieht, weiß ich nicht Die kennen das Konzept eines Hardlinks einfach gar nicht.
Frank E. schrieb: > Kommt auf die Menge der Dokumente an. Wirft man den Begriff "DMS" > (document management system) in den Raum, zucken immer alle zusammen und > stöhnen wegen des Aufwandes. Die Anfrage klingt eher wie jemand, der seine Bewerbungsunterlagen nach Betrieben sortieren möchte, bei denen er sich bewirbt, aber die Zeugnisse nicht alle mehrfach auf seinem Laufwerk haben möchte. Wenn man natürlich Bewerbungen (als Betrieb) sammelt, sollte man nicht die Zeugnisse aller Bewerbenden "auf einen Haufen" werfen. DMS würde doch eh bedeuten, dass man irgendwelche Meta-Daten pflegt. Sowas verwendet man doch z.B. zum Nachverfolgen von Zeichnungsrevisionen.
Jörg W. schrieb: > Die kennen das Konzept eines Hardlinks einfach gar nicht. Doch (zumindes bei NTFS): "mklink /h <destination\Dateiname> <source\Dateiname>"
Beitrag #8026674 wurde vom Autor gelöscht.
Jack V. schrieb: > Tatsächlich ging es darum, ein Verzeichnis an verschiedenen Stellen im > Verzeichnisbaum zu haben. An der Stelle sind Hardlinks sowieso raus. Sagt wer? Zur Erinnerung: Verzeichnisse sind effektiv auch wieder nur Dateien (mit gewisser Zusatzfunktionalität und stark reglementiertem Zugriff auf die Dateiinhalte). Bei NTFS ist es so, dass die sog. "Junctions" effektiv Hardlinks auf die Verzeichnis-Datei sind, solange sich die Sache in einem FS abspielt. Erst wenn die Sache sich über mehrere Volumes erstreckt, kommt zusätzlich die Funktionalität als "symbolischer Link" zum Zuge, die eben das erlaubt.
Pat A. schrieb: > Jörg W. schrieb: >> Die kennen das Konzept eines Hardlinks einfach gar nicht. > > Doch (zumindes bei NTFS): > "mklink /h <destination\Dateiname> <source\Dateiname>" Du kannst doch nicht ernsthaft die Grundüberzeugungen von JW als falsch entlarven. Das ist reine Blasphemie, ein Vergehen gegen Gott höchstselbst. Dafür wirst du brennen, Ketzer!
Ob S. schrieb: > Bei NTFS ist es so, dass die sog. "Junctions" effektiv Hardlinks auf die > Verzeichnis-Datei sind, solange sich die Sache in einem FS abspielt. Wie gesagt, wie es bei Windows und seinen FS ist, weiß ich nicht – kann sein, dass man dort Hardlinks für Verzeichnisse haben kann. Unter Unixoiden und den dort typischen FS geht es jedenfalls nicht: user@host ~ ≫ mkdir A user@host ~ ≫ LANG=C ln A B ln: A: hard link not allowed for directory
Jack V. schrieb: > Ob S. schrieb: >> Bei NTFS ist es so, dass die sog. "Junctions" effektiv Hardlinks auf die >> Verzeichnis-Datei sind, solange sich die Sache in einem FS abspielt. > > Wie gesagt, wie es bei Windows und seinen FS ist, weiß ich nicht – kann > sein, dass man dort Hardlinks für Verzeichnisse haben kann. Unter > Unixoiden und den dort typischen FS geht es jedenfalls nicht: > > user@host ~ ≫ mkdir A > user@host ~ ≫ LANG=C ln A B > ln: A: hard link not allowed for directory Mit symbolischen Links (aka "Verknüpfungen" per Contaxtmenu des Explorers) geht es laufwerksübergreifend. Die Hardlinks-Funktion kannte ich bis jetzt noch nicht.
Was bei Verzeichnissen unter Unixoiden geht: ›mount -o bind /pfad/zum/Ausgangsverzeichnis /pfad/zu/dokumente/zielverzeichnis‹ – das verhält sich praktisch in etwa, wie Hardlinks für Verzeichnisse.
Jack V. schrieb: > Was bei Verzeichnissen unter Unixoiden geht: ›mount -o bind > /pfad/zum/Ausgangsverzeichnis /pfad/zu/dokumente/zielverzeichnis‹ – das > verhält sich praktisch in etwa, wie Hardlinks für Verzeichnisse. Jepp. Das ist in etwa vergleichbar. Natürlich nicht für JW und seine gläubigen Anhänger. Für die existieren Symlinks/Hardlinks/Junctions unter Windows ja erst garnicht. Hat den Vorteil: Da braucht man sich mit Vergleichen bezüglich der Funktionalität nicht weiter aufhalten und kann ohne weiteres Nachdenken gleich sagen: *x ist allemal besser als Windows. Also den unabänderlichen Grundsatz des Glaubens erneut bestätigen.
Pat A. schrieb: > Jörg W. schrieb: >> Die kennen das Konzept eines Hardlinks einfach gar nicht. > > Doch (zumindes bei NTFS): > "mklink /h <destination\Dateiname> <source\Dateiname>" OK, wie ist das dann, wenn man eine der Dateien löschen will? Werden dann alle gelöscht? Die unixoiden trennen ja Datei (inode) vom Verzeichniseintrag, NTFS macht das meines Wissens nicht.
Jack V. schrieb: > mount -o bind Das ist allerdings Linux-spezifisch. Bei den BSDs heißt das Pendant nullfs und ist keine Mount-Option, sondern ein eigenes Dateisystem (mount -t nullfs). Inwiefern es bei SysV-Derivaten (Solaris und Nachfolger) etwas Vergleichbares gibt, damit habe ich zu lange nichts mehr gemacht.
Jörg W. schrieb: > OK, wie ist das dann, wenn man eine der Dateien löschen will? Werden > dann alle gelöscht? Nein, natürlich nicht. Genausowenig wie unter *x übrigens. > Die unixoiden trennen ja Datei (inode) vom Verzeichniseintrag, NTFS > macht das meines Wissens nicht. Doch, machen sie, sonst wären Hardlinks ja überhaupt nicht möglich, wie jeder mit einer gewissen Minimal-Intelligenz ausgestatte unschwer herausfinden kann. Heißt da halt nur nicht "Inode". Wenn dich schon sowas verwirrt, musst du dringend dazu lernen. Da reicht halt der unverrückbare Glaube allein nicht mehr. Alternativ kann man natürlich weiterhin einfach alle missliebigen Fakten ignorieren. Dann reicht der Glaube bis zur Rente oder wahlweise auch bis zum Ableben und alles ist immer schön konsistent im Weltbild.
Ob S. schrieb: > Alternativ kann man natürlich weiterhin einfach alle missliebigen Fakten > ignorieren. Alternativ genügt es auch, wenn ich deine unfreundlichen Kommentare in Zukunft ignoriere und mich einfach mit denen weiter unterhalte, die ihr Wissen auf freundliche Art und Weise weitergeben. Die sind zum Glück deutlich in der Mehrzahl.
Ob S. schrieb: > Genausowenig wie unter *x übrigens. Naja … sowohl bei einem Symlink, als auch bei der Methode mit dem Bind-Mount, verschwinden alle Referenzen auf die Datei, wenn ich sie an einer Stelle lösche. Was macht Windows denn an da, wenn es dort anders ist – legt es für jede Datei, die man unter ein hart verlinktes Verzeichnis packt, einen eigenen Hardlink für diese Datei an? OT: Diese abfällige Arroganz steht dir gar nicht mal so gut zu Gesicht. Mach mit der Info, was du willst.
Jörg W. schrieb: > OK, wie ist das dann, wenn man eine der Dateien löschen will? Werden > dann alle gelöscht? Nein, das nicht. Aber es gibt eine andere Stolperfalle bei verlinkten Dateien und zwar dann, wenn ein Programm, mit dem man die Datei bearbeitet und wieder speichert, eine Backupdatei anlegt, indem es die geöffnete (verlinkte) Datei umbenennt (in "xyz.bak" z.B.) und die Änderung in eine neue Datei (mit altem Namen) speichert. Dadurch wird die (nicht geänderte) Backupdatei zur verlinkten Datei und die (gespeicherte) Änderung taucht auch nicht in der original Datei auf. Umgekehrt dann natürlich ebenso: Eine Änderung in der original Datei führt nur zu einer Änderung in der Backupdatei, welche nun die verlinkte Datei ist, und nicht in der Datei, die man eigentlich für die verlinkte Datei hält => ganz böse Falle!
Diese Falle haben aber Hardlinks unter Unixen genauso. Wenn ein Programm eine Datei umbenennt und dann neu anlegt, merken natürlich die hard gelinkten anderen Kopien nichts davon.
Jörg W. schrieb: > Alternativ genügt es auch, wenn ich deine unfreundlichen Kommentare in > Zukunft ignoriere Natürlich wirst du das tun, sofern sie Fakten enthalten, die mit deinem Weltbild nicht kompatibel sind. Und dein Weltbild hast du deutlichst hier manifestiert: Beitrag "Re: Ordner-Überschneidungen" Wenn du da sinngemäß geschrieben hättest: Ich weiß es nicht genau, aber meines Wissens nach... o.ä. wäre die Sache niemals derart eskaliert. Dann hätte man den Fakt völlig unaufgeregt richtig gestellt und alles wäre gut gewesen. Aber diese faktisch falsche Behauptung als Fakt zu verkaufen, das geht eben einfach garnicht.
Johannes K. schrieb: > Löst ihr das mit Verlinkungen oder habt ihr eine andere Lösung? Andere Überkategorien. "Dokumente" ist ja nur eine ganz allgemeine Überkategorie. Und so Beruf-und Ausbildungssachen kann man in einem Unterorder in den Dokumenten z.B. mit "Beruf und Ausbildung" (mit zugehörigen Unterordnern) erstellen. Und eine Inhaltsaddressierung könnte man auch mit einer kleinen Html-Seite erstellen. Die entsprechenden Links dann halt mit dem üblichen Code.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.