Папки с GUID в каталоге 1cv8: чья это база и что с ними делать

Кэш какой базы лежит в папке, видно по её имени: GUID папки в %LOCALAPPDATA%\1C\1cv8\ и %APPDATA%\1C\1cv8\ совпадает со строкой ID= у нужной базы в файле %APPDATA%\1C\1CEStart\ibases.v8i. Открываете файл блокнотом, ищете этот GUID и смотрите, в какой секции [Название базы] он стоит.

Частое заблуждение: «кэш привязан к самой базе, значит у всех пользователей папка называется одинаково». Это не так. GUID принадлежит строке в списке баз конкретного пользователя. Добавили одну и ту же базу в список дважды — получили две разные папки кэша. Описание относится к платформе 8.3 и не зависит от конфигурации: в БП, ЗУП и УТ всё устроено одинаково.

Как устроен клиентский кэш 1С и откуда берутся папки с GUID

При первом входе в базу платформа скачивает к себе на компьютер файлы конфигурации: модули, формы, макеты, картинки. В следующий раз она сверяет версии и тянет только изменённое. Поэтому второй запуск идёт заметно быстрее первого, особенно в клиент-серверном варианте и через веб-публикацию.

Хранится всё это в двух местах профиля Windows:

%LOCALAPPDATA% обычно раскрывается в C:\Users\<имя>\AppData\Local, %APPDATA% — в C:\Users\<имя>\AppData\Roaming. Папка AppData скрыта: вставьте путь с переменной прямо в адресную строку Проводника или в окно Win + R.

Имя каждой папки — это идентификатор строки списка баз. Он генерируется, когда базу добавляют в список окна запуска, и записывается в ibases.v8i полем ID. По этому идентификатору платформа и понимает, в какую папку класть кэш при входе.

Отсюда три следствия, которые объясняют большинство вопросов «почему кэш раздувается»:

• 📁 удалили базу из списка и добавили заново — у неё новый ID и новая папка, старая остаётся на диске мёртвым грузом;
• 👥 одна база добавлена в список дважды (например, «Бухгалтерия» и «Бухгалтерия копия» с одной строкой подключения) — две папки, два полных кэша;
• 🖥 на терминальном сервере у каждого пользователя свой профиль, а значит, свой набор папок на каждую базу.

Ищем идентификатор базы в файле ibases.v8i

Файл ibases.v8i — обычный текст в кодировке UTF-8. Каждая база в нём занимает секцию, которая начинается с названия в квадратных скобках.

Пример секции:

[Бухгалтерия ООО Ромашка]
Connect=Srvr="srv1c";Ref="buh_romashka";
ID=3f5b2c1e-8a47-4d9b-9c11-2e6f0a7d4b58
OrderInList=16384
Folder=/
OrderInTree=16384
External=0
ClientConnectionSpeed=Normal
App=Auto
WA=1
Version=8.3
DefaultApp=ThinClient

Что здесь важно:

• 🔑 ID — тот самый GUID, которым названа папка кэша;
• 🔌 Connect — строка подключения. Srvr и Ref означают серверную базу (сервер и имя базы в кластере), File="D:\Bases\Buh" — файловую, ws="https://..." — веб-публикацию;
• 🏷 название в скобках — то, что пользователь видит в окне запуска. Оно ничего не говорит о реальной базе: две строки с разными названиями могут смотреть в одну базу.

Пошагово: от папки к базе

1. Скопируйте имя подозрительной папки из %LOCALAPPDATA%\1C\1cv8\, например 3f5b2c1e-8a47-4d9b-9c11-2e6f0a7d4b58.
2. Откройте %APPDATA%\1C\1CEStart\ibases.v8i в Блокноте. Ничего не меняйте и не сохраняйте.
3. Нажмите Ctrl + F и вставьте GUID.
4. Поднимитесь вверх от найденной строки до ближайшего [...] — это название базы в списке.
5. Посмотрите строку Connect, чтобы понять, какая база стоит за названием на самом деле.

Обратный путь — от базы к папке — такой же: находите секцию по названию, копируете ID и ищете папку с этим именем.

Если GUID в ibases.v8i не нашёлся

Вариантов два.

Первый: база приходит из общего списка. Администратор может раздавать список баз через файл на сетевом ресурсе, а путь к нему прописывается в 1cestart.cfg параметром CommonInfoBases=. Тогда секции с ID лежат в том общем файле, а не в личном ibases.v8i. Откройте 1cestart.cfg в %APPDATA%\1C\1CEStart\ (или общий для всех пользователей в C:\ProgramData\1C\1CEStart\), найдите путь и ищите GUID там.

Второй: строку давно удалили из списка, а папка осталась. Такая папка — сирота. Её можно удалить при закрытой 1С, ничего не потеряв.

Где найти папку кэша нужной базы на диске пользователя

