Jak poprawnie obsłużyć różną kolejność plików w systemach plików.

Mam aplikacje która obsługuje różne systemy plików, ext2, ext3, NTFS, fat.

Główne ogarnianie ich sprowadza się do separatorów ścieżek i litery dysku na Windowsie.

Natomiast różne systemy plików inaczej ogarniają kolejność plików, zwłaszcza plików i folderów. Nie ma to specjalnego wpływu na działanie aplikacji, poza jednym.

Kiedy listuje katalogi i pliki, to printuje też logi. A więc treść tych logów, jakby nie patrzeć zależy od kolejności w jakiej przeiteruje po plikach, co w gruncie rzeczy sprawi że ten sam program uruchomiony na tym samym zestawie plików wyprintuje inne logi.

Mógłbym to ogarnąć, po prostu sortując pliki, ale to jest trudne bo sortowanie po nazwie nie bierze pod uwagę hierarchii folderów., dodaje też niepotrzebny overhead performance'owy, którego nie chcę w aplikacji.

Chciałbym napisać test pod wyprintowany output, ale asercje failują na różnych systemach plików przez kolejność właśnie. Mógłbym je prasować, i porównać bez sprawdzenia kolejności, ale to z kolei sprawia że testy są bardziej przywiązane do widoku, bo muszą go prasować. Mógłbym też je testować niżej, zanim się wyprintują.

Jakie mam opcje według was, co do ogarnięcia różnic w kolejności plików w systemie plików? Może skorzystać z wirtualnych systemów plików in-memory na potrzeby testów - ale nadal jest problem ze po uruchomieniu nadal aplikacja ma różnicę.

Proszę się wstrzymać od odpowiedzi "olej kolejność plików" bardzo proszę.

Riddle napisał(a):

, ale to jest trudne bo sortowanie po nazwie nie bierze pod uwagę hierarchii folderów.

