Користувацькі папки RECYCLER містять тисячі прихованих файлів


11

У нас є папка "Користувачі", яка є коренем усіх файлів користувача та мережевих профілів.

Використовуючи утиліту розміру каталогів (WinDirStat), я натрапив на дивну і хвилюючу проблему - тисячі файлів, ефективно приховані в інтерфейсі Windows Recycle Bin. Кожна папка користувача має папку RECYCLER безпосередньо під My Documents, наприклад:

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

Дуже небагато наших користувачів мають ПК, оскільки більшість користувачів входять на сервер додатків Citrix із простого терміналу Wyse. Оскільки більша частина їхніх файлових дій відбувається на мережевих спільних ресурсах, користувачі (а ми адміністратори) завжди розуміли, що немає "Мережевої кошика".

Однак у прихованій папці RECYCLER для більшості користувачів є тисячі файлів. Виділяється кілька речей:

  1. У більшості випадків жоден з файлів не відображається за допомогою інтерфейсу кошика
  2. Угода про іменах для окремих файлів , має включати в себе букву диска , такі як DCабо DD, але замість цього вони все починаються з D@- наприклад, D@1234.doc.
  3. Я вважаю, що @символ заважає Windows перенаправити оригінальні файли, тому вони просто придушуються в інтерфейсі користувача.
  4. Файли разом споживають десятки гігабайт. Вони не привиди. Видалення деяких файлів збільшує вільний простір на диску.
  5. Схоже, насправді у нас є "мережевий кошик". Випадково. Без реальних імен файлів.

Ми вже вирішили видалити всі файли, старші за Xкілька днів. Я можу це зробити за допомогою сценарію PowerShell. На відміну від подібного випадку , ми збираємось видалити окремі файли замість усієї папки.

Отже, мої запитання:

  • Хтось бачив ці @символи у файлах кошика?
  • Весь доступ до мережевого диска здійснюється через відображені на карті диски. Чи може це пояснити, чому файли переробляються? І приховано?
  • Хоча ми виконуємо резервні копії щодня, я хочу лише натиснути цей ресурс для відновлення файлів останньої інстанції. Будь-які пропозиції чи застереження?

Не знаєте, чи все-таки все ще поруч, враховуючи вік цього питання, але ви перенаправляєте Мої документи на мережевий шлях?
Патрік Сеймур

У цих двох статтях містяться інструкції, як створити мережевий кошик для відображення на картографічних мережевих накопичувачах. Ви можете перевірити, чи стосується будь-якого з ваших випадків: стаття 1 та стаття 2 .
harrymc

Відповіді:


3

Те, що ви бачите, - це кошик для перенаправлених папок "Мої документи".

Проблема добре описана у статті Мої документи перенаправлення папки / кошик :

Під час використання переадресації папок для переадресації користувачів папки "Мої документи" елементи, видалені з папки "Мої документи" користувача, зберігаються в кошику в папці "Мої документи" користувача [що живе на сервері]. На жаль, максимальний розмір кошика базується на розмірі диска, на який також була перенаправлена ​​папка Мої документи. Розмір за замовчуванням - 10%. Використовуючи клієнт реєстру виробника політики та групову політику, я застосував необхідні настройки, щоб максимальний розмір кошика для папки "Мої документи" становив 1%.

Проблема полягає в тому, що 1% все ще є великим. Диск, який використовується для зберігання перенаправлених Моїх документів, наразі становить 500 Гб. 1% від цього становить 5 Гб, це близько 2000 користувачів, і зрозуміло, що за ці роки ми могли потенційно зберігати багато непотрібних файлів. Навчити або доручити 2000 користувачам регулярно чистити папки «Мої документи» просто неможливо.

У статті "Перенаправлення папок і кошик" йдеться про таке:

Якщо ви переспрямовуєте "Мої документи", кошик може стати проблемою (витрачаючи тонни дорогого місця на сервері на диску).

Ви можете контролювати поведінку кошика Bin з цим ключем реєстру: HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer\BitBucket, NukeOnDelete=1буде відключити використання кошика для перенаправлені папок.

Є ще один елемент, який називається UseGlobalSettings, 1 якщо ці параметри використовуються для всіх дисків. За значенням 0параметри кошика для кожного диска знаходять як під-ключі, що мають букву диска диска.

Однак у цій статті є ще одна проблема:

Цей ключ NukeOnDelete дуже приємний. Однак я створюю ще одну загадку ... Після перенаправлення «Моїх документів» у користувача з’являться дві кошики для переробки - одна для локальних файлів, а друга - для перенаправлених файлів. Коли користувач переходить до кошика, він автоматично завантажує перенаправлені Мої документи, але я не можу дізнатися, як отримати доступ до місцевого кошика. Я розумію, що місцевий кошик є C: \ Recycler, але каталог завжди видається порожнім. Я знаю, що в ідеальному середовищі користувачі не повинні мати доступу до видалення файлів з локальної системи. Повинен бути спосіб дозволити користувачеві отримати доступ до місцевого кошика після перенаправлення Моїх документів (крім відключення перенаправлення та виходу / входу) ...

