Czy to istnieje: znormalizowany sposób dokumentowania struktury systemu plików

W pracy jestem odpowiedzialny za organizację wielu różnych danych w standardowym systemie plików. Część z nich ma sensowną klasyfikację (według podobieństwa, potrzeby, dostępu do odczytu / zapisu itp.), Ale większa część faktycznie to dokumentuje: jakie dokumenty / pliki / nośniki powinny iść gdzie, a czego nie powinno być w tym katalogu, „coś nieco innego, patrz ../../other-dir” itp.

W tej chwili udokumentowałem to za pomocą pliku tekstowego readmew każdym katalogu, który chcę dokumentować. Jeśli ktoś nie jest pewien, co ma być w jakimkolwiek katalogu, odczytuje ten plik.

Działa to w porządku, ale wydaje się dziwne, że mam to prymitywne niestandardowe rozwiązanie problemu, którego musi doświadczyć każdy opiekun nietrywialnej struktury katalogów. Na przykład każda firma, o której wiem, ma jakiś wspólny system plików, w którym ważna jest uzgodniona terminologia kategoryzacji. Z mojego doświadczenia wynika, że ​​ludzie po prostu muszą dowiedzieć się, co to jest, metodą prób i błędów i eksperymentów.

Pozwól więc, że zaproponuję lepsze rozwiązanie, i mam nadzieję, że możesz mi powiedzieć, czy istnieje. Dowolny katalog w dowolnym systemie plików może mieć nazwę ukrytego pliku w postaci zwykłego tekstu .readme. Jego treść to opisowy język ludzki. Wykorzystuje niektóre znaczniki, takie jak Markdown, z niewiele więcej niż pogrubionymi, kursywnymi i (względnymi) hiperłączami do innych katalogów. Teraz odpowiednio włączona przeglądarka plików będzie sprawdzać plik o nazwie .readmeza każdym razem, gdy wyświetla katalog. Jeśli istnieje, jego zawartość jest analizowana i wyświetlana w dyskretnym okienku w pobliżu widgetu ścieżki katalogu. Wszelkie linki w nim zawarte można kliknąć, a użytkownik zostanie przeniesiony do katalogu docelowego tego łącza.

Myślę, że wysiłek wdrożenia takiego standardu zwróciłby się wielokrotnie w postaci zwiększenia użyteczności. Mielibyśmy, powiedzmy, wtyczki dla Nautilusa, Konquerora itp. Można by go użyć do wyświetlania informacji o katalogu na standardowych listach plików obsługiwanych przez serwery WWW. I tak dalej.

Pytanie: czy coś takiego istnieje? Jeśli nie, dlaczego nie? Czy ludzie myślą, że warto?

O ile mi wiadomo, nie ma standardu. Oto kilka pomysłów z mojego doświadczenia.

Skonfiguruj, nigdy nie zmieniaj

To właśnie w przypadku niepowodzenia większości firm. Nie ma nic gorszego niż ciągle zmieniająca się struktura systemu plików. Jeśli nie jest możliwe utrzymanie go na stałym poziomie, czysty system plików jest po prostu niewłaściwym pojemnikiem do organizowania informacji. Użyj bazy danych lub systemu zarządzania treścią.

Używaj opisowych i spójnych nazw katalogów

Nikt nie ma czasu na odczytanie .filingpliku ani niczego innego. Jeśli nazwy katalogów nie tłumaczą się, prawdopodobnie i tak zgubisz się.

Napisz dokumentację dla swojej struktury katalogów

Napisz dokument, w którym wyjaśnisz rolę każdego katalogu. Podaj wiele przykładów. Udostępnij ją każdemu, kto musi pracować z twoją strukturą, ale nie wierz, że ktoś ją przeczyta. To powinno być dla ciebie bardziej jak Biblia . Nie jest łatwo znaleźć przykład takiego dokumentu, ponieważ oczywiście firmy go nie publikują. Przykładem oprogramowania open source jest Standard Systemu Hierarchii Plików .

Jeśli brzmi to trochę negatywnie, to tak. Nigdy nie widziałem nietrywialnego repozytorium opartego na systemie plików, w którym więcej niż pięciu użytkowników pracuje w dłuższej perspektywie w praktyce. Problem polega na tym, że niezależnie od kategorii, które skonfigurujesz, ludzie będą mieli zupełnie inne pomysły na ich temat. Aby w końcu odpowiedzieć na twoje pytania:

Czy coś takiego istnieje?

Nie, nie sądzę.

