Комментарии 140
и что?
Кому вообще может понадобиться скачивать один и тот же файл 100+ раз
Ну а вдруг js-код на сайте зациклится и начнёт качать один и тот же файл...
Алло, это Балабановская спичечная фабрика? (с)
Например манагер скачивает отчёт по остаткам на складе раза 3-4 в день... И он чудесно называется report.zip)
Один и тот же может и мало кому, а вот скачивание каждый день файла с одним и тем же именем - довольно частый кейс.
Регулярно встречал у бухгалтеров в папке "Загрузки" длинный список банковских выгрузок kl_to_1c(XX).txt.
Один и тот же может и мало кому, а вот скачивание каждый день файла с одним и тем же именем - довольно частый кейс.
Или не каждый день, но из одного места. Это настолько частый случай, что непонятно, почему браузеры не стали раскладывать скачанное по папкам-датам, как многий софт для сканирования документов делает. (Или я отстал от жизни и где-то галочка есть?)
Мне кажется, такое поведение сильно не всегда будет удобно.
Например, открыв папку загрузок в проводнике практичнее видеть сразу имена/тип/превью/иконки файлов, нежели ничего не говорящие папки с датами. Даже если в имени папки помимо даты будет адрес сайта-источника, все равно попробуй еще вспомнить через месяц, откуда и когда именно ты качал понадобившийся тебе файл.
Мне кажется, такое поведение сильно не всегда будет удобно.
Тот случай, когда хорошо бы, чтобы возможность была предусмотрена в принципе, но была настраиваемой. Например, я бы, наверное, предпочел чтобы у меня каждый раз спрашивали - перезаписать, переименовать и оставить здесь же, или рассортировать по подпапкам по дате загрузки. Разумеется с возможностью выбрать любое из действий по умолчанию.
папки с датами
Можно предположить, что кто-то из разработчиков браузера догадается именовать папки по названию файла плюс дата, а не только дата. Тут, правда, очередная засада, потому что если папки сортируются по алфавиту, то только YYYY-MM-DD даст адекватную сортировку вместо довольно распространенного DD-MM-YYYY, а некоторые страны любят MM-DD-YYYY, и в этом есть своя логика, которая тоже не поддается обычной алфавитной сортировке, ведь имя папки это только текст.
а некоторые страны любят MM-DD-YYYY,
А почему, кстати, у них так?
Ну когда дата произносится как January 13th, 2025, - то записывать её тоже интуитивно понятно как 01-13-2025.
Сортировка файлов по имени становится осмысленной, например. Если сначала идет месяц, а не день.
Это осмыслено, когда год впереди месяца, а если год по-прежнему в конце, то сортировке это не особо помогает. У меня стандарт наименования документов в личном архиве - "YYYY MM DD Name", вот тут сортировка действительно удобна - можно смотреть хронологию именно по датам документов, а не датам файлов, которые иногда совершенно случайны.
Тогда год надо ставить в начало
А почему, кстати, у них так?
Насколько я знаю, это из глубоко доэлектронной эпохи, когда записи о чем угодно, да хоть бухгалтерские, велись в бумажных таблицах. На новый год часто начинался новый журнал - текущие записи велись в текущем году, а архивные искались в журналах за известный год, поэтому обозначение года было маловажным и попадало в самый дальний элемент даты, а то и вовсе пропускалось. Год же делился на месяцы, а месяцы на дни - типичный многоуровневый список, причем поскольку месяц был и остается отчетным периодом сам по себе или вложенным в год, то месяц, как более важная характеристика даты, оказывается в начале, а день, как подхарактеристика месяца, идет после месяца. Год, как мы выяснили, маловажен и, если вообще указывается, то указывается лишь в самом конце. За точность объяснения не поручусь, но логика совершенно очевидно просматривается.
Можно проще, в английском дата так и произносится "месяц день год", также как и в русском "день месяц год" (что, кстати, в детстве выносило мне мозг, почему русские произносят дату наоборот 😅).
Очень похоже на формат времени: час, минута, период. От важного к уточняющему.
Пример: 12:15 P.M.
От важного к уточняющему.
И тут же нарушили:
Пример: 12:15 P.M.
PM — это [которая] половина суток. Получается "час минута полсуток", тогда как "от важного к уточняющему" было бы "полсуток час минута"
А какая отсюда мораль? Используйте 24-часовое время, и будет вам ЩАСТЬЕ!
Полусутки (как и год в дате) чаще всего понятны из контекста. Если требуется уточнить, то добавляют.
Используйте 24-часовое время , и будет вам ЩАСТЬЕ!
В IT чаще всего используют 64 или 128 битный формат представления времени, там ЩАСТЬЕ.
А у людей в бытовой речи привычнее слышать "встретимся за ужином в 8" (или уточнят "в 8 вечера") даже на русском. В англоязычной среде 8 P.M. От важного к уточняющему.
PM — это [которая] половина суток.
Ну так это лишь уточнение того, что зачастую и так очевидно из контекста.
Контекст Вы тоже в базу данных записывать планируете?
Или вот Вы никогда не просыпались после вчерашнего в 6-7-8-9-10 часов (по часам) и в пасмурную погоду, и долго тупили, не понимая, утро сейчас или вечер?
Вы пропустили слово "зачастую" в моем комментарии.
Я так понимаю, парашют, который зачастую раскрывается, Вас тоже удовлетворит?
Статистически да. Лично для себя - не знаю, не пробовал, не имею мнения.
Статистически да.
Раз уж Вы начали упоминать всуе серъёзных дядей терминов, Вам придётся идти до конца и уточнить, что, в Вашем понимании, означает слово «зачастую». В числах.
В числах.
Более пятидесяти процентов, но менее ста процентов.
Более пятидесяти процентов, но менее ста процентов.
Ну то есть парашют, который раскрывается зачастую (в Ваших же терминах, я Вас за язык не тянул), Вас удовлетворит.
Если пользователь парашюта - вы, то безусловно да, удовлетворит. Я же не желаю вам несчастного случая или каких-то неприятностей, а если с вашим парашютом - который вы зачем-то привнесли в эту ветку комментариев, что-то пойдет не совсем так, как обычно предполагается при прыжках с парашютом, то вы вполне можете его сбросить и использовать запасной. Обычно так и делают - используют запасной парашют при невозможности использовать основной.
Если пользователь парашюта - вы, то безусловно да, удовлетворит.
Dogfooding? Не слышали!
использовать запасной.
А у него шансы такие же!
(Конечно, 75% немножко лучше, чем 50%...)
Разные источники дают разные цифры вероятности нераскрытия парашюта, но даже наиболее пессиместичные говорят о цифрах порядка 0.1% отказов или 99.9% успеха работы основного парашюта. Но, поскольку я не желаю вам несчастного случая, то меня вполне удовлетворяет даже такой пессиместичный сценарий, в котором с вероятностью один к тысяче вам понадобится запасной парашют. А заодно и в предложенные мною в ответ на ваш запрос границы надежно помещаемся - больше 50% и меньше 100%.
Но ведь в те же границы поместится и парашют с вероятностью 50,00000001%!
Но ведь в те же границы поместится и парашют с вероятностью 50,00000001%!
Товарищ ИИ, у вас проблемы с удержанием контекста. Напомню, что ваш (субъективно абсурдный, но все же формально приемлемый) тезис был таким:
Или вот Вы никогда не просыпались
после вчерашнегов 6-7-8-9-10 часов (по часам) и в пасмурную погоду, и долго тупили, не понимая, утро сейчас или вечер?
Личный ли это ваш опыт, фантазии ли о бесцельно потраченном времени в молодости, которое уже не вернуть - неважно. Важно, что вы приводите пример редкого случая, когда одновременно и независимо кто-то не может понять, сейчас столько-то часов до полудня или столько же в цифрах часов после полудня, причем внешних, дополнительных критериев для уточнения не существует в том смысле, что они категорически недоступны. Поскольку тезис, как принято сейчас говорить в этих ваших интернетах, "не зашел", вы не нашли ничего более тонкого, как попробовать формализовать качественный, описательный термин, который не имеет поддающихся точной формализации границ, но имеет границы лишь приемлемые.
Раз уж Вы начали упоминать всуе серъёзных
дядейтерминов, Вам придётся идти до конца и уточнить, что, в Вашем понимании, означает слово «зачастую». В числах.
Вот, вот оно. Ваше требование формализовать в абсолютных числах качественный, а не количественный термин, абсурдно. Но, поскольку я исхожу из добросовестных предположений, что вы недостаточно свободно владеете языком, на котором ведется диалог, а также не в состоянии отыскать, включая доступные без регистрации и SMS толковые словари, я привожу вам примерное значение термина "зачастую", выраженное как вы просите - в цифрах. Дальше у вас случается когнитивное несварение и рождается известный...
... очень глупый и совершенно детский анекдот
Вагон общественного транспорта. Нетрезвый мужчина шатается по вагону, подходит к пассажирам не сказать, что по очереди, но как-то пытается охватить всех и каждого, громко выкрикивая в лицо один и тот же простой матюк. В основном все морщатся и с омерзением отворачиваются, а наш герой продолжает оглашать вагон все тем же одним повторяющимся матюком. Внезапно, одна из пассажирок, впрочем тоже не скрывая омерзения, спрашивает нашего глашатая: "Мужчина, вы кроме [этого матюка] еще какие-то слова знаете?". Тот зависает на время и, внезапно просияв от осознания мощи собственных ментальних сил, кричит: "Парашют!!!". - Мужчина, что парашют, - спрашивает пассажирка. [Матюк!] - гордо отвечает ей герой.
Итак, вы зачем-то приплели парашют, пытаясь доказать что? Вернемся, однако, к крайнему последнему вашему тезису.
Но ведь в те же границы поместится и парашют с вероятностью 50,00000001%!
Невероятным, поражающим воображением фактом является то, что чисто формально, в обусловленных вами самим рамках, вы совершенно правы! Аплодирую стоя. Нет, ну надо же - при помощи парашюта вывести доказательство того, что 50.00000001%<50.00000000%. Нобелевка по математике, уверен, ваша. Не про троллингу, нет - тут вы зачет по предмету "Троллинг первого уровня в этих ваших интернетах" провалили. Готовьтесь и приходите на пересдачу.
Или я отстал от жизни и где-то галочка есть?
Да.
У меня 2.5 года каждый рабочий день начинался со скачивания свежего .rdp файла для подключения к удаленке. До сих пор все до одного лежат там родненькие, глянул и правда после 100 таймстемпы пошли.
Звучит утомительно, разве нельзя было хоть как-то автоматизировать/поменять процесс?
Это была удаленка клиента, который, впрочем, в какой-то момент перешел на Citrix. Файлики больше скачивать не нужно, но я все равно храню их, как память.
нельзя было хоть как-то автоматизировать/поменять процесс
Так когда автоматизируешь web-тестирование или тестирование api сервака, как раз и могут накапливать сотни файлов, при пробеге тестов, включая скачивание сгенерированных файлов pdf и прочих xml и xls(x).
Я, правда, подобное не встречал, у нас файлы все изначально были с названием по выборке + таймстамп с точностью до миллисекунды.
Организация по безопасности организаций информационной безопасности?
В .rdp файле нет возможности удалять его сразу после подключения как в том же Citrix, например? Всё равно ведь файл обычно одноразовый.
А с чего он одноразовый-то?
Если надо каждый день новый файл тащить, то обычно это означает, что старый протух. Обычное дело. Потому и уточнил.
Но это локальная особенность, связанная, к примеру, с динамическим открытием порта. Или там вообще новая виртуалка создаётся. Или всё проще и новый файл скачивается не потому что он обновился, а потому что он мог обновиться.
Эти пляски не имеют отношения непосредственно к протоколу RDP.
Видимо потому что доступ идёт через PAM систему, а там каждый раз генерируется временный пароль и зашивается в rdp файл.
У меня 2.5 года каждый рабочий день начинался со скачивания свежего .rdp файла для подключения к удаленке
Подозрительно похоже на работу в "Люксофте" в "Сити-аккаунте". Там тоже вся работа шла через подключение к удалённой машине.
Не один и тот же, а файлы с одинаковыми именами. Каждый день текущий ежедневный отчёт называется Report.zip и скачивается как Report.zip, Report (1).zip, ..., Report (100).zip, но на 102-й день формат имени неожиданно изменяется.
Одна замечательная платформа электронных торгов переименовывает все скачиваемые файлы в имя "Файл", расширение остаётся.
В рамках одного лота может быть загружен десяток различных файлов (имя одинаковое). 10 лотов и уже соточка файлов на компьютере.
Safari не сохраняет файл ещё раз, если он получился таким же, как уже имеющийся. Т. е. если скачивать один и тот же файл, то будет только один. Более того, это работает и с не самым последним файлом. Например, если есть файлы svres.xml, svres-1.xml, ..., svres-11.xml, потом скачать новый файл svres.xml, отличающийся от них, то он получит имя svres-12.xml, но если потом скачать снова тот, который был сохранён под именем svres-11.xml, то новый файл сохранён не будет, а в список загрузок добавится svres-11.xml.
А дата у файла при этом тоже обновиться, или останется той, что была при первом скачивании?
А если этот файл несколько гигов весит?
А если с разных сайтов, но с одним именем? Перезапись в данном случае может быть злом, если файлик типа Readme.txt...
ну, на самом деле не то чтобы бесполезная информация - недавно писал генератор пдф, там имя файла тоже присылается с бэкенда (номер заказа _ параметры _ итп.pdf), в процессе несколько дней скачивал один и тот же заказ, и в один момент открыл downloads а там не (100).pdf а фигня какая-то, в первый момент подумал что что-то сломал в генерации имени файла
P.S. но вот что из этого можно статью запилить не додумался :)
Обратите внимание на то, что Firefox сохраняет дружелюбность к скриптам и классические традиции именования файлов для консольщиков (тем, что не добавляет лишних пробелов в имена файлов))
Но скобки всё равно всё портят.
Я до сих пор уверен, что Windows намеренно использовала "Program Files" и "My Documents"/"Documents and Settings" как кнут, заставить всех сделать по уму.
Да, это правило лучше соблюдать как пользователю, чтобы не ловить багов на Юникоде или пробелах в пути. Но этим же продолжается проблема с кодовыми базами, игнорирующими эту проблему.
Это вы ещё забыли про "длинное тире Copy" , если делать копию файла по Ctrl+C, Ctrl+V. Потом правда изменили на простой дефис.
Ого, оно точно так в эксплорере? Или было? Я в интернете ничего не нашел, кроме проблем с консолью и dir /b, который их якобы автоматом конвертирует в выдаче:
https://stackoverflow.com/questions/22677677/how-to-deal-with-an-em-dash-in-a-filename
https://stackoverflow.com/questions/19882824/how-to-rename-files-with-em-dash
Рад, что в Линуксе победил здравый смысл: UTF-8 везде.
utf8 в линуксе везде - так было не всегда. Сам столкнулся с моментом перехода, когда в одной версии дистрибутива была кодировка имён файлов на диске в koi8, и сколько-то лет так нормально всё было. А потом поставил новый дистрибутив - и словил кракозябры везде в именах файлов, которые были на русском. Хорошо что есть convmv. Год был где-то 2008-2009.
Да, и народ теперь со старыми кодировками "обратные" баги ловит. https://github.com/yt-dlp/yt-dlp/issues/5341
> чтобы не ловить багов на Юникоде
Хорошая теория. Жаль только, что Windows даже в самом последнем обновлении не использует Unicode как на уровне системы, так и на уровне всех пяти вариаций терминала. Для включения юникода нужно либо тыкать команды в терминал, либо ставить глубоко спрятанную галочку в недрах "старых" настроек и молиться, что это действие не прикончит систему.
Для Microsoft в 2025 году Unicode всё ещё эксперементальная технология из будущего.
Для Microsoft в 2025 году Unicode всё ещё эксперементальная технология из будущего.
1) Это наследие легаси и поддержка древних и не совсем древних энтепрайзных софтин, например довольно известный банковский софт работает ТОЛЬКО при английской локали в системе и только когда везде где только можно стоит английский язык, хотя сама система на чем это написано вполне себе юникод поддерживает (оракл)
2) в юниксах тоже не всё гладко с юникодом
3) юникод вызывает крайне трудноуловимые баги связанные с тем что часто в пользовательских данных встречаются "неправильно" написанные строки, например...буква Ё может быть написана десятком разных способов... начиная со стандартного 2хбайтного написания, и заканчивая самыми замысловатыми комбинациями из перестановки диакритических точек и сдвигов символов...растягивающих букву до 6-8-10-12 байт на 1 символ
я в свое время всю голову сломал в п.3 когда казалось бы 5 совершенно одинаковых по названию файла совершенно спокойно сосуществовали в файловой системе и БД совершенно чудестным образом игнорируя ограничения уникальности БД и ограничения ФС.. и это было на православном линуксе и постгри
1) Это наследие легаси и поддержка древних и не совсем древних энтепрайзных софтин
Отличный аргумент. А главное - применим к абсолютно любому единожды написанному ПО. Давайте тогда вообще ничего не менять -- легаси ведь!
Например довольно известный банковский софт работает ТОЛЬКО при английской локали в системе и только когда везде где только можно стоит английский язык, хотя сама система на чем это написано вполне себе юникод поддерживает (оракл)
Круто. Только в официальной версии винды для РФ по-умолчанию стоит cp1251, то есть НЕ использование юникода не только не решает названную проблему, но усугубляет её. И опять-таки, это проблема конкретной программы, а не Юникода или ОС.
2) в юниксах тоже не всё гладко с юникодом
А можно конкретнее? Не помню чтобы сталкивался с проблемами Юникода в Линуксе. Бывают проблемы отдельного софта, особенно того что с виндой взаимодействует. В самом же Линуксе (дистрибутивах) такого не встречал.
3) юникод вызывает крайне трудноуловимые баги
Хорошо, что использование прибитой гвоздями на уровне ВСЕЙ системы устаревшей на 50 лет кодировки, которая ещё и отличается в зависимости от инсталляции, не вызывает трудноуловимых багов. Не вызывает же?
я в свое время всю голову сломал в п.3 когда казалось бы 5 совершенно одинаковых по названию файла совершенно спокойно сосуществовали в файловой системе и БД совершенно чудестным образом игнорируя ограничения уникальности БД и ограничения ФС.. и это было на православном линуксе и постгри
Так, а причем тут юникод и линукс? Микроскопом можно забивать гвозди, но если он при этом сломается - это не проблема микроскопа. Если кто-то "неправильно" использует юникод и криво называет файлы - это не проблема Юникода, а проблема создателя файла.
Отличный аргумент. А главное - применим к абсолютно любому единожды написанному ПО. Давайте тогда вообще ничего не менять -- легаси ведь!
Это очень важный аргумент, это один из очень важных факторов почему винда так популярна, у неё просто чумовая обратная совместимость софта, тут в комментах со мной спорили что это не так, но например условная 1С7 написанная под 95 винду работает в 11 версии...это как пример энтерпрайзного софта, вы много софта под линукс знаете который был написан в 99 году, скомпилен (да даже и если не скомпилен, чтобы его можно было собрать в 25 году) тогдаже и без существенных проблем запустится в 25 году?
в винде очень много таких костылей для поддержки древнего софта и энтерпрайз этим пользуется, если вы не заметили то винда всегда в первую очередь ориентирована на корпоративных юзеров, а уже потом на домашних...это прослеживается во всей её структуре
и как вы представляете себе - предложение поменять турбину на новую, софт управления который написан в 99 году потому что "в вашем *никсе ядро устарело"... а микрософт, если вы прям мажор богатый а-ля сименс и прочий оракл, в 11 версию вам личный костыль впилит (что они активно и делают, что видно по утекшим исходникам XP ) чтобы софтина из древних времен безшовно подняласб
Круто. Только в официальной версии винды для РФ по-умолчанию стоит cp1251, то есть НЕ использование юникода не только не решает названную проблему, но усугубляет её.
она решает кучу других проблем, если cp1251 поменять на utf-8 отвалится куда больше софта, чем если этого не делать
В самом же Линуксе (дистрибутивах) такого не встречал.
Это вы может не встречали в DE и обкатанных утилитках, а копнуть чуть в сторону, так сразу всплывают "файл конфига должен лежать в папке где путь из ascii символов", "сделал логин на русском языке, а его как параметр часть утилит не понимает"
Это редкие кейсы для админов локалхостов, а когда у вас парк машин десятками тысяч измеряются, начинают выползать всякие глюки опенсорсного софта..дада именно глюки опенсорсного софта...когда "мы посчитали что этим функционалом полторы калеки пользуются, по этому мы решили его не фиксить, сами пишите MR мы его через 10 лет рассмотрим"...удобно! (я реально в 2009 году писал issue в какуюто утилитку что там режимы шифрования гвоздями прибиты...меня послали со словами "ты лох, используй что дают или пиши с нуля"...дада, мы сервисная компания будем форк ОС делать потому что у нас аудит безопасности не проходит
и юникод сюдаже, до сих пор можно найти утиль который на нем споткнётся...самое явное пробелы и не-ascii символы в uri, это пофикшено только в самых ходовых утилях бизибокса, а чуть в сторону, то там рандомные грабли
Если кто-то "неправильно" использует юникод и криво называет файлы - это не проблема Юникода, а проблема создателя файла.
гениально, предлагате мне уволится когда мне каждый день условная Sony и universal присылает по паре сотен тысяч файлов с кривыми названиями, я прям к своему гендиру приду и скажу, моя система за которую я ответственнен плохо работает потому что наши партнёры кривые файлы шлют... далее что, письмо турецкому султану "мы с гендиром компании на 50 человек пишем в сони что они плохо нам генерят файлы, которые нам каждый день надо в прод выливать"...всё потому что стандарт юникода в каждой системе через свою новою попу написан
Открытия, которые мы заслужили.
XIX век: если двигать магнит в катушке из провода, получится электричество
XX век: если лететь [почти] со скоростью света, время идёт иначе
XXI век: если сохранить файл 102 раза...
ну там таймстамп стоит или что? они так просто никальное имя делают, наверно
я себе написал скриншотер у меня тоже при каждом новом скриншоте уникальный скриншот с уникальным именем. просто 1-2-3... нагрузно проще сразу числами более менее уникальными
если там данные одинаковые поидее не проблема. вот еще интересный вопрос, что лучше сбрасывать таймер или вести его до бесконечности?
А что гадать, нужно код смотреть. Невероятно, разные программисты погромировали
Я даже их имена знаю, насяльника!
Вот кстати не нахожу сходу эту логику. Тут есть обработка дупликатов, но про таймстампы не там ни рядом ничего нет.
Мда, рекурсия в js конечно не самая хорошая идея. Но вообще этот код для chrome os, там в readme есть. Я думаю для десктопа код будет где то в районе chrome/browser/download лежать.
В комментах к оригинальной статье нашли релевантный коммит.
Вам смешно, а у меня реальные подобные кейсы были. Навскидку, в Strava больше 100 тренировок в день нельзя импортировать.
А можно было бы провести перед написанием статьи небольшое исследование.
Во-первых, кодовая база у Chrome и Edge общая, поэтому и поведение одинаковое. А у Firefox всё свое.
Во-вторых, можно было бы откопать предысторию: https://issues.chromium.org/issues/40235521
В Chrome изначально сделали перебор только 100 файлов при сохранении. Если все 100 существуют, то появляется диалог выбора имени. Сделано для того, чтобы избежать ситуации, когда в папке очень много файлов, и сохранение очередного занимает много времени. Представьте, что в каталоге миллион файлов с такими шаблонными именами. При сохранении очередного браузеру нужно проверить в цикле существование каждого файла из этого миллиона, и только потом сохранить новый.
Потом же появились жалобы, что 101 файл не сохраняется. И программисты дописали код, чтобы после 100 проверок просто генерировалось новое уникальное имя без индекса на основе времени. В итоге, браузерный код выполняется более менее за константное время даже в худшем случае.
В Firefox же базовый цикл на 10 тысяч повторений (после чего начинается магия). Автору, к сожалению, терпения не хватило.
https://searchfox.org/mozilla-central/source/toolkit/components/downloads/DownloadPaths.sys.mjs
createNiceUniqueFile(templateFile) {
// Work on a clone of the provided template file object.
let curFile = templateFile.clone().QueryInterface(Ci.nsIFile);
let [base, ext] = DownloadPaths.splitBaseNameAndExtension(curFile.leafName);
// Try other file names, for example "base(1).txt" or "base(1).tar.gz",
// only if the file name initially set already exists.
for (let i = 1; i < 10000 && curFile.exists(); i++) {
curFile.leafName = base + "(" + i + ")" + ext;
}
// At this point we hand off control to createUnique, which will create the
// file with the name we chose, if it is valid. If not, createUnique will
// attempt to modify it again, for example it will shorten very long names
// that can't be created on some platforms, and for which a normal call to
// nsIFile.create would result in NS_ERROR_FILE_NOT_FOUND. This can result
// very rarely in strange names like "base(9999).tar-1.gz" or "ba-1.gz".
curFile.createUnique(Ci.nsIFile.NORMAL_FILE_TYPE, 0o644);
return curFile;
},
Сделано для того, чтобы избежать ситуации, когда в папке очень много файлов, и сохранение очередного занимает много времени. Представьте, что в каталоге миллион файлов с такими шаблонными именами. При сохранении очередного браузеру нужно проверить в цикле существование каждого файла из этого миллиона, и только потом сохранить новый.
Прикиньте, если в каталоге миллион файлов, то в каждый файл из этого миллиона всё равно будет обходить,
только не браузер, а операционная система:
Браузер хочет записать в каталог файл
test12345678. Давайте посмотрим, что в этом каталоге сейчас естьфайл
test00000000, не проблемафайл
test00000001, не проблемафайл
test00000002, не проблема...
файл
test12345678, не проблемафайл
test12345679, СТОПЭ, мы не можем иметь два файла с одинаковым именем в каталоге. Отвечаю браузеру:EEXIST
(Конечно, некоторые ОС хранят каталоги в виде двоичного дерева, но это как повезёт. А я ещё про фрагментацию каталога не начинал...
Давайте всё-таки исходить из того, что на системном диске используется современная файловая система, а не FAT32?
И если проверять каждый файл по порядку — то файловая система имя первого файла проверит как минимум миллион раз, второго — 999,999 третьего — 999,998 и т.д. Сумму посчитаете? Так что всё же лучше всего на тысячах проверок остановиться (в случае ста файлов) :)
Прикиньте, если в каталоге миллион файлов, то в каждый файл из этого миллиона всё равно будет обходить
Нет. Для того чтобы проверить есть ли такой файл в директории, ОС должна лишь считать само оглавление директории, которое является отдельным системным файлом, но самое главное, что поиск в оглавлении делается один раз, если вы просто хотите сохранить файл под конкретно заданным именем, и 100500 раз, если вы хотите найти не занятое имя из шаблона имени. Соответственно, если вопрос стоит в том что вы задали имя и
Браузер хочет записать в каталог файл
test12345678
то ОС произведёт один раз поиск test12345678 по файлу оглавления, а если браузер хочет найти незанятое имя начинающееся на test(:digit:)+, то будут перебираться все совпадения с шаблоном до тех пор пока не будет НЕ найдено совпадение.
И разумеется поиск одного имени среди миллионов гораздо быстрее, чем поиск 100500 имён, когда 100499 из них уже существуют.
Поэтому разработчики браузера и ограничили поиск сотней имён (для ФФ - 10000).
ОС произведёт один раз поиск test12 345 678 по файлу оглавления
Вот только «поиск test12 345 678 по файлу оглавления» — это записанное кратенько «посмотри первое имя в файле оглавлении, если оно равно test12345678, то верни true, иначе возьми второе...» — то есть операция не атомарная.
Даже большинство операций процессора не атомарны, ибо выполняются по несколько тактов, но какое это отношение имеет к алгоритму поиска совпадения заданного текста в файле? И ежу понятно, что чем больше файлов в директории тем дольше поиск файла в ней, и если браузеру нужно выбирать имя файла для сохранения самостоятельно, то логично что нужно ограничить перебор не сильно большим количеством вариантов, исчерпав которые нужно изменить алгоритм генерации имени на более уникальное.
Как картинка про стандарты. 10000 файлов должно хватить каждому )
Миллион, говорите... У меня была одна задача, по которой в каталоге могло быть порядка 10 или 20 тысяч файлов, уже точно не помню. Так вот винде очень плохело уже после этого количества файлов в одном каталоге. Чтение списка файлов из каталога начинало дико тормозить на любом уровне - из моего кода, из самой винды если окошко открыть, везде.
AFAIK, по умолчанию винда на NTFS при простом чтении папки у всех файлов в ней меняет Last Access Time. Поэтому на большом количество файлов может поплохеть, да.
Ну, Проводник-то понятно почему тормозил - ему ж миниатюры надо для всех файлов получить. Вот почему тормозил доступ из кода - вопрос более интересный...
У меня сейчас в нескольких архивных папках более чем по 50 тысяч файлов в каждой, поплохения не замечаю.
Интересно, а Винда с "Новая папка (N)" сколько может их создать?
Я смог проверить в Thunar
Скрытый текст
На 105 закончились? И ничего не предложила больше?
Я решил, что «ошибка 102» не выявлена, и прекратил эксперимент.
Это для Хрома 102.
В Firefox же базовый цикл на 10 тысяч повторений (после чего начинается магия). Автору, к сожалению, терпения не хватило.
Это из комментариев. Вот меня и заинтересовало - а у Винды есть такое ограничение?
А вдруг там как в Firefox, начиная с десятитысячного элемента необычное поведение?
Уф, ну и заголовок статьи. Я уж было подумал, что само содержимое загружаемого файла другое получается. А тут просто уникальность имени немного иначе обеспечивается.
Почему было не написать "более 102 раз", или "102 и более раз"? "102+" может означать и 102,57, например.
А ещё к 102 можно прибавить отрицательное число или даже комплексное.
Я за комплексное. Профдеформация, простите. Чтобы сразу видеть реактивность и знак. :)
Я за комплексное. Профдеформация, простите.
Не «комплексное», а «сложное» (или «составное»). Профдеформация, простите. /s
Комплексные числа - обыденность любого инженера-электрика или электронщика, потому что они предоставляют удобную форму отображения процессов, происходящих в цепях переменного тока. Как вы возможно знаете, электрические цепи подчиняются т.н. закону Ома: "сопротивление не бесполезно; сопротивление это напряжение, деленное на ток". Так вот, в цепях переменного тока в это довольно нехитрое правило привносится увлекательное разнообразие способом расщепления фаз тока и напряжения, занимательный результат чего и описывается комплексными числами, как удобным в контексте математическим аппаратом, а не чем-то самоценным самим по себе.
Я в курсе этого всего. Я про то, что давным‑давно, пару веков назад переводчик был покусан тогда ещё диким надмозгом и перевёл «compex number» как «комплексное число», хотя в английском оно дословно «составное число». А дальше всё заверте...
Эта ерунда происходит не только с одним и тем же файлом. Сейчас не вспомню кейс, но у меня сохранялись разные png в одну папку с каким-то дефолтным именем. Естественно, имя совпадало, значит шла нумерация. После какого-то шага вместо нумерации начинался таймстамп.
Мне на тот момент не мешало, а может даже и удобно было, поэтому внимания не обратил. Эффект был стойким, случалось несколько раз.
У автора слишком много свободного времени. И ещё поражает, какая мелочная деталь так сильно его увлекла
Я проверил, если что, на мобильном хроме, на мобильном эдже, и на мобильной опере все тоже самое, на опере происходит при 142 файле, а на эдже и хроме 101 файл, если сможете найти контакт чтоб это отправить - передайте, я просто не заметил контакта чтоб это написать, а файрфокс и найтли никак не реагируют на это, даже после 300 файла
Заголовок статьи воодит в заблуждение. Я подумал, что меняется содержимое файла, стало интересно, а тут всего-лишь имена.
Загрузка одного и того же файла 102+ раз в браузерах Edge/Chrome и Firefox приводит к разным результатам