Восстановление данных с флешки, жесткого диска

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

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

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

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

Файловая система требует восстановления структуры при форматировании логического диска или его раздела. При этом атрибуты и структура данных не нарушаются, однако изменяется или приводится к начальному состоянию информация о располагаемых на данном накопителе данных. «Быстрое форматирование» производит только малую часть обновления файловой таблицы, при этом остается часть служебных записей, которую необходимо лишь интерпретировать для прочтения данных в нужном порядке.

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

Во время удаления данных, информация физически остается на накопителе (будь то flash карта или hdd), однако в файловой системе она более не отображается, а место на носителе, где она располагалась ранее, помечается в качестве свободного и готового к записи новых данных. В этом случае изменяются атрибуты файлов, а при записи в раздел логического диска может произойти полное или частичное замещение помеченных удаленными данных.

Подобные файлы могут быть прочитаны и восстановлены вместе со своими атрибутами с помощью прочтения служебных записей файловой системы. Существуют не только программы для восстановления удаленных данных, но и комплексные решения, в которых восстановление таких данных является лишь одной из функций. Однако существуют и специальные программы для уничтожения данных — «шредеры». После их правильного использования восстановление любых данных становится невозможным.

Почему возникает долгая загрузка Windows и что делать

На чтение: 4 минОпубликовано: 13. 05.2017Рубрика: ПроблемыАвтор: EvilSin225

Здравствуйте, в этой статье мы поговорим о медленные работы системы благодаря приложениям и программам, которые могут висеть в фоне. Сами они могут являться как полезными, так и не очень, но мы научимся определять самое энергозатратное. Если у вас долгая загрузка Windows 10 или любой другой версии происходит от нескольких минут и больше, то причиной может быть какая-то программа, которая запускается вместе с системой.

Почему происходит долгая загрузка Windows 10 и как это исправить?

Для того, чтобы оптимизировать работу Windows в интернете и на моем сайте вы можете найти много статей. Они действительно могут помочь, если грамотно их использовать. Также на эту тему пишут и книги. Пока что я рассмотрю один случай сокращения запуска системы и её стабильной работы- отключение программ из автозапуска. Таким образом мы узнаем, что за прожорливый инструмент забирает столько ресурсов компьютера и отключим его. Помимо этого, вам придётся обратить внимание на другие составляющие Windows. Дело в том, что не только программы в автозапуске тормозят систему, есть еще и множество других вариантов, например, антивирус, неправильные настройки системы, а также вирусы. Поэтому, если способ из данной статьи не поможет, то придётся искать другую причину.

Узнать о медленном запуске Window 10 и любой другой системы можно при помощи Журнала событий. Правда там вы определите только время, дату и еще пару моментов, что не относится к теме статьи совершенно. Переходим непосредственно к решению проблемы, на вступительной части закончим.

Запускаем диспетчер задач. Это можно сделать нажатием клавиш Esc+Shift+Ctrl, либо при нажатии правой кнопкой мыши по меню Пуск и выбрав там нужный пункт.

Если открылось маленько окошко, в котором нет ничего кроме кнопки «Подробнее», то жмём на неё.

Теперь переходим во вкладку «Автозагрузка» и смотрим там на влияние программ на систему. Оно может быть Низкое, Среднее и Высокое. Нас интересует сейчас «Высокое» понятие, так как одного этого слова нам недостаточно, нужно больше информации.

Нажмём по любому названию столбца правой кнопкой мыши и выберем пункт «ЦП при загрузке». Это добавит дополнительный столбец, который покажет время в миллисекундах, влияющее на систему.

Если у вас есть программы, время которых равняется 500 мс и выше, например, около 1000, что равняется одной секунде, то желательно их отключить.

Долгая загрузка Windows прочие варианты решения проблемы

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

На этом всё, если есть вопросы или дополнительные рекомендации, то пишите об этом в комментариях.

Как ускорить нетбук
3 совета по ускорению загрузки Windows 7 и 8
10 способов увеличить производительность компьютера

5 способов исправить Windows File Explorer, когда он работает медленно

Автор Модиша Тлади

Обновлено 10 мая 2022 г.

File Explorer удобен, но не тогда, когда он работает медленно. Вот как это исправить.

