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


11

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?


Ponieważ wspominasz o ulepszeniach systemu plików (lub przeglądarkach plików dla konkretnego systemu plików), szczególnie w przypadku kodu źródłowego, warto również wspomnieć o bardzo potrzebnej funkcji porządkowania plików . Większość systemów plików ma dwa główne typy uporządkowania: alfabetyczne i nieposortowane. Ale co z zamówieniem określonym przez użytkownika? Na przykład w przypadku kodu źródłowego, jeśli masz 7 plików (klas, modułów, komponentów) w folderze (moduł, pakiet, komponent nadrzędny), wówczas ich kolejność „logiczna” zwykle nie jest taka sama jak kolejność alfabetyczna. Ale raczej jest to kolejność ich „drzewa zależności”.
Sorin Postelnicu

Tak więc, jako standardowe dodatki do nowoczesnych systemów plików, te trzy funkcje powinny być domyślnie dostarczane: 1) opisy plików, 2) niestandardowe porządkowanie plików w folderze oraz 3) oznaczanie / etykietowanie plików. Nie trzeba używać CMS, aby korzystać z tych 3 „podstawowych” funkcji.
Sorin Postelnicu

Odpowiedzi:


5

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.


1
„Nie ma nic gorszego niż ciągle zmieniająca się struktura systemu plików”, z wyjątkiem tej, która zdecydowanie odmawia zmiany, nawet jeśli struktura nie ma już sensu.
jameshfisher

1
„Używaj opisowych i spójnych nazw katalogów” - absolutnie konieczne, tak. Niestety istnieje konflikt między opisem a zwięzłością - nikt nie chce wpisać ścieżki do pliku w katalogu / srv / all-hierarchical-data / available-only-by-office-and-admin / letters-but-not-public -notices / rok akademicki-2009 / ... i tak dalej.
jameshfisher

„Napisz dokumentację dotyczącą struktury katalogów” - również świetny pomysł. Zasadniczo to sugeruję; wystarczy, że dokumentacja będzie rozpowszechniana, a nie monolityczna.
jameshfisher

„idea kategorii (= katalogi, folder) nie skaluje się” - prawda, z wyjątkiem tego, że czasem musi. Powiedzmy, wielkie drzewa źródeł oprogramowania ( git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=tree ).
jameshfisher

„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.” Myślę, że to możliwe, ale zmniejsza przenośność i przejrzystość, które moim zdaniem są tak ważne. Co jeśli chcę umieścić wszystko w repozytorium git? Pliki w postaci zwykłego tekstu są używane do konfiguracji specyficznej dla katalogu (np. Htaccess), więc dlaczego też nie dokumentacja?
jameshfisher

2

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ą.


1

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.


Zajmowałem się różnymi CMSami, ale przekonałem się, że przenośność, prostota i przejrzystość to ogromne koszty, które trzeba zapłacić w porównaniu z najbardziej czcigodnym CMS: drzewem katalogów. Większość danych, którymi musiałem zarządzać, mieściło się w hierarchii. W ostateczności istnieją dowiązania symboliczne. A struktura katalogów jest czasem jedynym rozwiązaniem: np. W rozwoju oprogramowania kod źródłowy jest u podstawy drzewem katalogów. (Dokumentowanie takich katalogów na ogół oznacza trzymanie się sztywnego i tajemniczego schematu, który ostatecznie się psuje. Myślę, że moje rozwiązanie też mogłoby tu pomóc.)
jameshfisher

Jak powiedziałem, twój pomysł ma sens, ale myślę, podobnie jak autor drugiego plakatu, że nie może on przekroczyć określonego poziomu. Wspominasz o kodzie źródłowym, ale jest to bardzo wyspecjalizowany przypadek - a kiedy dodajesz do niego kod, nie zaglądasz do istniejących katalogów, aby znaleźć, gdzie powinien on „pasować”. CMS zazwyczaj daje ci możliwość oznaczania rzeczy, dzięki czemu masz „katalogi” (foldery, spacje, strony), które działają jak twoje rozwiązanie, PLUS system znakowania, który pozwala ludziom znajdować rzeczy bez konieczności szukania „właściwego” katalogu. Jest to bardziej elastyczne niż dowiązania symboliczne i mniej podatne na błędy, IMHO.
p.marino

1

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.).

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.