Папка Upload как ее чистить?

Вопрос

#31 1 февраля 2018 в 09:44
Уже нашел программку: Remove Empty Directories
Бесплатная НО интересная.
#32 1 февраля 2018 в 10:07

определить пустые папки

MegaRostov
пустые в двойке не создаются… а вот ситуация что папка, в ней папка, а в ней одна картинка реальны и часты… К сожалению.
#33 1 февраля 2018 в 10:11
Zau4man,

пустые в двойке не создаются

Полностью с вами не согласен!
Создаются еще как. У меня уже выявлено более 10000 из 146000 и это еще не придел.
Пока что только скачиваю на комп папку upload…
#34 1 февраля 2018 в 10:23

пустые в двойке не создаются.

Zau4man

создаются
#35 1 февраля 2018 в 10:26
Еще обнаружил такую вещь..
У меня установлен InstantMaps я импортировал объекты более 120000 и со временем их удали полностью все.
Так вот в папке upload формируются все мои импортированные объекты в .csv

И их тоже огромное количество как удалить их из папки upload они как раз и занимают больше всех места.

Ответ с моего хостинга:

Здравствуйте!

При подсчете количества файлов Unix подобные системы так же учитывают и пустые папки.

На текущий момент на Вашем аккаунте следующее количество файлов:
===
find | wc -l
528635
===

Так что нужно решать что делать с пустыми папками и как это все после удаления новостей. статей, объявлений, объектов InstantMaps, постов, фотографий так же удалять…
#36 1 февраля 2018 в 12:15
Поскольку тему Пустые папки после удаления картинок Fuze закрыл, отвечаю тут.

Пожалуйста, не делайте выводы в том, в чем не разбираетесь

Fuze

Насколько я вижу по коду и структуре папок, сейчас механизм такой. При сохранении файла на сайт в каждой пользовательской директории создаются папка с подпапкой. Учитывая, что вариантов имён для каждой папки может быть 256 и что эти две папки вложены, получаем максимальное количество конечных папок (где и хранятся файлы) в папке каждого пользователя — 65536. Имена папок при сохранении выбираются случайно. Таким образом, по теории вероятности, получаем, что скорее всего сохранённый файл будет ложиться в свою новую пару папка-подпапка. И только по мере приближения к 65 тысячам сохранённых этим пользователем файлов, новые файлы постепенно могут попадать в уже существующие папки. И так для каждого отдельного пользователя.

Эта система папок может оказаться удачной только в случае импорта большого количества файлов, в несколько сот тысяч штук.
На обычных проектах, где файлы создаются пользователями, имеем картину, которую я описал в похожей теме — на каждый файл приходится по 1.84 папки. И только по мере заполнения сайта эта цифра будет медленно снижаться. То есть, в данный момент на этом проекте пользователи сохранили, к примеру, 1000 картинок, а папок при этом создалось 1840. Это цифра соотношения файлов/папок с реального проекта, это не какие-то мои теоретические фантазии.

Для сравнения, например, если создавать новые папки последовательно по мере заполнения предыдущей и хранить в каждой папке не более 100 файлов, то получаем на каждую 1000 сохранённых файлов всего 10 папок. 1840 и 10 — разница существенная!

Казалось бы, в чём проблема, пусть себе папки хранятся, сейчас диски дешёвые. Но проблема есть, и не одна.
1. Такими папками забивается таблица файлов на диске. Это приводит к её разбуханию, требует больше памяти для работы с ней, замедляет её обработку. Если файлов 1000 — это не заметно. А если на каждые 100 тысяч файлов создаётся хотя бы по 1 папке, то это бестолково увеличивает таблицу файлов в 2 раза.
2. Проверять на вирусы и делать бекапы таких структур действительно становится накладно. Одно дело, когда проверил 100 папок по 100 файлов. Другое, когда проверяешь 10 тысяч файлов, разложенных по 10 тысячам папок. Тут хостеров, предлагающих недорогие тарифы, можно понять — время сканирования таких папок сильно увеличивается.
3. Синхронизация таких папок по ФТП или другим подобным образом становится ооочень долгой, так как приходится открывать каждую такую папочку ради одного или нескольких файлов. И в какой-то момент вместо того, чтобы забирать только несколько десятков новых файлов за день, придётся делать бекап всей папки upload в архив и вытягивать его целиком. Это и лишнее время, и лишний трафик.

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

Если я действительно чего-то сильно не понимаю, тогда прошу знающих людей объяснить механизм сохранения и причины создания кучи папок.
#37 1 февраля 2018 в 12:51
Я конечно в этом плане туп, но структуру какую то хотелось бы иметь, например:
upload/c_type/date/item_id/presets/
что в жизни выглядело бы так:
upload/news/01022018/3/big/file_name.jpg

Или подобные вариации
upload/date/c_type/id/presets/

Это так… между умными словами свое вставил)
#38 1 февраля 2018 в 12:59
Что архитектор поменяет своё решение — это навряд ли.
Но, возможно, он пояснит это решение, чтобы снять вопрос.
#39 1 февраля 2018 в 13:41

