none
Проблема с файловым сервером. RRS feed

  • Вопрос

  • Всем привет.

     

    После переноса данных с старого файлового сервера на новый столкнулись вот с какой проблемой. Пользователям, один раз открывшим файл Excel с сетевой шары не удается потом его удалить или переименовать в этой директории, права естественно настроены правильно, была мысль что это происходит из-за длинных путей к файлу, но дело не в этом, кто сталкивался?

    30 июля 2008 г. 11:08

Ответы

  • Проблема была в приложении McAfee VirusScan 8.0 Patch 16 (была официально объявлена производителеем). Использование этого патча не реккомендуется.

    8 октября 2009 г. 6:09

Все ответы

  • какая операционка? чем копировали файлы?
    30 июля 2008 г. 11:38
  • Сервер Windows 2003 SP2, в логах тишина, ошибка вот такая:

    ---------------------------
    Error Renaming File or Folder
    ---------------------------
    Cannot rename New Microsoft Excel Worksheet: It is being used by another person or program.

    Close any programs that might be using the file and try again.
    ---------------------------
    OK
    ---------------------------

    После перезагрузки сервера всё приходит в норму, но только первого открытия файла, открыли закрыли и снова не можем не переименовать ни удалить.

     

    При переносе данных использовался софт Microsoft File Server Migration Toolkit, вот только проблема в том, что это происходит и при создании нового файла на томе в любой из папок, возможно играет роль какой-то сторонний софт, но идентифицировать его я не могу.

     

    На сервере стоит программа Unlocker, но роли это не играет как я понимаю, так вот он говорит что не удается идентифицировать дискриптор который блокирует файл и предлагает его освободить, так вот проблема как раз в том, что бы отследить это, что имеено блокирует файл.

    30 июля 2008 г. 11:57
  • это был простой перенос файлов? почему не воспользовались утилитой robocopy? вроде она все переносит со структурой каталогов и правами. При ее использовании подобных проблем не испытывала.
    30 июля 2008 г. 13:05
  •  Аero написано:
    Пользователям, один раз открывшим файл Excel с сетевой шары не удается потом его удалить или переименовать в этой директории
    Посмотрите ProcessExplorer'ом (на сервере) кто держит этот файл.
    30 июля 2008 г. 13:36
  • Почему не Robocopy вопрос риторический, меня сейчас интересует как исправить ситуацию, виноватых не найти, да и цели нет, занимался этим не я. А насчёт Process Explorer-а, никак не могу понять какая его опция позволяет просмотреть кто держит файл?

    31 июля 2008 г. 4:45
  • Find -> Find Handle or DLL -> имя файла.

    31 июля 2008 г. 4:50
  • Ничего не показывает, странно, но ничего не показывает если для примера открыть файл test.txt, что его использует notepad, хотя открываю test.chm, показыает что этот файл занят, вообщем по моей проблеме результата 0 от этой утилиты, еще предложения?

    31 июля 2008 г. 5:15
  •  

    оснастка Управление компьютером -> СЛужебные программы->Общие папки->Открытые файлы

    может действительно кто-то еще открывает

     

    31 июля 2008 г. 5:19
  •  

    Проблема в том, что точно такая же ситуация и при работе с файлами через терминал, с теми файлами котторые вообще не расшарены, может проверить ChkDsk-ом, хуже не станет?
    31 июля 2008 г. 6:17
  •  Аero написано:
    может проверить ChkDsk-ом, хуже не станет?
    Конечно проверьте, но не думаю, что это исправит ситуацию...
    31 июля 2008 г. 6:47
  • Проблема была в приложении McAfee VirusScan 8.0 Patch 16 (была официально объявлена производителеем). Использование этого патча не реккомендуется.

    8 октября 2009 г. 6:09
  • Неоднократно уже высказывал мнение, что использование антивирусных мониторов на серверах - вещь глубоко порочная. На каждой странице технета можно найти сообщения от людей, которым то один, то другой антивирус подгаживает. Почему бы вам не применять гораздо более эффективные и надёжные методы защиты?
    9 октября 2009 г. 6:08
    Отвечающий
  • Почему бы вам не применять гораздо более эффективные и надёжные методы защиты?

    Неграмотная настройка инструмента или косяк (как в нашем случае) производителя еще не повод отказываться от достаточно эффективного и вполне себе устраивающего инструмента, на мой взгляд. В нашем случае "гораздо более эффективные и надёжные методы защиты" мешает применять корпоративный стандарт.
    15 октября 2009 г. 8:16