Ошибка, вынесенная в заголовок, может встречаться в Ubuntu версий от 8.04 и выше.

Скорее всего она проявит себя, если юзер захочет монтировать ntfs диски автоматически при загрузке системы и без ввода пароля рута. Небольшое редактирование fstab или расстановка галочек в визуальном инструменте и ... вуаля — диски монтируются автоматически. Однако есть частые проблемные последствия: диски вдруг стали странным образом дублироваться в главном меню, причем при попытке перехода на дубли возникает ошибка, а система при попытка удаления файлов на ntfs дисках выдает ошибку: «Не удалось переместить файл в корзину, удалить его безвозвратно?».

С такой проблемой я сам столкнулся не так давно, решение любезно описал нам пользователь genrich с русскоязычного сообщества ubuntu:
  1. Открываем fstab:
    sudo nano /etc/fstab
    или
    sudo gedit /etc/fstab
  2. Видим там строки типа:
    UUID=**************** /****/**** ntfs defaults 0 0
    в принципе, после «... defaults» может через запятую тащиться еще вереница параметров, для нас это не важно.
  3. Заменяем все, стоящее справа от «... ntfs» на:
    «defaults,umask=007,gid=46,uid=1000 0 0»
  4. Получаем в итоге строки типа:
    UUID=**************** /****/**** ntfs defaults,umask=007,gid=46,uid=1000 0 0
  5. Перемонтируем диски или перезагрузим ubuntu для проверки результата.
Это решение помогло лично мне — я избавился от дублей ntfs дисков и файлы стали нормально перемещаться в корзину.

WordpressПочти все мои сайты работают на самописных движках, но до недавнего времени один из них все еще сидел на столь распространенном сейчас wordpress. Дело в том, что изначально wordpress был установлен из-за удобства освоения админки человеком ведущим этот сайт (не мной). Но после выхода линейки версий 2.8 я понял, что это уже не дело…

Нагрузка на хостинг увеличилась значительно, при количестве хитов положим 500—600 wordpress уже превышал лимиты на использование ресурсов MySQL в три раза, а значит выход стоял либо в кеше (довольно геморном опять же в wordpress), либо в переходе на другой движок.

Я испробовал на локали большинство готовых блоговых движков и пришел к неутешительному выводу:
ни один из них (!) даже при наличии импорта из wordpress, не мог предоставить той же структуры ЧПУ (и уж тем более в автоматическом, интуитивном режиме), а это значит при переходе -> 301 редирект и непонятно какая реакция со стороны ПС в плане существующих позиций.

В итоге получилось как всегда: посмотрел сорцы wordpress, импортнул данные из существующей БД, написал небольшое подобие CMS.

Нагрузка: на MySQL снизилась в среднем в 10 раз, на проц — в 2 раза. Думается мне, что здесь есть еще где развернуться в плане оптимизации, но согласитесь даже это уже показательный результат!

Вывод из данного поста совсем не в том, чтобы всем ринуться срочно писать свои скрипты (подумайте хотя бы о защите от взлома), а в том, чтобы пару раз подумать прежде чем ставить wordpress в качестве блог-движка, ведь потом может быть проблематично сменить ЧПУ и уж тем более адреса существующих ссылок (если они, конечно, не покупные).


Категории