Иногда открывать ibases.v8i неудобно: пользователь на удалёнке, баз полсотни, названия похожие. Есть два быстрых приёма.

Приём «по дате изменения»

1. Попросите пользователя закрыть все окна 1С.
2. Откройте %LOCALAPPDATA%\1C\1cv8\ в Проводнике, включите вид «Таблица».
3. Пусть пользователь запустит нужную базу и сразу закроет её.
4. Отсортируйте папки по столбцу «Дата изменения». Верхняя папка — кэш только что открытой базы.

Этот способ однозначно показывает, кэш какой базы используется клиентом прямо сейчас, даже если в списке несколько строк с одной базой.

Терминальный сервер и чужие профили

На RDS-сервере папки ищите в профиле нужного пользователя: C:\Users\<логин>\AppData\Local\1C\1cv8\. Список баз этого же пользователя — C:\Users\<логин>\AppData\Roaming\1C\1CEStart\ibases.v8i. Для чтения чужого профиля нужны права администратора.

Если включены перемещаемые профили или перенаправление папок, Roaming может лежать на файловом сервере. Тогда %APPDATA% в сеансе пользователя покажет реальный путь — откройте его из его сеанса.

Кэш на сервере 1С: другая логика

Не путайте клиентский кэш с данными на сервере 1С:Предприятия. На сервере в каталоге кластера (по умолчанию srvinfo\reg_1541\) тоже лежат папки с GUID. Но эти GUID — идентификаторы информационных баз в кластере, а не строк в списке пользователя.

Сопоставить их можно утилитой rac на сервере:

rac cluster list
rac infobase summary list --cluster=<uuid кластера>

Вторая команда выводит для каждой базы её infobase (GUID) и name (имя в кластере). Имя папки в reg_1541 ищите среди этих GUID.

Скрипт: все папки кэша с названиями баз и размером

Руками сопоставлять двадцать папок долго. Скрипт PowerShell ниже читает личный список баз и общие списки из 1cestart.cfg, проходит по обоим каталогам кэша и выводит таблицу: папка, название базы, размер. Папки без строки в списке помечаются как сироты.

Запускать от имени того пользователя, чей кэш смотрите. Скрипт ничего не удаляет.

$lists = @("$env:APPDATA\1C\1CEStart\ibases.v8i")
$cfg = "$env:APPDATA\1C\1CEStart\1cestart.cfg"
if (Test-Path $cfg) {
    foreach ($line in Get-Content $cfg) {
        if ($line -match '^CommonInfoBases=(.+)$') { $lists += $Matches[1].Trim() }
    }
}

$map = @{}
foreach ($file in $lists) {
    if (-not (Test-Path $file)) { continue }
    $name = $null
    foreach ($line in Get-Content $file -Encoding UTF8) {
        if ($line -match '^\[(.+)\]$') { $name = $Matches[1] }
        elseif ($line -match '^ID=(.+)$') { $map[$Matches[1].Trim()] = $name }
    }
}

$result = foreach ($root in "$env:LOCALAPPDATA\1C\1cv8", "$env:APPDATA\1C\1cv8") {
    if (-not (Test-Path $root)) { continue }
    Get-ChildItem $root -Directory |
        Where-Object { $_.Name -match '^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-' } |
        ForEach-Object {
            $bytes = (Get-ChildItem $_.FullName -Recurse -File -ErrorAction SilentlyContinue |
                      Measure-Object Length -Sum).Sum
            $base = if ($map.ContainsKey($_.Name)) { $map[$_.Name] } else { '(сирота, нет в списке)' }
            [pscustomobject]@{
                Каталог = Split-Path $root -Leaf
                Папка   = $_.Name
                База    = $base
                МБ      = [math]::Round($bytes / 1MB, 1)
                Изменена = $_.LastWriteTime
            }
        }
}
$result | Sort-Object МБ -Descending | Format-Table -AutoSize

Чтобы сохранить отчёт в файл и открыть в Excel, замените последнюю строку на:

$result | Export-Csv "$env:USERPROFILE\Desktop\1c_cache.csv" -NoTypeInformation -Encoding UTF8 -Delimiter ';'

Если PowerShell ругается на политику выполнения, запустите скрипт так: powershell -ExecutionPolicy Bypass -File .\cache_map.ps1. Это разрешает запуск только этого файла и не меняет настройки системы.

Когда дело не в кэше: проверка файловой базы утилитой chdbfl

Кэш чистят, когда 1С ведёт себя странно: формы открываются в старом виде после обновления, появляются ошибки при открытии, падает клиент. Если после очистки кэша нужной базы ошибка осталась, а база файловая, проблема может быть в самом файле базы 1Cv8.1CD. Для этого есть chdbfl.exe.

Утилита лежит в каталоге платформы: C:\Program Files\1cv8\<номер версии>\bin\chdbfl.exe. Она проверяет физическую целостность файла 1Cv8.1CD и к кэшу клиента отношения не имеет. Её роль в этой истории — отделить «сломан кэш» от «сломана база».

