wisgest

https://qna.habr.com/help/rules

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

Скорее всего жаловаться надо

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

Ты не файл удаляешь, а только его имя из каталога. Файл остаётся до тех пор, пока не будет закрыт последний дескриптор указывающий на него. Все процессы открывшие файл до удаления его имени будут иметь к нему доступ до тех пор. В этом можно убедиться заглянув в /proc/<pid>/fd твоего процесса.

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

Очень часто, в логах сервера, в user-agent можно встретить selenium. Достаточно в конфиг прописать правило отклонения запросов с user-agent: (*selenium*) и проблема исчезает.

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

Обходить это, можно загружая страницу через браузер и случайно сдвигать мышь, случайное количество раз (от 5-10), через случайные промежутки. Спасет от ручной проверки, для большинства сайтов.

Для 100% гарантии, чтобы не банили, нужно "наводиться" на ссылки, которые нужно распарсить следующими (по очереди). Однако, в этом случае, вы пожертвуете производительностью парсера.

Как реализовать: Поднять сервис (несколько) на машине с vnc и получать страницу через браузер, имитируя работу мышкой.

Но, обычно, указать корректный user-agent достаточно. (Я, почему-то уверен, что вы остановитесь на этом варианте).

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

Владельцу сайта проще заблокировать тот ip, с которого сыпятся запросы, чем проводить оптимизацию кода сайта и выяснять, по какой причине вообще создалась нагрузка (например, из-за не проставленных индексов в бд).
А порой, это является единственным вариантом, т.к. на сервер, может прилететь за час свыше 10000 запросов к сайту с одного ip.
Для сравнения от yandex/google, за сутки, может прийти около 4000 запросов (с минимальными настройками индексации).

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

На Пайтоне, создаёт 1000 папок с именами dir1...dir1000:

import os

for i in range(1000):
	os.mkdir("dir{}".format(i+1))

Если хостинг бомжатский и ничего кроме PHP не предоставляет, то можно и на PHP:

for ($i = 1; $i <= 1000; $i++)
  mkdir('dir' . $i);

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

так у себя и держите что может быть проще

Оказывается, Апач при POST-запросе на URL папки без конечного слеша, перенаправляет на URL со слешем и при этом запрос трансформируется в GET. Если же слеш поставить, то эффект пропадает.

Вывод: В action формы ставьте всегда слеш в конце URL папки, а лучше используйте URL файла.
Получается такая схема
1. Мы посылаем POST на mysite/mydir
2. Сервер отвечает нам 301 на mysite/mydir/ (почему это правильно, описано в документации к Апачу)
3. Браузер делает GET без параметров на mysite/mydir/ (так и надо делать, это описано в RFC 2616)

В итоге мы вместо нашего POST с параметрами получаем GET без параметров. Все логично, но несколько неожиданно.