Проводник Windows — отличный инструмент, но у него есть и свои недостатки. Например, эта программа часто медленно отвечает, когда вы используете ее для открытия или копирования файлов. Иногда панель поиска File Explorer загружает результаты поиска слишком долго.

Если этот инструмент вызывает у вас проблемы, вы, вероятно, задаетесь вопросом: «Почему мой File Explorer такой медленный?»

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

1. Перезапустите Проводник

Перезапуск Проводника может помочь решить проблему «Проводник Windows работает медленно». Чтобы начать, выполните следующие простые шаги:

1. Щелкните правой кнопкой мыши на панель задач и выберите Диспетчер задач из вариантов.
2. Наконец, щелкните правой кнопкой мыши параметр Проводник Windows и выберите Перезапустить .

Если проблема не устранена, закройте проводник с помощью диспетчера задач, а затем снова откройте его вручную.

Для этого откройте диспетчер задач в соответствии с предыдущими шагами. Оттуда щелкните правой кнопкой мыши Проводник Windows и выберите Завершить задачу . Наконец, откройте проводник вручную и проверьте, решена ли проблема.

2. Минимизируйте количество активных программ ПК

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

Чтобы решить проблему «Проводник загружается медленно», попробуйте свести к минимуму количество программ, запущенных на вашем ПК.

1. Чтобы начать работу, откройте Диспетчер задач, нажав Ctrl + Shift + Esc .
2. Перейдите на вкладку Процессы .
3. В разделе Приложения щелкните правой кнопкой мыши конкретную программу и выберите Завершить задачу . Повторите это для всех программ, которые вы хотите закрыть.

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

3. Отключить быстрый доступ и очистить историю проводника

Быстрый доступ — одна из лучших функций Проводника. Когда вы открываете проводник, ваши недавно использованные файлы и папки будут отображаться в разделе «Быстрый доступ». Хотя эта функция помогает вам быстро получить доступ к вашим файлам, она также может замедлить работу Проводника.

Итак, чтобы ускорить проводник, отключите быстрый доступ, выполнив следующие действия:

1. Откройте File Explorer и выберите параметр File в верхнем левом углу экрана.
2. Выберите Изменить папку и параметры поиска .
3. В следующем окне перейдите на вкладку Общие .
4. Нажмите раскрывающееся меню Открыть проводник на и выберите Этот компьютер .
5. Далее снимите флажок Показать недавно использованные файлы в Быстром доступе и параметры Показать часто используемые папки в Быстром доступе .
6. Теперь нажмите кнопку Очистить под параметрами Конфиденциальность . Это должно очистить историю File Explorer.
7. Нажмите Применить , а затем нажмите OK , чтобы применить эти изменения.

Наконец, перезагрузите компьютер, чтобы применить эти изменения.

4. Настройка параметров оптимизации папки

Возникла ли эта проблема с папкой, содержащей множество файлов и вложенных папок? Если это так, оптимизация этой папки может помочь.

Итак, вот как вы можете оптимизировать свою папку для решения проблемы «Проводник Windows 10 работает медленно»:

1. Щелкните правой кнопкой мыши проблемную папку и выберите Свойства .
2. Перейдите на вкладку Настроить .
3. Щелкните раскрывающееся меню Оптимизировать эту папку для и выберите Общие позиции .
4. Установите флажок Также примените этот шаблон ко всем вложенным папкам .
5. Наконец, нажмите Применить , а затем нажмите
   OK , чтобы применить эти изменения.

5. Устранение неполадок службы поиска и индексирования Windows

Если ни одно из решений до сих пор не сработало, вы, вероятно, беспокоитесь и до сих пор задаетесь вопросом: «Почему файловый менеджер работает так медленно?» Но у нас есть еще одно решение для вас!

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

Служба поиска и индексирования Windows помогает повысить производительность поиска на вашем ПК. Однако File Explorer и его панель поиска могут работать медленно, если у службы поиска и индексирования есть проблемы.

Итак, чтобы решить проблему, устраните неполадки службы поиска и индексирования, выполнив следующие действия:

1. Введите Панель управления в строке поиска Windows и выберите Наилучшее соответствие
   .
2. Выберите Маленькие значки в Просмотр по раскрывающемуся меню .
3. Оттуда выберите Параметры индексирования .
4. В следующем окне выберите Устранение неполадок поиска и индексации .
5. Затем установите флажок Поиск или индексирование замедляет работу компьютера .
6. Наконец, нажмите Далее , чтобы завершить процесс.