Jak to ma dokładnie działać? Czy nie możesz zrobić takiego porównania "/usr/bin/a.txt" < "/usr/bin/b/c.txt" => ("usr", "bin", "a.txt") < ("usr", "bin", "b", "c.txt") (czyli coś jak https://en.cppreference.com/w/cpp/algorithm/lexicographical_compare)?

W sumie chyba, na dużo różnych sposobów może być zwracana zawartość katalogu, ja na jednym systemie sprawdzałem, to alfabetycznie foldery i potem alfabetycznie pliki.
Chyba jednego uniwersalnego standardu nie ma bo bez własnej implementacji sortowania, która wszędzie wykona tak samo.

Ja bym pewnie zrobił to jakoś tak, zwrócił zawartość katalogu, posortował alfabetycznie, nie ważne czy plik czy folder, pliki dodawał jako liście do tablicy, a foldery z następnymi tablicami wypełnionymi listą pod folderów i tak rekurencyjnie przechodził, aż zmapowałbym do postaci drzewa strukturę katalogów, a potem depth first search np. tworząc generator, po prostu przeszedł od początku do końca mapę.

Lub generatorem zwracać w trakcie tworzenia drzewa, co będzie bardziej pamięciowo oszczędne, bo po sortowaniu by się prostu zwracało plik jeśli to liść, lub wchodziło głębiej jeśli folder i powtarzało kolejną rekurencje.

slsy napisał(a):

Riddle napisał(a):

, ale to jest trudne bo sortowanie po nazwie nie bierze pod uwagę hierarchii folderów.

Jak to ma dokładnie działać? Czy nie możesz zrobić takiego porównania "/usr/bin/a.txt" < "/usr/bin/b/c.txt" => ("usr", "bin", "a.txt") < ("usr", "bin", "b", "c.txt") (czyli coś jak https://en.cppreference.com/w/cpp/algorithm/lexicographical_compare)?

A inny pomysł niż sortowanie tego?

Nadal trzeba to posortować, zamiast zwykłej iteracji.

Z głupich pomysłów to log może być wielkim jsonem, gdzie klucz to scieżka do pliku a wartość to log, Wtedy output jest semantycznie równoznaczny niezależnie od kolejności, bo kolejność kluczy w jsonie nie ma znaczenia

Wiec w tym wypadku problem jest redukowany poprzez użycie formatu, który w swoim RFC ma napisane, że kolejność nie ma znaczenia. Może jest jakiś inny format, który się lepiej nadaje

Tak czy owak na pewno użyłbym sortowania, bo szkoda cudować jak rozwiązanie jest proste i szybkie.

slsy napisał(a):

Z głupich pomysłów to log może być wielkim jsonem, gdzie klucz to scieżka do pliku a wartość to log, Wtedy output jest semantycznie równoznaczny niezależnie od kolejności, bo kolejność kluczy w jsonie nie ma znaczenia

Wiec w tym wypadku problem jest redukowany poprzez użycie formatu, który w swoim RFC ma napisane, że kolejność nie ma znaczenia. Może jest jakiś inny format, który się lepiej nadaje

Tak czy owak na pewno użyłbym sortowania, bo szkoda cudować jak rozwiązanie jest proste i szybkie.

Mi chodziło o rozwiązania na poziomie systemu plików, a nie aplikacji.

Bez obrazy, ale jeśli nigdy się nie zajmowałeś kolejnością plików to raczej nie wpadniesz na nic odkrywczego.

Tak, mógłbym posortować, i tak mógłbym wyprintować to inaczej, ale to są rzeczy które już wymieniłem i których nie chciałbym robić. Wolałbym znaleźć lepsze rozwiązanie.

Jeżeli "kolejność plików" jest przypadkowa, to musisz do nich podejść jak do kolejności zwracanych rekordów z bazy danych. Czyli jeżeli jawnie nie wskażesz kolejności, to wszystko co z siebie wypluje baza danych jest ok. Wg. mnie nic lepszego niż już wymyśliłeś, czyli samodzielne posortowanie całości nie wymyślisz.

piotrpo napisał(a):

Jeżeli "kolejność plików" jest przypadkowa, to musisz do nich podejść jak do kolejności zwracanych rekordów z bazy danych. Czyli jeżeli jawnie nie wskażesz kolejności, to wszystko co z siebie wypluje baza danych jest ok. Wg. mnie nic lepszego niż już wymyśliłeś, czyli samodzielne posortowanie całości nie wymyślisz.

Ale kolejność nie jest przypadkowa, zależy od systemu plików, a każdy z nich się rządzi innymi zasadami, np Windows zawsze listuje foldery pierwsze.

Mógłbym to ogarnąć, po prostu sortując pliki, ale to jest trudne bo sortowanie po nazwie nie bierze pod uwagę hierarchii folderów.

Czy ta kolejność jest dla ciebie ważna "biznesowo"? Bo jeżeli tego nigdzie nie pokazujesz użytkownikowi, a zależy ci jedynie na posiadaniu stałej kolejności, to przecież wystarczy posortowanie alfabetyczne. Jeżeli nie wystarczy, to sortowanie po kolejnych segmentach ścieżek też nie powinno być wyzwaniem. Problem zaczyna się dopiero jeżeli chcesz żeby było zawsze "tak jak w systemie", bo użytkownicy są przyzwyczajeni do tego jak działa ls, dir, czy co tam jest używane. Ale z tego co piszesz, to zależy ci jedynie na stabilnym teście, więc możesz sobie to posortować właśnie w teście w celu zapewnienia stabilności asercji.

To może wytłumacz na czym polega bezsensowność sortowania

Riddle napisał(a):

Mógłbym to ogarnąć, po prostu sortując pliki, ale to jest trudne bo sortowanie po nazwie nie bierze pod uwagę hierarchii folderów.

I na czym polega trudność w implementacji sortowania.

Dla potomnych:

O coś takiego mi chodziło: http://e2fsprogs.sourceforge.net/ext2intro.html

nalik napisał(a):

To może wytłumacz na czym polega bezsensowność sortowania

Riddle napisał(a):

Mógłbym to ogarnąć, po prostu sortując pliki, ale to jest trudne bo sortowanie po nazwie nie bierze pod uwagę hierarchii folderów.

I na czym polega trudność w implementacji sortowania.

No chociażby dlatego że duże foldery z dużą ilością plików dają duży narzut O(n log n).

Z resztą, nie chce mi się tłumaczyć czemu nie wybrałem tego rozwiązania.

Jak Ci się nie chce tłumaczyć, to oszczędź nam czasu i nie zadawaj pytań.
Co do tego linka, przeczytałeś to w ogóle? Co ma implementacja ext2 do Twojego listowania plików?

Taki ls sortuje wypisywane pliki przy każdym wywołaniu. A ty się boisz, że sortowanie spowolni Ci apkę albo testy?

Chciałbym napisać test pod wyprintowany output, ale asercje failują na różnych systemach plików przez kolejność właśnie. Mógłbym je prasować, i porównać bez sprawdzenia kolejności, ale to z kolei sprawia że testy są bardziej przywiązane do widoku, bo muszą go prasować. Mógłbym też je testować niżej, zanim się wyprintują.
No chociażby dlatego że duże foldery z dużą ilością plików dają duży narzut O(n log n).

ale po co testować czy printki działają na dużych folderach?

printki sobie potestuj na 10 plikach

a stress testy bez printek

Riddle napisał(a):

Mi chodziło o rozwiązania na poziomie systemu plików, a nie aplikacji.

Nie rozumiem, to co piszesz wygląda na sprzeczność.

Na poziomie systemu plików masz to, co masz: różne systemy plików inaczej sortują.

Pojęcia nie mam, czy da się wszystkie wymienione przez cb systemy plików jakoś tak skonfigurować, by ustawiały pliki w tej samej kolejności, ale nawet jeśli, to przyda się to chyba tylko do testów, bo straci ogólność i w rzeczywistości i tak będziesz miał różną kolejność. Więc użyteczność testów spadnie, bo będą dalej od rzeczywistości.

Z koleiustalenie kolejności na poziomie aplikacji nazywa się, o ile mi wiadomo, "sortowanie", podczas gdy ty twierdzisz, że sortować nie będziesz, ponieważ

Riddle napisał(a):

Z resztą, nie chce mi się tłumaczyć czemu nie wybrałem tego rozwiązania.

Tak więc wymogi, które podałeś, wydają mi się być sprzeczne.

Riddle napisał(a):

Proszę się wstrzymać od odpowiedzi "olej kolejność plików" bardzo proszę.

Wolno wiedzieć, dlaczego?

nalik napisał(a):

Jak Ci się nie chce tłumaczyć, to oszczędź nam czasu i nie zadawaj pytań.
Co do tego linka, przeczytałeś to w ogóle? Co ma implementacja ext2 do Twojego listowania plików?

Taki ls sortuje wypisywane pliki przy każdym wywołaniu. A ty się boisz, że sortowanie spowolni Ci apkę albo testy?

A myślisz, po co jest ls -U, jak nie pod performance?

YetAnohterone napisał(a):

Z koleiustalenie kolejności na poziomie aplikacji nazywa się, o ile mi wiadomo, "sortowanie", podczas gdy ty twierdzisz, że sortować nie będziesz, ponieważ

Szukam rozwiązania innego niż sortowanie, także jeśli nie masz nic takiego co możesz zaproponować, to bardzo proszę, wstrzymaj się od odpowiedzi i nie zaśmiecaj wątku.

Przygotowałem algorytm:

• Jeśli chcesz zaproponować sortowanie - don't

• Jeśli chcesz zaproponować olanie tematu - don't

• Jeśli chcesz mnie przekonać żebym zmienił podejście - don't

• Jeśli natomiast masz jakiś pomysł jak sensownie ogarnąć różnice pomiędzy systemami plików - zapraszam do udzielenia opinii, chętnie poczytam.

@Riddle: "Jeśli natomiast masz jakiś pomysł jak sensownie ogarnąć różnice pomiędzy systemami plików" - bardzo słabo postawiłeś problem. Jak definiujesz różnicę między systemami plików? Określ porządek plików. Fizyczny może być różny od logicznego, dodatkowo w przypadku fizycznej organizacji, możesz na różne sposoby przechodzić fizyczną strukturę.

Masz takie atrybuty jak nazwa, czas utworzenia, czas modyfikacji, locale (które będą wpływać na kolejność znaków), dodatkowo system pozwala olewać takie atrybuty jak access time (np. montowanie z noatime), czy wymagać odpowiednich uprawnień (jeśli chcesz grzebać w niskopoziomowych szczegółach). Rozumiem, że chcesz skończyć bez sortowania, ale z rozwiązaniem, które jest przyspawane do niskopoziomowych szczegółów implementacji systemu plików i utrzymywać w nieskończoność przy zmianie wersji kernela, systemy plików, bądź pojawienia się nowego rodzaju systemu plików? KISS.

Zakładam, że nie chcesz monitorować wszystkich zmian w systemie plików, tylko określone katalogi, które mają znaczenie dla aplikacji.

1. Bierzesz FileSystemWatcher (jak nie wiesz co to: man inotify, google FileSystemWatcher)
2. Wybierasz swoją ulubioną uporządkowaną strukturę danych, do której pakujesz "bieżący stan systemu plików"
3. Dane zebrane przez file system watchera wykorzystujesz do aktualizacji takiej struktury

Masz uporządkowane tak jak chcesz, bez sortowania i wchodzenia w implementacje poszczególnych systemów plików.

no to może zamiast sortowania zwykły contains :)

Masz źle napisane testy, nieporozumienie z tym oczekiwaniem że kolejność musi być identyczna, aby test był zaakceptowany. Do tego żadne sortowanie nie jest potrzebne, żeby sprawdzić warunek formalny równości nieuporządkowanych zbiorów.

W pełni się zgadzam z @baryel

Moim zdaniem problem Riddle jest zwalony u samych założeń.

Riddle napisał(a):

Kiedy listuje katalogi i pliki, to printuje też logi. A więc treść tych logów, jakby nie patrzeć zależy od kolejności w jakiej przeiteruje po plikach, co w gruncie rzeczy sprawi że ten sam program uruchomiony na tym samym zestawie plików wyprintuje inne logi.

Wygląda, że w pełni prawidłowe zachowanie: kolejność zależy od systemu plików, a więc i logi także. Program nie jest uruchomiony w próżni, tylko w jakimś kontekście.

Riddle napisał(a):

Chciałbym napisać test pod wyprintowany output, ale asercje failują na różnych systemach plików przez kolejność właśnie.

Tak jak napisał baryel wyżej

Riddle napisał(a):

Tak, mógłbym posortować, i tak mógłbym wyprintować to inaczej, ale to są rzeczy które już wymieniłem i których nie chciałbym robić. Wolałbym znaleźć lepsze rozwiązanie.

A więc jak pisałem wyżej wymogi są sprzeczne, bo ustalenie kolejności nazywa się "sortowanie", a zatem nie można jednoczesnie chcieć ustalić kolejności i nie chcieć sortować.

Cała sprawa wygląda mocno na problem XY, ale trudno cokolwiek więcej powiedzieć, skoro Riddle uporczywie i arogancko odmawia podania szczegółów.

Mój strzał w ciemno: Riddle ma jakieś dziwne, zakrawające na nerwicę natręctw pojęcie na temat czystości kodu i kurczowo trzyma się sztucznych, narzuconych samemu sobie wymogów, które jemu wydają się być eleganckie, ale stanowią bohaterską próbę rozwiązania problemu, który nie istnieje. Riddle nie zauważył nawet, że jego wymogi są sprzeczne.

Niestety Riddle wydaje się być zbyt zarozumiały, by uznać taką możliwość, że może się mylić u samych założeń. Albo uznajemy wspaniałość jego podejścia i podajemy rozwiązanie (które IMO ze względu na sprzeczność nie istnieje) według jego pomysłów, albo my maluczcy musimy z pokorą pochylić głowy i zamilknąć, gdyż nie jesteśmy dość kompetentni, by zrozumieć ten jakże głęboki i zaawansowany problem.

baryel napisał(a):

Masz źle napisane testy, nieporozumienie z tym oczekiwaniem że kolejność musi być identyczna, aby test był zaakceptowany. Do tego żadne sortowanie nie jest potrzebne, żeby sprawdzić warunek formalny równości nieuporządkowanych zbiorów.

Nie chcę tak przywiązać testów do formatu danych, ale dzięki z sugestie.

@YetAnohterone: Po prostu wszystkie rozwiązania zaprezentowane w tym wątku, są takie że lepiej mi zostawić program tak jak jest teraz, niż je dodać.

Nie wiem co w tym dziwnego.

Riddle napisał(a):

baryel napisał(a):

Masz źle napisane testy, nieporozumienie z tym oczekiwaniem że kolejność musi być identyczna, aby test był zaakceptowany. Do tego żadne sortowanie nie jest potrzebne, żeby sprawdzić warunek formalny równości nieuporządkowanych zbiorów.

Nie chcę tak przywiązać testów do formatu danych, ale dzięki z sugestie.

Już to zrobiłeś. Chcesz testować output, który ma z góry określony format. To samo w sobie jest przywiązaniem testu do formatu logu.

nalik napisał(a):

Riddle napisał(a):

baryel napisał(a):

Masz źle napisane testy, nieporozumienie z tym oczekiwaniem że kolejność musi być identyczna, aby test był zaakceptowany. Do tego żadne sortowanie nie jest potrzebne, żeby sprawdzić warunek formalny równości nieuporządkowanych zbiorów.

Nie chcę tak przywiązać testów do formatu danych, ale dzięki z sugestie.

Już to zrobiłeś. Chcesz testować output, który ma z góry określony format. To samo w sobie jest przywiązaniem testu do formatu logu.

No właśnie nie chcę tego robić.

Moment, najpierw piszesz, że chcesz napisać asercję pod wyprintowany output (patrz pierwszy post). A teraz piszesz, że nie chcesz. Hmm

nalik napisał(a):

Moment, najpierw piszesz, że chcesz napisać asercję pod wyprintowany output (patrz pierwszy post). A teraz piszesz, że nie chcesz. Hmm

Tak, ale nie pod format tego outputu.

Mi się na prawdę nie chce walczyć z wiatrakami, i tłumaczyć Ci czemu sortowanie outputu tylko po to żeby napisać test jest bez sensu. To nie jest wymaganie biznesowe, i dodanie tego jest tylko overheadem performance'owym. Jeśli chcę mieć dobry test to albo muszę go przetestować inaczej, albo zostawić tak jak jest teraz. Sortowanie jest out of the question.

Skup się pytaniu: "Jak poprawnie obsłużyć różną kolejność plików w systemach plików." to jest miejsce w którym chce to ogarnąć. Jesli nie znasz się na systemach plików, nie wiesz czym się różni chociazby ext2 od ext3, to bez obrazy, ale raczej mi nie pomożesz.

A kto Ci każe sortować w logice? Możesz posortować w teście. Możesz też zrobić zwykłe n*n porównanie w teście i też zadziała.

I proszę Cię bardzo, zejdź ze swojego mentorskiego tonu. Bo nie masz ku temu żadnych podstaw.

Co do systemów plików, wyobraź sobie, że nawet pracowałem z userspacową implemntajcą ext3. Ale co ty tam wiesz.

nalik napisał(a):

A kto Ci każe sortować w logice? Możesz posortować w teście. Możesz też zrobić zwykłe n*n porównanie w teście i też zadziała.

I proszę Cię bardzo, zejdź ze swojego mentorskiego tonu. Bo nie masz ku temu żadnych podstaw.

A skąd wezmę tą listę plików bez parsowania outputu, czyli przywiązania testów do formatu outputu?

Prosiłem już kilka razy.

Rozumiem, żę według Ciebie parsowanie outputu albo sortowanie to spoko wyjścia. Dziekuje za przekazanie swojej opinii w taki dobitny sposób. Ja nie skorzystam z tego rozwiązania, i szukam innych, dziękuję.

Możw zacznij od zde

Riddle napisał(a):

nalik napisał(a):

A kto Ci każe sortować w logice? Możesz posortować w teście. Możesz też zrobić zwykłe n*n porównanie w teście i też zadziała.

I proszę Cię bardzo, zejdź ze swojego mentorskiego tonu. Bo nie masz ku temu żadnych podstaw.

A skąd wezmę tą listę plików bez parsowania outputu, czyli przywiązania testów do formatu outputu?

Prosiłem już kilka razy.

Rozumiem, żę według Ciebie parsowanie outputu albo sortowanie to spoko wyjścia. Dziekuje za przekazanie swojej opinii w taki dobitny sposób. Ja nie skorzystam z tego rozwiązania, i szukam innych, dziękuję.

Jakbym wiedział, co chcesz przetestować, to bym może i coś zaproponował konkretniejszego. Ale Twoje przedstawienie problemu jest tak mętne, że nawet nie wiadamo co chcesz osiągnąć. Nawet nie wiadomo co te logi zawierają.

A skąd wezmę tą listę plików bez parsowania outputu, czyli przywiązania testów do formatu outputu?

No nie wiem, może wczytasz w teście ten katalog, tak dynamicznie? I porównasz oczekiwanie wygenerowane z listy plików z wynikiem zwróconym prez testowaną jednostkę? Tak tylko głośno myślę.

nalik napisał(a):

No nie wiem, może wczytasz w teście ten katalog, tak dynamicznie? I porównasz oczekiwanie wygenerowane z listy plików z wynikiem zwróconym prez testowaną jednostkę? Tak tylko głośno myślę.

Not gonna work, nie ma zapewnienia że test wczyta pliki w takiej samej kolejności jak testowany program.

nalik napisał(a):

Jakbym wiedział, co chcesz przetestować, to bym może i coś zaproponował konkretniejszego. Ale Twoje przedstawienie problemu jest tak mętne, że nawet nie wiadamo co chcesz osiągnąć. Nawet nie wiadomo co te logi zawierają.

Napisałem Ci dokładnie co chcę zrobić: "obsłużyć różnice w kolejności plików w systemach plików".

Dziękuję, za zaproponowanie "posortować", ale nie chcę tego robić. Dziękuję za zaproponowanie "sparsuje sobie output", ale też tego nie chcę robić.

Ty chcesz zmusić filesystem i biblioteki, które używasz do listowania plików, by Ci zapodały pliki w odpowiedniej kolejności, zamiast napisać test tak by był niezależny od kolejności plików.