Jeśli tylko struktura ReFS będzie znana czyli będzie możliwe montowanie pliku/partycji pod innymi systemami w trybie R/W (wiem, wiem, marzenia), to jestem jak najbardziej na tak.
Może niech najpierw zaczną od zmiany w jądrze - MAXPATH z 256znaków na większą bo to archaiczne ograniczenie jest na codzień uciążliwe.
A gdzie tam, zrobią system plików oparty o słowa kluczowe (bazodanowy) i poproszą grzecznie, by wszystko trzymać w jednym katalogu .
Pół biedy jeśli grzecznie poproszą
W zasadzie to system bazodanowy można stworzyć w ramach nakładki bez jakiejkolwiek modyfikacji ntfs, nie ma problemu z synchronizowaniem nawet jesli to by było w przestrzeni programu - w winapi są na to proste sposoby żeby na bierząco śledzić zmiany w obu tych warstwach. Poza tym - system z indeksowaniem słów kluczowych czy zawartości nie musi być jednokatalogowy - Windows Search jakoś działa, kwestia działania explorera i okienek dialogowych typu save, open itd.
Raczej nie, bo od kiedy Hans Reiser siedzi za morderstwo żony, status systemu Reiser 4 jest niepewny.
To siedząc w pierdlu ma chyba sporo czasu na dopracowanie swojego systemu plików. Tym bardziej, że teraz żona już mu nie truje d...
Ta sprawa jest już dawno rozwiązana, firma się rozpadła, Reiser dostał dożywocie, a projekt przeniesiono na kernel.org i teraz ekipa z dawnej firmy Reiser'a rozwija go w wolnym czasie. Tak więc projekt nie upadł, ale zwolnił i dalej nie wygląda na to aby miał trafić w niedalekiej przyszłości do stabilnej gałęzi jądra linuksa.
http://msdn.microsoft.com/en-us/library/wi...1(v=vs.85).aspx
Prosty przykład na wykorzystanie FindFirstChangeNotification to Dropbox
Po zmianie nazwy podkatalogu w Dropboxie pliki w nim zawarte nie tracą synchronizacji i zaindeksowania w chmurowej bazie. To by umożliwiło - wbudowanie systemu obsługi wersji plików(podobnie jak w dropboxie), automatycznie wyeliminowało duplikaty etc.
Mogliby w M$ usunąć to idiotyczne ograniczenie długości ścieżki do 260 znaków!
#define MAX_PATH 260
Tak, wiem że jest jakiś dziwny przedrostek \\?\ który pozwala to ograniczenie ominąć, ale przeważająca większość oprogramowania nie radzi sobie z długimi ścieżkami.
A wystarczyłoby zmienić w windows.h na
#define MAX_PATH 32767
i przekompilować system oraz oprogramowanie. Wydanie nowej wersji Windows, w tym na ARMy, jest najlepszą okazją.
Windows ma wiele takich ograniczeń, np. WinAPI w ogóle sobie nie radzi z głębią kolorów większą niż 24 bity, jedyny sposób żeby je obsłużyć to... zdefiniować obraz jako teksturę w OpenGL!
Inna koszmarna sprawa to chaos związany z Unicode i starą 8-bitową tablicą znaków (Multibyte) i związaną z tym koniecznością stosowania we wszystkich stringach makra _T. Należałoby w ogóle wywalić obsługę Multibyte z kompilatora!
Dotkliwy też jest brak odśmiecania pamięci i licznika referencji w WinAPI prowadzący do bardzo trudnych do znalezienia wycieków zasobów GUI, w przeciwieństwie do nowszych GUI (np. Cocoa w Apple IOS)
Andree - obawiam się że to nie jest takie proste gdyby tak było to pewnie by to zrobili.
Windows ma wiele takich ograniczeń, np. WinAPI w ogóle sobie nie radzi z głębią kolorów większą niż 24 bity, jedyny sposób żeby je obsłużyć to... zdefiniować obraz jako teksturę w OpenGL!
Tej pretensji kompletnie nie rozumiem - niby jak w oparciu o stare WinApi to zrobić?
Są takie a nie inne struktury, takie a nie inne parametry w funkcjach winapi, nie da się tego tak poprostu zmienić.
Andree - obawiam się że to nie jest takie proste gdyby tak było to pewnie by to zrobili.
Po prostu trzeba by zrezygnować z wstecznej kompatybilności programów napisanych dla Windows 8, który starsze programy powinien wykonywać w trybie kompatybilności.
nie wiadomo dokładnie, ale chyba nie powiesz ze systemy plików typu fat,fat32,ntfs nie przynosiły żadnych zmian
nie wiadomo dokładnie, ale chyba nie powiesz ze systemy plików typu fat,fat32,ntfs nie przynosiły żadnych zmian
No właśnie ciekaw jestem co wymyślili
Raczej nie, bo od kiedy Hans Reiser siedzi za morderstwo żony, status systemu Reiser 4 jest niepewny.
A gdzie tam, zrobią system plików oparty o słowa kluczowe (bazodanowy) i poproszą grzecznie, by wszystko trzymać w jednym katalogu
A gdzie tam, zrobią system plików oparty o słowa kluczowe (bazodanowy) i poproszą grzecznie, by wszystko trzymać w jednym katalogu
Pół biedy jeśli grzecznie poproszą
W zasadzie to system bazodanowy można stworzyć w ramach nakładki bez jakiejkolwiek modyfikacji ntfs, nie ma problemu z synchronizowaniem nawet jesli to by było w przestrzeni programu - w winapi są na to proste sposoby żeby na bierząco śledzić zmiany w obu tych warstwach. Poza tym - system z indeksowaniem słów kluczowych czy zawartości nie musi być jednokatalogowy - Windows Search jakoś działa, kwestia działania explorera i okienek dialogowych typu save, open itd.
Raczej nie, bo od kiedy Hans Reiser siedzi za morderstwo żony, status systemu Reiser 4 jest niepewny.
To siedząc w pierdlu ma chyba sporo czasu na dopracowanie swojego systemu plików. Tym bardziej, że teraz żona już mu nie truje d...
Raczej nie, bo od kiedy Hans Reiser siedzi za morderstwo żony, status systemu Reiser 4 jest niepewny.
To siedząc w pierdlu ma chyba sporo czasu na dopracowanie swojego systemu plików. Tym bardziej, że teraz żona już mu nie truje d...
Generalnie to on ma święty spokój. Nawet już nie prauje nad systemami plików bo sprzedał swoją firmę i prawa do FS'ów by pokryć koszty procesu.
Raczej nie, bo od kiedy Hans Reiser siedzi za morderstwo żony, status systemu Reiser 4 jest niepewny.
To siedząc w pierdlu ma chyba sporo czasu na dopracowanie swojego systemu plików. Tym bardziej, że teraz żona już mu nie truje d...
Ta sprawa jest już dawno rozwiązana, firma się rozpadła, Reiser dostał dożywocie, a projekt przeniesiono na kernel.org i teraz ekipa z dawnej firmy Reiser'a rozwija go w wolnym czasie. Tak więc projekt nie upadł, ale zwolnił i dalej nie wygląda na to aby miał trafić w niedalekiej przyszłości do stabilnej gałęzi jądra linuksa.
Prosty przykład na wykorzystanie FindFirstChangeNotification to Dropbox
Po zmianie nazwy podkatalogu w Dropboxie pliki w nim zawarte nie tracą synchronizacji i zaindeksowania w chmurowej bazie. To by umożliwiło - wbudowanie systemu obsługi wersji plików(podobnie jak w dropboxie), automatycznie wyeliminowało duplikaty etc.
#define MAX_PATH 260
Tak, wiem że jest jakiś dziwny przedrostek \\?\ który pozwala to ograniczenie ominąć, ale przeważająca większość oprogramowania nie radzi sobie z długimi ścieżkami.
A wystarczyłoby zmienić w windows.h na
#define MAX_PATH 32767
i przekompilować system oraz oprogramowanie. Wydanie nowej wersji Windows, w tym na ARMy, jest najlepszą okazją.
Windows ma wiele takich ograniczeń, np. WinAPI w ogóle sobie nie radzi z głębią kolorów większą niż 24 bity, jedyny sposób żeby je obsłużyć to... zdefiniować obraz jako teksturę w OpenGL!
Inna koszmarna sprawa to chaos związany z Unicode i starą 8-bitową tablicą znaków (Multibyte) i związaną z tym koniecznością stosowania we wszystkich stringach makra _T. Należałoby w ogóle wywalić obsługę Multibyte z kompilatora!
Dotkliwy też jest brak odśmiecania pamięci i licznika referencji w WinAPI prowadzący do bardzo trudnych do znalezienia wycieków zasobów GUI, w przeciwieństwie do nowszych GUI (np. Cocoa w Apple IOS)
Tej pretensji kompletnie nie rozumiem - niby jak w oparciu o stare WinApi to zrobić?
Są takie a nie inne struktury, takie a nie inne parametry w funkcjach winapi, nie da się tego tak poprostu zmienić.
Po prostu trzeba by zrezygnować z wstecznej kompatybilności programów napisanych dla Windows 8, który starsze programy powinien wykonywać w trybie kompatybilności.