Ускорьте Проводник с легкостью

Очень расстраивает, когда File Explorer загружается вечно. На самом деле, это делает управление вашими файлами и работу с ними неприятным опытом. Надеюсь, вы сможете решить проблему «Проводник Windows работает медленно», используя наши советы.

Git Bash работает очень медленно в Windows 7 x64

Я использовал Git как в Windows, так и в Ubuntu во время разработки небольшого проекта, часто переключаясь между ними. Проблема в том, что Git Bash

постоянно становится медленным.

Когда я говорю медленно, я имею в виду, что запуск cd занимает от 8 до 25 секунд, выполнение команд git занимает от 5 до 20 секунд, а ls иногда может занимать до 30 секунд. Излишне говорить, что это не весело, не говоря уже о непродуктивно. Я знаю, что Git работает медленнее в Windows, но это смешно.

Единственное решение, которое сработало — временно — для меня, состояло в том, чтобы отключить сетевое подключение (как предлагается в этом ответе), запустить Git Bash, а затем снова подключиться. Иногда он продолжает работать быстро в течение нескольких дней после этого, но в конечном итоге производительность всегда ухудшается. Я неделями просматривал дискуссионную группу msysgit, Stack Overflow, список проблем msysgit и т. д., но не смог найти работающих решений.

Пока пробовал:

• Добавление папок Git и проекта в список исключений антивирусного сканера
• Полное отключение антивирусного сканера (Kaspersky IS 2011)
• Проверка того, что Outlook не запущен (Outlook 2007)
• Закрытие всех остальных приложений
• Запуск Git Bash от имени администратора
• Отключение сетевого подключения, запуск Git Bash и сохранение отключенного подключения
• Отключение сетевого подключения, запуск Git Bash, повторное включение подключения (работает только изредка)
• Работает git gc
• И комбинации вышеуказанных

Я читал, что нескольким людям удалось отключить завершение Bash, но в идеале я хотел бы оставить это активным. Версия msysgit — 1.7.3.1-preview20101002, а ОС — Windows 7 x64. Запуск одних и тех же вещей в Linux, как и ожидалось, происходит молниеносно. Я бы использовал исключительно Linux, но мне нужно запускать некоторые вещи и в Windows (определенные приложения, тестирование и т. д.).

Кто-нибудь сталкивался с подобной проблемой? Если да, то в чем заключалась основная проблема и каково было решение (если оно было)?

Это касается не только репозиториев Git, но просто для справки: репозитории, с которыми я использовал Git, были довольно маленькими: максимум ~4-50 файлов.

• git
• bash
• windows-7
• msysgit
• mingw32

7

Вы можете значительно ускорить Git в Windows, выполнив три команды для установки некоторых параметров конфигурации:

 git config --global core.preloadindex true
git config --global core.fscache верно
git config --global gc.auto 256
 

Примечания:

• core.

  preloadindex выполняет операции файловой системы параллельно, чтобы скрыть задержку (обновление: включено по умолчанию в Git 2.1)

• core.fscache устраняет проблемы с UAC, поэтому вам не нужно запускать Git от имени администратора (обновление: включено по умолчанию в Git для Windows 2.8)

• gc.auto минимизирует количество файлов в .git/

7

Отображается ли информация Git в командной строке Bash? Если это так, возможно, вы непреднамеренно слишком много работаете над каждой командой. Чтобы проверить эту теорию, попробуйте следующее временное изменение в Bash:

 export PS1='$'
 

18

Мой домашний каталог Windows находится в сети, и я подозревал, что команды Git Bash сначала искали его. Конечно же, когда я посмотрел на $PATH , он указал /h/bin , где /h — это общий ресурс на файловом сервере Windows, хотя /h/bin не существует.
Я отредактировал /etc/profile и закомментировал команду экспорта, которая ставит ее на первое место в $PATH :

 #export PATH="$HOME/bin:$PATH"
 

Это заставило мои команды выполняться намного быстрее, вероятно, потому, что Git Bash больше не ищет исполняемые файлы по сети. Мой /etc/profile был c:\Program Files (x86)\Git\etc\profile .

8