Я конечно в этом плане туп, но структуру какую то хотелось бы иметь, например:
upload/c_type/date/item_id/presets/
что в жизни выглядело бы так:
upload/news/01022018/3/big/file_name.jpg

Или подобные вариации
upload/date/c_type/id/presets/

Jestik

Пресеты генерироваться должны просто исходя из размера. Например nazvanie-450x450.png и всё. Папки удобнее всего когда генерируются по дате. 1 папка года, 12 папок месяца, 365 папок дней. Даже если пресеты сделать папки то появятся максимум еще 5-6 штук, но лучше добавлять размер к названию.

Названия файлов надо иметь возможность переименовывать, забирая либо указанное название, либо вставляя какую то часть символов названия материала. Это и для seo хорошо и для организации сайта.
#40 1 февраля 2018 в 13:44

2. Проверять на вирусы и делать бекапы таких структур действительно становится накладно. Одно дело, когда проверил 100 папок по 100 файлов. Другое, когда проверяешь 10 тысяч файлов, разложенных по 10 тысячам папок. Тут хостеров, предлагающих недорогие тарифы, можно понять — время сканирования таких папок сильно увеличивается.
3. Синхронизация таких папок по ФТП или другим подобным образом становится ооочень долгой, так как приходится открывать каждую такую папочку ради одного или нескольких файлов. И в какой-то момент вместо того, чтобы забирать только несколько десятков новых файлов за день, придётся делать бекап всей папки upload в архив и вытягивать его целиком. Это и лишнее время, и лишний трафик.

WebMan

Точно, с этим согласен +++, прогнал прогой Remove Empty Directories у меня в папке upload 6029 пустых папок —
#41 1 февраля 2018 в 14:13
Сделал автоматический пустыхпапокавтоудалятель.
Кому мешают пустые папки — пройдите сюда.
#42 1 февраля 2018 в 14:21
"Ты суслика видишь?… А он есть..."
Проблема есть. Её нужно решать. Лучше — в самом движке. Как вариант — решать индивидуально.

Один из простых и универсальных способов — дать админам возможность выбора варианта структуры папок. Для этого в минимальном варианте нужно добавить хук в getUploadDestinationDirectory() и при его вызове не создавать стандартные папки.

В расширенном варианте можно сделать в настройках сайта выпадающий список вариантов. Генерацию пути вынести во внешние файлы в какой-то папке движка и в список в Админке собирать имена этих файлов. Так любой желающий может написать себе свою функцию генерации имени папки файла и потом просто выбрать свой файл из списка в Админке. А уже эти пути создавать хоть по датам, хоть по типам контента — кому как надо. Также можно будет выложить такой файл с функцией генерации пути на форум для общего пользования.
#43 1 февраля 2018 в 14:38

Проблема есть. Её нужно решать. Лучше — в самом движке.

WebMan
Проблемы нет. Решать нечего.

1. Такими папками забивается таблица файлов на диске. Это приводит к её разбуханию, требует больше памяти для работы с ней, замедляет её обработку. Если файлов 1000 — это не заметно. А если на каждые 100 тысяч файлов создаётся хотя бы по 1 папке, то это бестолково увеличивает таблицу файлов в 2 раза.

WebMan
Дальше читать не стал. Я надеюсь, на этом форуме есть люди, которые понимают степень абсурда процитированного.

И так все остальные аргументы.

Ris, жму руку.


За сим, не буду больше мешать этой милой теме smile
#44 1 февраля 2018 в 14:59

Точно, с этим согласен +++, прогнал прогой Remove Empty Directories у меня в папке upload 6029 пустых папок

Андрей
Даже не знаю что и сказать… тоже просканировал прогой Remove Empty Directories и у меня в папке upload нашлось всего 320 пустых папок из 8514
Конечно, папок могло быть поменьше....
Новостной сайт, под Инстантом 2 версии 2,5 года!
Из них 1 год и 3 месяца ежедневно работает парсер UPDS, добавляю в среднем 35-40 новостей, не считая прочего контента!
Основной редактор TinyMCE/
Как то так! Проблем с хостингом по количеству папок никогда не имел даже на РНР хостинге.
#45 1 февраля 2018 в 15:19

Дальше читать не стал. Я надеюсь, на этом форуме есть люди, которые понимают степень абсурда процитированного.

Fuze
Я, конечно, не спец в Юних-подобных системах, я занимаюсь виндовыми серверами и сетями. Но у каждой файловой системы есть специальное место, где хранится информация о её объектах. У Винды это FAT или MFT. У линуксовых систем — своя структура inode. Википедия про inode: "В этой структуре хранится метаинформация о стандартных файлах, каталогах или других объектах файловой системы, кроме непосредственно данных и имени". "Файловые системы, не относящиеся к традиционным ФС UNIX, такие как ReiserFS, могут обходиться без таблицы индексных дескрипторов, но должны хранить аналогичную информацию схожим способом, обеспечивающим эквивалентную функциональность."

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

И так все остальные аргументы.

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