Foldery RECYCLER użytkownika zawierają tysiące ukrytych plików

11

Mamy folder „Użytkownicy”, który jest katalogiem głównym wszystkich plików użytkownika i profili sieciowych.

Korzystając z narzędzia rozmiaru katalogu (WinDirStat), natknąłem się na dziwny i niepokojący problem - tysiące plików skutecznie ukrytych w interfejsie Kosza systemu Windows. Folder każdego użytkownika ma folder RECYCLER bezpośrednio pod My Documents, na przykład:

\\server1\Users\smithj\smithj's Documents\RECYCLER\S-1-5-21-nnnnnn

Bardzo niewielu naszych użytkowników ma komputery PC, ponieważ większość użytkowników loguje się do serwera aplikacji Citrix z prostego terminala Wyse. Ponieważ większość ich aktywności na plikach dotyczy udziałów sieciowych, użytkownicy (i my, administratorzy) zawsze rozumieli, że nie ma „Kosza sieciowego”.

Jednak ukryty folder RECYCLER dla większości użytkowników zawiera tysiące plików. Wyróżnia się kilka rzeczy:

  1. W większości przypadków żaden z plików nie jest widoczny przy użyciu interfejsu Kosza
  2. Konwencji nazewnictwa dla poszczególnych plików powinien zawierać literę dysku, takich jak DClub DD, lecz wszystkie one zacząć D@- na przykład [email protected].
  3. Uważam, że ten @symbol uniemożliwia systemowi Windows usunięcie dereferencji z oryginalnych plików, więc są one po prostu tłumione w interfejsie użytkownika.
  4. Pliki razem zużywają dziesiątki gigabajtów. Nie są duchami. Usunięcie niektórych plików zwiększa wolne miejsce na dysku.
  5. Wygląda na to, że faktycznie mamy „Kosz sieci”. Przez przypadek. Bez prawdziwych nazw plików.

Zdecydowaliśmy już, że usuniemy wszystkie pliki starsze niż Xdni. Mogę to zrobić za pomocą skryptu PowerShell. W przeciwieństwie do tego podobnego przypadku , będziemy usuwać pojedyncze pliki zamiast całego folderu.

Więc moje pytania:

  • Czy ktoś widział te @symbole w plikach Kosza?
  • Cały dostęp do dysku sieciowego odbywa się za pośrednictwem dysków mapowanych. Czy to może wyjaśnić, dlaczego pliki są poddawane recyklingowi? I ukryty?
  • Chociaż wykonujemy codzienne kopie zapasowe, chcę tylko dotknąć tego zasobu w celu odzyskania plików w ostateczności. Wszelkie sugestie lub ostrzeżenia?
jswanson
źródło
Nie jestem pewien, czy nadal jesteś w pobliżu, biorąc pod uwagę wiek tego pytania, ale czy przekierowujesz Moje dokumenty na ścieżkę sieciową?
Patrick Seymour
Te dwa artykuły zawierają instrukcje dotyczące tworzenia Kosza sieciowego na mapowanych dyskach sieciowych. Możesz sprawdzić, czy któryś z nich dotyczy Twojej sprawy: artykuł 1 i artykuł 2 .
harrymc

Odpowiedzi:

3

To, co widzisz, to kosz na przekierowane foldery „Moje dokumenty”.

Problem jest dobrze opisany w artykule Przekierowanie / Kosz folderu Moje dokumenty :

Podczas przekierowywania użytkowników do folderów Moje dokumenty elementy usunięte z folderu Moje dokumenty użytkownika są przechowywane w Koszu w folderze Moje dokumenty użytkownika [który znajduje się na serwerze]. Niestety maksymalny rozmiar Kosza zależy od rozmiaru dysku, na który został przekierowany folder Moje dokumenty. Domyślny rozmiar to 10%. Korzystając z klienta rejestru Twórcy polityki i Zasad grupy, wprowadziłem niezbędne ustawienia, aby maksymalny rozmiar Kosza dla folderu Moje dokumenty 1%.