Порядок работы:

1. Убедитесь, что в базе никого нет: все пользователи вышли, фоновые задания и обмены остановлены. Утилита требует монопольного доступа к файлу.
2. Сделайте копию каталога базы целиком. Без копии не включайте исправление ошибок — утилита может удалить повреждённые данные безвозвратно.
3. Запустите chdbfl.exe, укажите путь к файлу 1Cv8.1CD.
4. Первый проход сделайте без галочки исправления, только проверку.
5. Если ошибки найдены — включите исправление и запустите повторно, уже на копии или после неё.

Для серверных баз chdbfl не применяется: целостность таблиц проверяют средствами СУБД и через Тестирование и исправление в Конфигураторе.

Права доступа, RLS и кэш: что очистка решает, а что нет

Вопрос «поменяли роль или ограничение RLS, а пользователь всё видит по-старому — почистить кэш ?» звучит регулярно. Ответ: не поможет, и вот почему.

Клиентский кэш хранит файлы конфигурации и локальные настройки. Данных информационной базы и прав пользователя в нём нет. Ограничения доступа на уровне записей (RLS) проверяются на сервере при каждом запросе к данным: клиент получает уже отфильтрованный результат и сам ничего не решает.

Что на самом деле держит старые права:

• 🔄 текущий сеанс. Роли и параметры сеанса, на которые опираются шаблоны RLS, вычисляются при входе. Пользователь должен выйти из 1С и зайти снова;
• 🧠 повторно используемые значения. Общие модули с этим свойством кэшируют результаты функций на время сеанса. Если там вычисляются признаки доступа, они обновятся только при новом сеансе;
• 🛠 конфигурация не обновлена. Если роль меняли в Конфигураторе, изменения действуют только после обновления конфигурации базы данных.

Когда очистка кэша при работе с правами всё же нужна: после обновления конфигурации у пользователя открываются старые формы или вылетают ошибки при открытии, хотя у остальных всё нормально. Это уже симптом кэша, а не прав.

Очистка кэша выбранной базы и профилактика

Когда папка найдена, есть три способа очистить её кэш — от самого мягкого к ручному.

Параметр /ClearCache

В окне запуска выделите базу, нажмите Изменить и дойдите до последней страницы мастера. В поле «Дополнительные параметры запуска» впишите /ClearCache и нажмите Готово. Запустите базу один раз, затем уберите параметр — иначе кэш будет скачиваться заново при каждом входе.

Тот же ключ работает из командной строки, например при запуске ярлыком: 1cestart.exe /ClearCache, вместе с остальными параметрами подключения.

Ручное удаление

1. Закройте все окна 1С у пользователя. В диспетчере задач не должно остаться процессов 1cv8.exe и 1cv8c.exe.
2. Удалите папку с найденным GUID в %LOCALAPPDATA%\1C\1cv8\.
3. При необходимости удалите папку с тем же GUID в %APPDATA%\1C\1cv8\.
4. Запустите базу. Первый вход займёт больше времени: конфигурация скачается заново.

Не удаляйте весь каталог 1C целиком «для надёжности»: вместе с ним пропадёт 1CEStart со списком баз, и пользователю придётся добавлять их снова — с новыми ID и новым кэшем.

Автоматическая очистка сирот на терминальном сервере

Сироты копятся годами: на сервере на 30 пользователей легко набрать десятки гигабайт. Скрипт для запуска при входе пользователя удаляет только папки, которых нет в его списках баз. Это продолжение скрипта выше: добавьте после блока, заполняющего $map.

foreach ($root in "$env:LOCALAPPDATA\1C\1cv8", "$env:APPDATA\1C\1cv8") {
    if (-not (Test-Path $root)) { continue }
    Get-ChildItem $root -Directory |
        Where-Object { $_.Name -match '^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-' -and -not $map.ContainsKey($_.Name) } |
        Remove-Item -Recurse -Force -ErrorAction SilentlyContinue
}

Ставьте его в сценарий входа пользователя, до запуска 1С. Если общий файл списка на сетевом ресурсе в этот момент недоступен, $map окажется неполным и скрипт удалит кэш живых баз. Ничего не сломается, просто первый вход будет долгим. Чтобы этого избежать, добавьте в начало проверку Test-Path для общего файла и выходите из скрипта, если его нет.

Профилактика сводится к трём правилам:

• ✏️ правьте строку подключения в существующей секции списка, а не удаляйте и не добавляйте базу заново;
• 📋 раздавайте общий список баз одним файлом через CommonInfoBases, чтобы у пользователей не было дублей;
• 🧹 раз в квартал прогоняйте отчётный скрипт на терминальных серверах и смотрите, сколько места занимают сироты.

Частые вопросы