Chcę opowiedzieć to tak, jak faktycznie się wydarzyło, bo jeśli czytasz stronę zatytułowaną „Synchronizacja OneDrive jest wolna przy dużej bibliotece", prawdopodobnie stoisz dokładnie tam, gdzie my staliśmy jakiś czas temu — wpatrując się w wirującą ikonę w zasobniku, ze złym kolegą za plecami i dymkiem „przetwarzanie zmian", który wisi od wczoraj.
Nie zamierzaliśmy budować oprogramowania. Zamierzaliśmy przenieść firmę ze starzejącego się serwera plików. To, czego nauczyliśmy się po drodze, jest całym powodem istnienia OneMount.
Dlaczego w ogóle przenieśliśmy się do chmury
Stary \\serwer\udział był szybki i każdy go rozumiał — ale był też jedną skrzynką w
jednym budynku. Brak historii wersji wartej tej nazwy. Kopie zapasowe, o które ktoś musiał pamiętać.
Nic dla ludzi pracujących z domu. Kiedy plik został nadpisany, po prostu znikał.
SharePoint Online i OneDrive dla Firm naprawiały to wszystko na papierze: prawdziwa historia wersji, bezpieczeństwo i kontrola dostępu klasy Microsoft, dostępność z dowolnego miejsca i żywe współautorstwo w Office. Wierzyliśmy w tę zmianę. Nadal wierzymy — kierunek był właściwy. To transport walczył z nami na każdym kroku.
Potem biblioteka przekroczyła terabajt
Nasza główna biblioteka działu miała około terabajta rozłożonego na ogromną liczbę plików — lata dokumentów, eksportów, skanów, folderów projektowych. Plan był prosty: skierować klienta synchronizacji OneDrive na nią i pozwolić ludziom pracować w Eksploratorze jak zawsze.
Nie poszło prosto. Nowe komputery potrzebowały większości dnia na pierwszą synchronizację. Na słabszych łączach wstępna synchronizacja docierała prawie do końca, przerywała się i zaczynała od zera. A ikona w zasobniku spędzała dni mówiąc „przetwarzanie zmian" — stan, który przy dużych bibliotekach rzeczywiście potrafi trwać dniami, a nie minutami.
Ta liczba zmieniła nasze spojrzenie na wszystko. Nie używaliśmy narzędzia niewłaściwie. Po prostu poprosiliśmy klienta synchronizacji kopiującego pliki, aby lustrzanie odwzorował bibliotekę, do trzymania której nigdy nie został zaprojektowany. Każdy zsynchronizowany plik wymaga od klienta śledzenia swojego skrótu, znaczników czasu, stanu synchronizacji i konfliktu — i to właśnie ta księgowość zawodzi na dużą skalę.
Skonfliktowane kopie
Potem przyszedł plik, o którym wciąż opowiadamy historie. Dwie osoby otworzyły to, co wyglądało jak ten
sam arkusz kalkulacyjny. Klient synchronizacji, opóźniony, nie skończył jeszcze sprowadzać wersji
jednej z osób. Obie edytowały. Obie zapisały. A chmura zyskała drugi plik:
Budżet (skonfliktowana kopia użytkownika Ktoś 2026-03-14).xlsx.
Przeczytaj to jeszcze raz, powoli. Przenieśliśmy się do SharePoint właśnie po czystą historię wersji — jeden plik, łańcuch kto-zmienił-co-i-kiedy, powrót do dowolnego punktu. A klient synchronizacji, w drodze do chmury, niszczył dokładnie to: rozwidlał plik, duplikował dane i zostawiał ludziom scalanie dwóch arkuszy na oko. Skonfliktowane kopie to udokumentowane, codzienne zachowanie przy edycjach offline i opóźnionych, a przy naszej skali opóźnienie było stałe.
Ludzie chcieli z powrotem swój dysk sieciowy
W tym momencie nastroje się odwróciły. Wszyscy byli zadowoleni na starym dysku sieciowym i mieli
rację co do jednej rzeczy: X:\ był natychmiastowy, nigdy nie „przetwarzał zmian",
a każdy program na komputerze go rozumiał. Nikt nigdy nie zgłosił zgłoszenia mówiącego „litera dysku
utknęła na imporcie".
Ale powrót oznaczał rezygnację z tego, po co się przenieśliśmy — historii wersji, bezpieczeństwa, zdalnego dostępu, współautorstwa. Stanowczo odmówiliśmy tej wymiany. Szczery wniosek był niewygodny i, patrząc wstecz, oczywisty:
Nie chcieliśmy chmury ani dysku sieciowego. Chcieliśmy mózgu chmury i rąk dysku sieciowego — historii wersji i bezpieczeństwa SharePoint, osiągalnych przez zwykłą literę dysku, która nie kopiuje niczego na dysk.
Dlaczego „po prostu użyj przeglądarki" nie zadziałało
„To po prostu otwieraj pliki w przeglądarce" to standardowa odpowiedź, i dla części firmy jest w porządku. Dla reszty to nie wchodzi w grę — ponieważ ogromna część prawdziwego oprogramowania biznesowego potrafi otworzyć wyłącznie ścieżkę, nie adres internetowy.
- Systemy księgowe i ERP (te, które żyją na zmapowanym dysku i oczekują na nim pliku bazy danych).
- Backendy Access, współdzielone bazy danych i raporty budowane na nich.
- Pliki inżynierskie i CAD z linkami do innych plików po ścieżce.
- Zadania kopii zapasowych, skrypty wsadowe, zaplanowane eksporty i to jedno makro z 2014 roku, którego nikt nie odważy się przepisać.
Żadne z nich nie potrafi otworzyć https://…sharepoint.com/…. Otwierają
X:\Projekty\…. Zabierz literę dysku, a połowa firmy po prostu przestaje działać — bez
względu na to, jak nowoczesna jest chmura za tym stojąca.
Ludzie chcieli udostępniać jednym kliknięciem
Była jeszcze jedna prośba, która napływała od każdej organizacji: „dajcie nam przycisk do szybkiego udostępnienia pliku, prosto z Outlooka". Ludzie wysyłają kolegom i klientom linki do dokumentów przez cały dzień — i za każdym razem musieli otworzyć przeglądarkę, znaleźć plik w SharePoint i skopiować właściwy link. Małe tarcie, pomnożone przez setki razy dziennie.
A „właściwy link" to nie jeden link. Kolega wewnątrz firmy chce ścieżkę na podłączonym dysku (otwiera dokładnie ten sam plik). Osoba z zewnątrz potrzebuje linku WWW do SharePoint, który przetrwa logowanie i otwiera się w przeglądarce. Wybieranie ręcznie za każdym razem to kolejne źródło błędów i straconych minut.
Wypróbowaliśmy dedykowane narzędzia
Zanim napisaliśmy linijkę własnego kodu, zrobiliśmy to, co odpowiedzialne, i wypróbowaliśmy istniejące narzędzia, które obiecują „SharePoint i OneDrive jako dysk". Nie wymienię ich nazw — to nie jest o pokonaniu konkurenta, to o wzorcu, na który wciąż się natykaliśmy, i to ten wzorzec w końcu popchnął nas do zbudowania własnego.
Najpierw prosiły o rejestrację aplikacji
Zanim pojawił się choć jeden dysk, chciały rejestracji aplikacji Azure w tenancie — zgody administratora, projektu do utworzenia, przeglądu bezpieczeństwa do przejścia. Dla litery dysku. Na każdym tenancie, jaki mógł mieć nasz klient. Samo to czyniło je niemożliwymi do przekazania małej firmie bez dedykowanego działu IT.
Edycja zespołowa tak naprawdę nie działała
To był ten, który zabolał najbardziej. Cały powód, dla którego przetrwaliśmy migrację, to możliwość przebywania kilku osób w jednym skoroszycie naraz. Z tymi narzędziami to zniknęło. Albo plik był twardo zablokowany dla jednej osoby, podczas gdy wszyscy inni czekali, albo dwie osoby pracowały równolegle i dostawały — tak — znowu konflikty wersji. Jedyna najlepsza rzecz, jaką daje chmura, żywe współautorstwo, była po cichu wyłączana w momencie, gdy plik przechodził przez ich dysk.
Każdy zapis nadpisywał historię wersji
A potem najgłębszy problem, ten, którego nie zauważasz, dopóki nie zaczniesz szukać. Za każdym razem, gdy zapisywałeś, narzędzie wypychało do chmury zupełnie nową kopię całego pliku — świeże nadpisanie, nie edycję żywego dokumentu. Czysty łańcuch wersji — ten akapit zmieniony we wtorek, powrót do poniedziałku, zobacz, kto co zrobił — został zastąpiony stosem pełnych nadpisań pliku bez prawdziwego rodowodu. Narzędzie było technicznie „w SharePoint", po cichu demontując powód, dla którego ktokolwiek wybiera SharePoint.
Dysk, który psuje współautorstwo i spłaszcza historię wersji, to nie przechowywanie w chmurze z literą dysku. To udział sieciowy przebrany za SharePoint.
Więc zbudowaliśmy OneMount
Wszystko, czego potrzebowaliśmy, było na tej liście porażek, zapisane jako zestaw wymagań. Więc zbudowaliśmy coś, co spełniało je wszystkie naraz:
- Prawdziwa litera dysku Windows. Każda starsza aplikacja — księgowość, Access,
CAD, kopie zapasowe, skrypty — widzi zwykły
X:\i jest zadowolona. Bez przeglądarki, bez przepisywania. - Bez synchronizacji, bez kopii. Terabajt zostaje w chmurze. Nic nie pobiera się na dysk, więc nie ma ściany 300 000 plików, nie ma całodniowej pierwszej synchronizacji, nie ma „przetwarzania zmian".
- Bez rejestracji aplikacji. Zwykłe logowanie Microsoft 365, to samo, którego ludzie używają do Outlooka. Nic do utworzenia w Azure, nic do zatwierdzenia przez administratora.
- Prawdziwe współautorstwo i pełna historia wersji — zachowane. Ponieważ plik na dysku jest dokumentem w chmurze, nie jego kopią, Word i Excel otwierają go jako żywy plik SharePoint. Kilka osób edytuje naraz, Autozapis działa, a łańcuch wersji pozostaje nienaruszony. Przetestowaliśmy to z jednym skoroszytem i dwiema osobami, obok siebie, na żywo.
- Udostępnianie jednym kliknięciem. Kliknij prawym przyciskiem plik lub folder na dysku, a menu OneMount w Eksploratorze plików skopiuje link WWW do SharePoint (dla osób z zewnątrz) lub ścieżkę na dysku (dla kolegów wewnątrz firmy), otworzy plik w SharePoint, pokaże jego historię wersji albo wyśle go do Outlooka. Dokładnie „przycisk udostępniania", o który wciąż prosiły organizacje.
Ten ostatni punkt to cała gra. Nie chcieliśmy sięgać do chmury poprzez kopiowanie z niej plików — to właśnie niszczyło historię wersji przez cały czas. Chcieliśmy, aby litera dysku była oknem na plik w chmurze, żeby wszystko, co SharePoint robi dobrze, nadal działało. To linia, na której zbudowany jest OneMount, i dlatego ścieżka z tej historii doprowadziła do produktu, a nie kolejnego obejścia.
Jeśli jesteś teraz w samym środku tego i chcesz po prostu, żeby litera dysku działała już dziś, praktyczny towarzysz tej historii jest tutaj: jak zmapować SharePoint jako dysk sieciowy w Windows — metody, realne ograniczenia i to, co naprawdę się sprawdza →
Chcesz odpowiedzi na to samo pytanie, ale w liczbach, nie w opowieści? Zmierzyliśmy klienta OneDrive na bibliotece SharePoint liczącej 997 392 elementy: OneDrive i 1 000 000 plików — test synchronizacji, szybkość i wydajność →
Źródła