Problem polega na tym, że 1% jest wciąż zbyt duży. Dysk używany do przechowywania przekierowanych Moich dokumentów ma obecnie 500 GB. 1% z tego to 5 GB, co stanowi mieszankę z około 2000 użytkownikami i jasne jest, że przez lata potencjalnie moglibyśmy przechowywać wiele niepotrzebnych plików. Nauczanie lub instruowanie 2000 użytkowników regularnego czyszczenia folderu Moje dokumenty po prostu nie jest możliwe.

Artykuł Przekierowanie folderu i Kosz zawiera następujące informacje:

Jeśli przekierujesz „Moje dokumenty”, Kosz może stać się problemem (marnowanie ton drogiego miejsca na dysku serwera).

Można kontrolować zachowanie Recycle Bin z tym kluczu rejestru: HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer\BitBucket, NukeOnDelete=1by wyłączyć użycie kosza na foldery przekierowane.

Istnieje inny element o nazwie, UseGlobalSettingsktóry ma wartość, 1 jeśli te parametry są używane dla wszystkich dysków. Przy tej wartości 0parametry kosza dla każdego dysku znajdują się jako podklucze o literze dysku.

W tym artykule pojawia się jednak inny problem:

Ten klucz NukeOnDelete jest naprawdę fajny. Przynoszę jednak inną zagadkę ... Po przekierowaniu Moich dokumentów użytkownik będzie miał dwa Kosze - jeden dla plików lokalnych, drugi dla przekierowanych plików. Gdy użytkownik przejdzie do Kosza, automatycznie ładuje przekierowane Moje dokumenty, ale nie mogę dowiedzieć się, jak uzyskać dostęp do lokalnego Kosza. Rozumiem, że lokalny Kosz to C: \ Recycler, ale katalog zawsze wydaje się pusty. Wiem, że w idealnym środowisku użytkownicy nie powinni mieć dostępu do usuwania plików z systemu lokalnego. Musi istnieć sposób, aby umożliwić użytkownikowi dostęp do lokalnego Kosza po przekierowaniu Moich dokumentów (innym niż wyłączenie przekierowania i wylogowanie / zalogowanie) ...