Більше інформації з наведеної статті про керування розмірами кошика:

  1. Значення MaxCapacity знаходиться наHKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\BitBucket\KnownFolder\<GUID>
  2. У нашому середовищі ми переспрямовуємо папки Настільний і Документи лише на сервер. GUID для цього є (інші розміщені за адресою http://msdn.microsoft.com/en-us/library/bb882665.aspx ):
    1. Настільний: B4BFCC3A-DB2C-424C-B029-7FE99A87C641
    2. Документи: FDD39AD0-238F-46AF-ADB4-6C85480369C7
  3. Як приклад, щоб встановити переспрямовану папку на робочий стіл лише до 200mb, застосуйте таке значення реєстру:
    HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\BitBucket\KnownFolder\{B4BFCC3A-DB2C-424C-B029-7FE99A87C641}\MaxCapacity=0xC8 (0xC8 - 200 у шістнадцятковій кількості)
  4. Я скористався налаштуваннями групової політики, щоб перенести ці зміни на наше середовище.
  5. У моєму тестуванні це не відразу очистило предмети в кошику, які були більшими. Однак, коли я видалив новий елемент після застосування цього параметра реєстру, старіші елементи були негайно видалені з кошика.

Що стосується видалення цих файлів: це призведе до того, що ви видалите видалені документи з кошика користувача, тому це може бути не надто великою проблемою. За винятком того, що це може втратити настройки кошика із зазначенням файлів, які вже не існують. Можливо, краще видалити загальну кошик для сміття відразу після видалення всіх цих файлів.

Чесно кажучи, переглянуті Мої документи, здається, були по-справжньому переплутані Microsoft. Вам доведеться делікатно переступити між гетчами.


Хороша стаття, але зауважте, що проблема прихованих файлів у кошику може існувати і існує, навіть якщо ви відключите параметр максимального розміру для кошика.
HopelessN00b

3

WTF? Хтось бачив ці символи @ у файлах кошика?

Так, я бачив це в середовищах Windows, наскільки я пам'ятаю. Як вдома, в одиночному користувальницькому середовищі та клієнтських операційних системах Windows, так і на роботі / в школі в багатокористувацьких середовищах на ОС Windows Server з багатьма користувачами.

Весь доступ до мережевого диска здійснюється за допомогою Mapped Drive. Чи може це пояснити, чому файли переробляються? І приховано?

Ні. Те, що ви бачите, - це функція способу роботи кошика .


Коли ви видаляєте файл, повний шлях та ім’я файлу зберігаються у прихованому файлі під назвою Info або Info2 (Windows 98) у папці Recycled. Видалений файл перейменовано, використовуючи наступний синтаксис:

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

Щодо "пояснення", чому це відбувається з кошиком для Windows, я ніколи не бачив більш авторитетного пояснення, ніж " знизати плечима ... корупція". Короткий зміст у пов’язаній статті розповідає про те, яка частина процесу йде не так, але не вникає в тип деталей про процес, який вам знадобиться правильно пояснити, що насправді виходить з ладу, і де. Імовірно, якби вони були, хтось уже вирішив би це питання.

Хоча ми виконуємо резервні копії щодня, я планую скористатися цим ресурсом для відновлення файлів останньої інстанції. Будь-які пропозиції чи застереження?

Ні, ядра. Файли не можуть бути відновлені до їхніх оригінальних імен (так як вони більше не містяться в маніфесті файлу INFO зі вмістом кошика), і користувачі не можуть їх бачити / не знають, що вони там є, тому це просто витрачений простір.


У статті, яку ви цитуєте, файли є #, а плакат є @. Крім того, багато речей змінилося з Windows 98, тому стаття насправді не застосовується.
harrymc

@harrymc Я позитивний. @Існує тому , що файл спочатку «прийшов з" загальною мережевий папці або шлях, а не диск з листом. Тож замість того, DC[#].[whatever]якби він спочатку прийшов з Cдиска, ви отримуєте D@[#].[whatever]... тому що мережева частка або шлях UNC не мають "літери накопичувача", щоб перейти на цю позицію другого символу. (Отже, він використовує @символ замість літери диска ... з будь-якої причини.)
HopelessN00b

Він каже, що доступ здійснюється через накреслені акції, тому у них є лист із накопичувачем. Я намагався дублювати його проблему, і я не можу керувати нею, зіставлений чи ні: файли просто видаляються. Дивно. Ви можете скопіювати це? Дивіться у wikipedia нову конвенцію про іменування, використовуючи $, не @або #.
harrymc

@harrymc Я не можу дублювати це командою, але я адмініструю десятки файлових серверів із цими видами файлів на них у дорозі переспрямованого профілю користувачів. Відображений привід не є тим самим, як локально приєднані накопичувачі, оскільки мережеві відображення (і відображення букв диска, що постачаються разом з ними) є налаштуваннями для кожного користувача, а не загальносистемними. Це означає, що коли система записує оригінальне розташування файлу в маніфест кошика, вона використовує фактичний шлях, наприклад, \\server1\Users\smithj\smithj's Documents\somefileа не шлях, який бачить користувач, наприклад Y:\somefile.
HopelessN00b

Я провів ще кілька досліджень з цієї цікавої проблеми і знайшов більше інформації, яку я виклав окремо у відповідь.
harrymc
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.