Я обнаружил, что проблема с производительностью связана с сетевым диском. HOME указывал на медленную сетевую папку. Я не мог переопределить HOMEDRIVE , но, судя по тому, что я видел, это не проблема.

Установите переменную среды, щелкнув правой кнопкой мыши ваш компьютер на рабочем столе —> свойства —> Дополнительные параметры системы —> Переменные среды Добавить в раздел пользовательских переменных

9\* \(.*\)/ [\1] / p’)» } PS1=’\[\033]0;$MSYSTEM:\w\007 \033[32m\]\u@\h \[\033[33m\w$(fast_git_ps1)\033[0m\] $ ‘

Это сохраняет преимущество цветной оболочки и отображения имени текущей ветки (если в репозитории Git), но на моей машине это происходит значительно быстрее, с ~ 0,75 с до 0,1 с.

Это основано на этом сообщении в блоге.

4

Хотя ваша проблема может быть связана с сетью, я лично ускорил свой локальный git status вызывается в десять раз (с 7+ секунд до 700 мс), выполнив две модификации. Это репозиторий размером 700 МБ с 21 000 файлов и чрезмерным количеством больших двоичных файлов.

Один из них включает предварительную загрузку параллельных индексов. Из командной строки:

git config core.preloadindex true
Это изменило time git status с 7 секунд до 2,5 секунд.

Обновление!

Следующее больше не нужно. Патч исправил это с mysysgit 1.9..4
https://github.com/msysgit/git/commit/64d63240762df22e92b287b145d75a0d68a66988
Однако вы должны включить исправление, введя
git config core.fscache true

Я также отключил UAC и драйвер «luafv» (требуется перезагрузка). Это отключает драйвер в Windows Vista, 7 и 8, который перенаправляет программы, пытающиеся выполнить запись, в системные папки, а вместо этого перенаправляет их доступ к пользовательскому каталогу.

Чтобы увидеть обсуждение того, как это влияет на производительность Git, прочитайте здесь: https://code.google.com/p/msysgit/issues/detail?id=320

Чтобы отключить этот драйвер, в regedit измените ключ «Пуск» в HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/luafv на 4, чтобы отключить драйвер. Затем установите UAC на самое низкое значение «никогда не уведомлять».

Если отключение этого драйвера вызывает у вас опасения (так и должно быть), альтернатива выполняется на диске (или разделе), отличном от вашего системного раздела. По-видимому, драйвер работает только при доступе к файлу в системном разделе. У меня есть второй жесткий диск, и я вижу одинаковые результаты при запуске с этой модификацией реестра на диске C и без нее на диске D.

Это изменение занимает времени git status с 2,5 секунд до 0,7 секунд.

Вы также можете подписаться на https://github.com/msysgit/git/pull/94 и https://github.com/git/git/commit/d637d1b9a8fb765a8542e69bd2e04b3e229f663b, чтобы узнать, какая дополнительная работа ведется для решения проблем со скоростью. в Windows.

4

Похоже, что полное удаление Git, перезагрузка (классическое лечение Windows) и переустановка Git были лекарством. Я также стер все оставшиеся файлы конфигурации bash (они были созданы вручную). Все снова быстро.

Если по какой-то причине переустановка невозможна (или нежелательна), то я обязательно попробую изменить переменную PS1, указанную в ответе Криса Долана; это привело к значительному ускорению некоторых операций.

9

Я решил проблему с медленной работой Git в Windows 7 x64, запустив cmd.exe с параметром «Запуск от имени администратора».

6

Вы также можете значительно повысить производительность, изменив следующую конфигурацию Git:

 git config --global status. submoduleSummary false
 

При выполнении простой команды git status в Window 7 x64 моему компьютеру потребовалось более 30 секунд для запуска. После определения этой опции команда выполняется немедленно.

Активация собственной трассировки Git, как описано на следующей странице, помогла мне найти причину проблемы, которая может отличаться в вашей установке: https://github.com/msysgit/msysgit/wiki/Diagnosing-why-Git-is-so-slow

Я увидел приличное улучшение, установив для core.preloadindex значение true, как рекомендуется здесь.

Как отмечено в ответах Криса Долана и Уилберта, PS1 замедляет работу .

Вместо полного отключения (как предложил Долан) или использования сценария, предложенного Уилбертом, я использую «тупую PS1», которая намного быстрее.

Используется (git symbolic-ref -q HEAD || git rev-parse --short HEAD) 2> /dev/null :

 PS1='\033[33m\]\w \n\[\ 033[32m\]$((git symbolic-ref -q HEAD || git rev-parse -q --short HEAD) 2> /dev/null) \[\033[00m\]# '
 

На моем Cygwin это быстрее, чем ответ Уилберта «fast_Git_PS1» — 200 мс против 400 мс, поэтому он немного снижает вашу медлительность.

Он не такой сложный, как __git_ps1 — например, он не меняет подсказку, когда вы переходите в каталог .git и т. д., но для обычного повседневного использования он достаточно хорош и быстр.

Это было протестировано на Git 1.7.9 (Cygwin, но должно работать на любой платформе).

4

В дополнение к этим другим ответам я ускорил проекты с несколькими подмодулями, используя параллельную выборку подмодулей (начиная с Git 2.8 в начале 2016 года).

Это можно сделать с помощью git fetch --recurse-submodules -j8 и установить с помощью git config --global submodule.fetchJobs 8 или сколько ядер у вас есть/хотите использовать.

Мне помогло только отключение AMD Radeon Graphics (или Intel Graphics) в диспетчере устройств.

Я нашел ответ здесь: https://superuser.com/questions/1160349/git-is-extremely-slow-on-windows# =

У меня была одна и та же проблема как в Git Bash, так и в Git GUI. Обе программы раньше работали хорошо, но затем они случайно замедлились до ползания, и я не мог понять, почему.

Как оказалось, это был Avast. Avast вызывал странные вещи, происходящие с различными программами (включая программы, которые я пишу), поэтому я отключил его на секунду, и, конечно же, Bash теперь работает так же быстро, как и в Linux. Я только что добавил папку с программными файлами Git ( C:\Program Files\Git ) в список исключений Avast, и теперь он работает так же быстро, как и в Linux.

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

Комбинированные ответы:

1. Уилберт — какую информацию включить в PS1
2. sinelaw’s — () или ()

 #
# https://unix.stackexchange.com/questions/124407/what-color-codes-can-i-use-in-my-ps1-prompt
# \033 совпадает с \e
# 0;32 равно 32
ГОЛУБОЙ = "$(echo -e "\e[1;36m")"
ЗЕЛЕНЫЙ="$(echo -e "\e[32m")"
ЖЕЛТЫЙ = "$(echo -e "\e[33m")"
СБРОС = "$ (эхо -e "\ e [0m")"
# https://stackoverflow. com/questions/4485059/git-bash-очень-медленно-в-Windows-7-x64/19500237#19500237
# https://stackoverflow.com/questions/4485059/git-bash-is-extremely-slow-in-windows-7-x64/13476961#13476961
# https://stackoverflow.com/questions/39518124/check-if-directory-is-git-repository-without-having-to-cd-into-it/39518382#39518382
fast_git_ps1 ()
{
    гит -С . rev-parse 2>/dev/null && echo " ($((git symbolic-ref --short -q HEAD || git rev-parse -q --short HEAD) 2> /dev/null))"
}
# вам нужно \] в конце для цветов
# Не устанавливайте \[ в начале, иначе ctrl+up для истории будет работать странно
PS1='${ЗЕЛЕНЫЙ}\u@\h ${ЖЕЛТЫЙ}\w${ГОЛУБОЙ}$(fast_git_ps1)${СБРОС}\] $ '
 

Результат:

2

В моем случае ярлык Git Bash был установлен на Start in:%HOMEDRIVE%%HOMEPATH% (это можно проверить, щелкнув правой кнопкой мыши Git Bash и выбрав свойства). Это был сетевой диск.

Решение состоит в том, чтобы указать на %HOME% . Если у вас его нет, вы можете настроить его в переменных среды, и теперь Git Bash должен работать молниеносно.

1

Я столкнулся с той же проблемой при запуске Git для Windows (msysgit) в Windows 7 x64 в качестве ограниченной учетной записи пользователя в течение достаточно долгого времени.

Судя по тому, что я читал здесь и в других местах, общей темой является отсутствие административных привилегий и/или UAC. Поскольку UAC отключен в моей системе, объяснение, что он пытается что-то записать/удалить в каталоге программных файлов, имеет для меня наибольший смысл.

В любом случае, я решил свою проблему, установив переносную версию Git 1.8 с помощью zipinstaller. Обратите внимание, что мне пришлось распаковать файл дистрибутива .7z и перепаковать его как ZIP-файл, чтобы zipinstaller заработал. Мне также пришлось вручную добавить этот каталог в системный путь.

Теперь производительность в порядке. Несмотря на то, что он установлен в каталоге Program Files (x86) , для которого у меня нет разрешений как у пользователя с ограниченными правами, похоже, он не страдает от той же проблемы.

Я связываю это либо с тем, что портативная версия немного более консервативна в том, где она записывает/удаляет файлы, что, вероятно, так и есть, либо с обновлением с 1.7 до 1.8. Я не буду пытаться определить, в чем причина, достаточно сказать, что теперь он работает намного лучше, включая Bash.

2

В моем случае на самом деле это был антивирус Avast, который привел к тому, что Git Bash и даже PowerShell стали очень медленными.

Сначала я попытался отключить Avast на 10 минут, чтобы посмотреть, улучшится ли скорость, и это произошло. После этого я добавил весь каталог установки Git Bash в качестве исключения в Avast для чтения, записи и выполнения. В моем случае это было C:\Program Files\Git\* .

4

Если вы используете Git из cmd, попробуйте запустить его из Git Bash. В cmd git.exe на самом деле является оболочкой, которая настраивает правильную среду каждый раз, когда вы ее запускаете, и только потом запускает настоящий git.exe. Это может занять в два раза больше времени, чем требуется, чтобы просто сделать то, что вы хотите. А Git Bash настраивает окружение только при запуске.

У моего коллеги были проблемы с Git в Windows (7) git status checkout и add были быстрыми, но git commit занял целую вечность.

Мы все еще пытаемся найти основную причину этого, но клонирование репозитория в новую папку решило его проблему.

Как многие говорили, это связано с тем, что stash является сценарием оболочки в Windows, но, начиная с Git 2.18.0, установщик Windows имеет возможность экспериментальной функции гораздо более быстрой (~ 90%) встроенной версии тайник — https://github. com/git-for-windows/build-extra/pull/203.

3

У меня была похожая ситуация, и моя проблема была связана с Active Directory и использованием VPN.

Поработав так полгода нашел это золото: http://bjg.io/guide/cygwin-ad/

Все, что вам в принципе нужно, это отключить db в /etc/nsswitch.conf ( вы можете найти его в вашем каталоге git) из раздела passwd и group , поэтому файл выглядит так:

 # Начало /etc/nsswitch.conf
пароль: файлы
группа: файлы
db_enum: встроенный кеш
db_home: описание cygwin
db_shell: описание cygwin
db_gecos: описание cygwin
# Конец /etc/nsswitch.conf
 

, а затем один раз обновите локальный пароль и настройки группы:

 $ mkpasswd -l -c > /etc/passwd
$ mkgroup -l -c > /etc/группа
 

Ничего из перечисленного мне не помогло. В моем сценарии проблема проявлялась так:

• Любая команда ls -l выполнялась медленно (выполнение занимало около 3 секунд)
• Любая последующая ls -l команда выполнялась мгновенно, но только если в течение 45 секунд после предыдущей лс команда.

При отладке с помощью Process Monitor обнаружилось, что перед каждой командой был DNS-запрос.

Итак, как только я отключил брандмауэр (в моем случае Comodo) и позволил выполнить команду, проблема исчезла. И он не возвращается обратно при повторном включении брандмауэра. При первой возможности я обновлю этот ответ более подробной информацией о том, какой процесс выполнял блокирующий DNS-запрос и что было целью.

0

У меня также была проблема с медлительностью git PS1, хотя я долгое время думал, что это проблема размера базы данных (большой репозиторий), пробовал различные трюки git gc и искал другие причины, как и вы. Однако в моем случае проблема заключалась в этой строке:

 function ps1_gitify
{
   status=$(git status 2>/dev/null ) # <--------------------
   if [[ $status =~ "фатальный: не репозиторий git" ]]
   затем
       эхо ""
   еще
       эхо "$(ps1_git_branch_name) $(ps1_git_get_sha)"
  фи
}
 

Выполнение git status для каждой строки состояния командной строки было медленным.