pokerfrog

Внезапно обнаруживаю, что мой замечательный (кто посмеет сказать что нет?) favicon.ico превратился в какое-то радужное говно. Так и выяснилось, что бинарные файлы в gulp надо обрабатывать как-то по-особенному. То ли опции где-то задавать, то ли плагин специальный искать.

Блядь, и ведь такое ощущение, что эта ошибка только у меня и никто больше о ней не знает

… и не удивительно. Я нашел мерзавца. Это gulp-jsrefs, который, сука, должен был только скриптики менять. Которых в favico нет по определению, и быть не может. Но он между делом что-то там нашел и переделал под себя.  Шлю лучи поноса китайскому товарищу, который его написал. Или корейскому? Или японскому? Да мне в общем без разницы.

Придется выделить отдельно копирование  php через gulp-jsrefs, отдельно копирование всякой всячины.

Итак, запущен локальный Google AppEngine сервер, на нем крутится простой скриптик, который получив POST-запрос по адесу localhost/name, должен создать файлик name.txt. Ну то есть как простой, он уже много чего умеет, но конкретно сейчас я вдруг обнаружил некоторые проблемы именнос этой частью.

Пишем localhost:8080/%D0%BF%D1%83%D1%88-%D0%BA%D0%BE%D0%BB%D0%BB%20%D0%A1%D0%BA%D0%BB%D0%B0%D0%BD%D1%81%D0%BA%D0%B8-%D0%A7 – все зашибись, файлик создается

Пишем localhost:8080/%D0%BF%D1%83%D1%88-%D0%BA%D0%BE%D0%BB%D0%BB%20%D0%A1%D0%BA%D0%BB%D0%B0%D0%BD%D1%81%D0%BA%D0%B8-%D0%A7%D1%83 – получаем хуй в рот и сообщение:

Warning: Cloud Storage Error: INTERNAL SERVER ERROR in C:\Program Files (x86)\Google\Cloud SDK\google-cloud-sdk\platform\google_appengine\php\sdk\google\appengine\ext\cloud_storage_streams\CloudStorageWriteClient.php on line 265

Сидим, причмокиваем. Причем на рабочем сервере все по прежнему зашибись!

Пишем localhost:8080/1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111 и понимаем, что, например, русские буковки тут не причем, просто мы уперлись в ограничение длины полного имени файла. У нас конечно в имени символов явно меньше, ну так файлик же не в вакууме висит, а лежит где-то во глубине сибирских руд в хуй знает какого уровня вложенности папке. И вот полное имя этого ценного ресурса вылезло за пределы.

И что теперь с этим делать? Я не могу поднять локальную копию своего сервиса, а при особо удачном стечении обстоятельств не смогу сделать даже бэкап – ну попадется мне, допустим, пользователь который любит делать длинные имена страниц, благо движок сайта позволяет не скромничать. Даже случайно может получиться – забыл в вики разметке закрыть ссылку, а она возьми и найди закрывающую скобочку у другой, на 10 Кб текста ниже – и здравствуй жопа, новый год.

Проверка разумности длины ссылки конечно не помешает, но не сильно поможет.

Можно заменить длинные имена хэшами с фиксированной длиной. Но блиин… теперь надо как-то сконвертировать те файлы, что уже есть

P.S. Глаза боятся – руки делают. Слегка модифицированный скрипт для бэкапа прекрасно справился с задачей – считал старые файлы и сохранил их под новыми именами. Потом осталось загрузить их обратно и поправить один модуль отвечающий за работу с файлами данных.

P.P.S. Интересно, при каком количестве файлов в папке это станет новой проблемой? Надеюсь я к тому времени буду уже на пенсии уже перейду на нормальный хостинг и затолкаю всё в БД.