up7, Вообще вы пользуетесь ActiveX оберткой над системной функцией SHBrowseForFolder. На самом деле в самой системной функции более широкие возможности. Например там можно задать свою "почти оконную функцию", которая может обрабатывать сообщения винды. Возможно системная функция лишена этого недостатка с длинной пути.
На сколько я знаю из C# можно вызывать функции WinAPI напрямую. Попробуйте такой вариант.
У меня был опыт издевательств над SHBrowseForFolder - делал центрирование окна функции над консольным окном, из которого она вызывалась.
up7, Есть параметр в реестре:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\LongPathsEnabled
Если его выставить в 1 (и перезагрузиться), то каким-то приложениям помогает преодолеть это ограничение.
Я не сталкивался с ситуацией, где бы мне это помогло. Возможно вам поможет.
То же самое можно сделать прописав соответствующую опцию в манифесте программы. Подробней тут.
Вообще ограничение в 260 символов было во времена, наверное, Вин95. Тогда в WinSDK в заголовочных файлах была константа MAX_PATH равная 260. Сейчас это давно уже не актуально. Но многие программы до сих пор пользуются этой константой (на сколько знаю она до сих пор на месте, возможно для совместимости).
PS: На сколько я знаю функция BrowseForFolder не имеет своего юникодного двойника, в котором бы были сняты ограничения на длину пути.
Возможно папка "5677..." слишком длинная, поэкспериментируйте с ее размером.
Так же возможны в имени папки какие-либо спец.символы ( &<>|! ).
Вообще вряд ли вы как-то сможете повлиять на работу системной функции, разве что написать свою. Unicode тут не причем, вы же используете С#, а там юникод по умолчанию.
Посмотрите виндовый журнал, возможно там есть какие-то сообщения подозрительные.
Вообще сама система бесконечно память не отжирает, хоть и винда. Для Вин7 4Гб в принципе достаточно. Может быть не достаточно для какого-либо софта.
Начинайте деинсталлировать софт, который устанавливали последним и смотрите как себя ведет система.
Profi_GMan, Есть предположение, что в выводе mountvol EFI раздел последний. Проверить не могу - под рукой только один комп.
Другой вариант - монтировать все не смонтированные разделы и проверять наличие каталога \Boot или загрузчика винды.
Profi_GMan, О том, что с ключом /s он требует указание диска а:
У меня аналогичное поведение.
Но можно монтировать EFI раздел без ключа /s на какую угодно букву используя синтаксис:
mountvol x:\ \\?\Volume{xxxx}
Список доступных идентификаторов томов выводится той же mountvol, если запустить ее без параметров. Один из не примонтированных томов и есть EFI раздел.
Да. В никсах, в отличие от виндов, GUI не является частью ОС и вообще не является чем-то необходимым для работы ОС. Возьмите debian, например, у них есть легкая сборка (netinst) только с командной строкой. Потом, при желании, можно будет доустановить GUI вручную. И в никсах в общем-то нет каких-то серверных дистрибутивов - любую установку можно довести как до "серверного" варианта так и до "десктопного". То что заявляется как "серверный" просто включает в себя некий набор софта, который обычно устанавливается на сервер, а так же некоторые настройки ядра для оптимизации серверных операций.
Тимофей, Прочитал апдейты.
По скринам видно, что дохнут сектора, но пока еще порог не пройден.
Если диски реально дохнут, то порог будет пройден в ближайшее время.
Но может быть, что переназначения были уже давно и больше их нет.
Есть смысл сделать бэкап и понаблюдать несколько дней за дисками, если количество переназначений будет увеличиваться - значит смерть дисками близка.
Можете поставить какую-либо компактную утилиту для мониторинга SMART состояния дисков, например smarthdd и наблюдать с ее помощью.
На сколько я знаю из C# можно вызывать функции WinAPI напрямую. Попробуйте такой вариант.
У меня был опыт издевательств над SHBrowseForFolder - делал центрирование окна функции над консольным окном, из которого она вызывалась.