Jeśli nie, dlaczego nie?

Moim zdaniem: dla małej statycznej hierarchii z kilkoma użytkownikami jest to przesada. W przypadku dużej zmieniającej się hierarchii z wieloma użytkownikami nie będzie działać, ponieważ idea kategorii (= katalogi, folder) nie skaluje się.

Czy ludzie myślą, że warto?

Hm, to ciekawy pomysł. Aby zobaczyć, czy ludzie będą go używać, ktoś musi go zaimplementować. Zamiast .filingpliku możesz przechowywać te informacje w alternatywnym strumieniu danych (tak, foldery mogą mieć również ADS). Możesz użyć rozszerzonych atrybutów w systemie Linux i OSX. Największym problemem byłoby prawdopodobnie załatanie przeglądarek plików.

wasabi jest warte strzału. W katalogu głównym projektu źródło w postaci zwykłego tekstu posłuży jako solidny przegląd projektu i możesz rzucić ten sam dokument w przeglądarce, aby uzyskać bardziej wyszukane wyniki.

To prawda, że ​​nie jest to rozwiązanie oparte na systemie plików, ale dopóki wszystkie systemy plików nie obsługują czegoś wspólnego, wasabi (lub twoja własna implementacja) może być najlepszą opcją.

Twój pomysł ma pewne zalety, ale obawiam się, że kiedy potrzebujesz czegoś takiego, to naprawdę oznacza, że ​​potrzebujesz czegoś bardziej uporządkowanego. To jest CMS, może tylko lekki, ale zdecydowanie coś więcej niż tylko plik tekstowy.

Zwłaszcza jeśli chcesz ograniczyć pisanie (lub nawet uzyskiwanie dostępu) do określonych dokumentów (a tym samym zawierających je folderów) do niektórych podzbiorów bazy użytkowników.

Nie określasz swojego systemu operacyjnego, ale istnieją doskonałe (i bezpłatne) produkty, takie jak alfresco, które mogą ci służyć lepiej niż bieżąca konfiguracja.

Oto pomysł. Napisz skrypt, który zadaje użytkownikowi różne pytania dotyczące pliku i / lub dokonuje dopasowania w samej treści pliku, a następnie zaleca lokalizację do umieszczenia pliku lub umieszcza go tam. Skrypt może być tak prosty lub tak złożony, jak chcesz.

Skrypt działa jako system zarządzania plikami, system wspomagania decyzji i żywa dokumentacja hierarchii systemu plików. Linux Hierarchy Standard systemu plików jest trochę mitem, jeśli się nad tym zastanowić, ponieważ istnieje bardzo duża różnica między dystrybucjami. Jednak większość użytkowników systemu Linux / Unix nie musi się samodzielnie uczyć o hierarchii systemu plików, ponieważ istnieje różne oprogramowanie zainstalowane w systemie, które zarządza hierarchią w znormalizowany sposób (menedżer pakietów, narzędzie konfiguracyjne itp.). Różne ramy aplikacji tworzą również skrypty do zarządzania katalogami, np. Django ma komendy zarządzania do tworzenia nowego projektu lub nowego modułu aplikacji lub plików migracji squash itp.

Ma to tę dodatkową zaletę, że skrypt może tworzyć różne dowiązania symboliczne, jeśli plik musi być przeszukiwany na więcej niż jeden sposób, na przykład indeks oparty na autorze pliku lub dacie utworzenia lub dowolnej posiadanej regule biznesowej. Możesz symulować oznaczanie za pomocą dowiązań symbolicznych. Tag jest prostym dowiązaniem symbolicznym z tagskatalogu, więc tags/mytag/myfilemoże być dowiązaniem symbolicznym do actual/myfile.

Dodatkowo możliwa będzie również zmiana struktury hierarchii systemu plików bez zmiany interfejsu użytkownika.

System plików to baza danych. Nie relacyjna baza danych, ale hierarchiczna baza danych. Pomyśl o tym jak o zarządzaniu bazą danych, tak naprawdę nie chcesz, aby ludzie musieli nauczyć się struktury relacyjnej, ale raczej chcesz, aby aplikacja przedstawiała użytkownikowi różne zadania, które muszą wykonać (np. Czy wykonujesz miesięcznie Raport XYZ, świetnie, a następnie umieść go w tym folderze i utwórz to dowiązanie symboliczne, a następnie będziesz musiał zmodyfikować inny plik, aby zapisać, że zrobiłeś raport za ten miesiąc itp.).