Więcej informacji z powyższego artykułu na temat kontroli rozmiarów pojemników:

  1. Wartość MaxCapacity znajduje się naHKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\BitBucket\KnownFolder\<GUID>
  2. W naszym środowisku przekierowujemy tylko foldery Desktop i Documents na serwer. Identyfikatory GUID dla nich to (inne znajdują się na stronie http://msdn.microsoft.com/en-us/library/bb882665.aspx ):
    1. Komputer stacjonarny: B4BFCC3A-DB2C-424C-B029-7FE99A87C641
    2. Dokumenty: FDD39AD0-238F-46AF-ADB4-6C85480369C7
  3. Na przykład, aby ustawić przekierowany folder pulpitu na użycie tylko do 200 MB, zastosuj następującą wartość rejestru:
    HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\BitBucket\KnownFolder\{B4BFCC3A-DB2C-424C-B029-7FE99A87C641}\MaxCapacity=0xC8 (0xC8 to 200 w trybie szesnastkowym)
  4. Użyłem Preferencji zasad grupy, aby wprowadzić te zmiany do naszego środowiska.
  5. W moich testach nie od razu oczyściło to elementy w Koszu, które były większe. Jednak gdy usunąłem nowy element po zastosowaniu tego ustawienia rejestru, starsze elementy zostały natychmiast usunięte z Kosza.

Jeśli chodzi o usuwanie tych plików: wykonanie tego spowoduje usunięcie skasowanych dokumentów z kosza użytkownika, więc może nie być zbyt dużym problemem. Tyle, że może wprowadzić ustawienia kosza, określając pliki, których już nie ma. Lepszym rozwiązaniem może być opróżnienie ogólnego kosza natychmiast po usunięciu wszystkich tych plików.

Szczerze mówiąc, przekierowane Moje dokumenty wydają się być po królewsku pomieszane przez Microsoft. Będziesz musiał delikatnie wkroczyć pomiędzy gotchas.

harrymc
źródło
Dobry artykuł, ale pamiętaj, że problem ukrytych plików w Koszu może i nadal będzie istniał, nawet jeśli wyłączysz maksymalny rozmiar Kosza.
HopelessN00b
3

WTF? Czy ktoś widział te symbole @ w plikach Kosza?

Tak, widziałem to w środowiskach Windows sięgających wstecz, o ile pamiętam. Zarówno w domu, w środowisku pojedynczego użytkownika i systemie Windows klienta, jak iw pracy / szkole w środowisku wielu użytkowników w systemie Windows Server z wieloma użytkownikami.

Cały dostęp do dysku sieciowego odbywa się za pośrednictwem mapowanych dysków. Czy to może wyjaśnić, dlaczego pliki są poddawane recyklingowi? I ukryty?

Nie. To, co widzisz, jest funkcją sposobu działania Kosza .


Po usunięciu pliku pełna ścieżka i nazwa pliku są przechowywane w ukrytym pliku o nazwie Info lub Info2 (Windows 98) w folderze Recycled. Nazwa usuniętego pliku jest zmieniana przy użyciu następującej składni:

D<original drive letter of file><#>.<original extension> 

Jeśli chodzi o „wyjaśnianie”, dlaczego tak się dzieje z Koszem systemu Windows, nigdy nie widziałem bardziej miarodajnego wyjaśnienia niż „ wzruszanie ramionami … korupcja”. Podsumowanie w połączonym artykule informuje, która część procesu się nie udaje, ale nie zagłębia się w szczegóły dotyczące procesu, które należy właściwie wyjaśnić, co się właściwie psuje i gdzie. Prawdopodobnie, gdyby tak było, ktoś do tej pory naprawiłby ten problem.

Chociaż codziennie wykonujemy kopie zapasowe, planuję wykorzystać ten zasób w celu odzyskania plików w ostateczności. Wszelkie sugestie lub ostrzeżenia?

Nie, odsuń się. Plików nie można przywrócić do ich pierwotnych nazw (ponieważ nie ma ich już w pliku INFO manifestu zawartości Kosza), a użytkownicy nie mogą ich zobaczyć / nie wiedzą, że już tam są, więc to tylko zmarnowane miejsce.

Beznadziejny
źródło
W cytowanym artykule pliki mają #, a plakat ma @. Ponadto wiele rzeczy zmieniło się od systemu Windows 98, więc ten artykuł tak naprawdę nie ma zastosowania.
harrymc
@harrymc Jestem pozytywny. @Istnieje, ponieważ plik pierwotnie „pochodzi od” udziale sieciowym lub ścieżki, zamiast napędu z listem. Zamiast tego, DC[#].[whatever]jeśli pierwotnie pochodzi z Cdysku, otrzymujesz D@[#].[whatever]... ponieważ udział sieciowy lub ścieżka UNC nie ma „litery dysku”, aby przejść do pozycji drugiego znaku. (Więc używa @symbolu zamiast litery dysku ... z jakiegokolwiek powodu.)
HopelessN00b
Mówi, że dostęp jest udostępniany przez mapowane udziały, więc mają literę dysku. Próbowałem zduplikować jego problem i nie mogę nim zarządzać, mapowany czy nie: pliki zostały właśnie usunięte. Dziwne. Czy możesz to powielić? Zobacz wikipedię, aby zapoznać się z nową konwencją nazewnictwa używającą $, nie @lub #.
harrymc
@harrymc Nie mogę powielić go na polecenie, ale zarządzam dziesiątkami serwerów plików z tego rodzaju plikami na nich, w ścieżce przekierowanego profilu użytkownika. Dysk mapowany nie jest tym samym dyskiem, co dyski podłączone lokalnie, ponieważ mapowania sieciowe (i dołączone wraz z nimi mapowania liter dysków) są ustawieniami dla poszczególnych użytkowników, a nie ustawieniami ogólnosystemowymi. Oznacza to, że gdy system zapisuje oryginalną lokalizację pliku w manifeście kosza, używa rzeczywistej ścieżki, takiej jak \\server1\Users\smithj\smithj's Documents\somefileścieżka, którą widzi użytkownik, np Y:\somefile.
HopelessN00b
Przeprowadziłem dalsze badania tego ciekawego problemu i znalazłem więcej informacji, które podałem w osobnej odpowiedzi.
harrymc