Linda-chan, смотря какая файловая система

Техническое ограничение вроде как есть, но это зависит от файловой системы, разве нет?

BTRFS 255 bytes
exFAT 255 UTF-16 characters
ext2 255 bytes
ext3 255 bytes
ext3cow 255 bytes
ext4 255 bytes
FAT32 8.3 (255 UCS-2 code units with VFAT LFNs)
NTFS 255 characters
XFS 255 bytes

http://en.wikipedia.org/wik..._file_systems#Limits

ext3fs.

Не, таки, ext4.

Забавно, для винды справедливо тоже самое, но MAX_PATH никто не отменял.

Linda-chan, /3 таки. Но полный путь - не лимитирован.

В линуксе тоже есть лимиты ан путь - https://serverfault.com/que...s-on-linux/9548#9548

Я БП, мне постоянно рассказывают, что все проблемы винды давно побеждены в линупсе, а оно во как выходит. Если, конечно, виноват не Дропбокс.

Есть проблемы, а есть разумные ограничения.
С другой стороны, в Линуксе никогда не было проблем с размером файла. например.

Про NTFS враньё, там 260, как и в FAT32, но можно больше, просто всё хитро. И, да, байты как бы намекают OO

Ну хоть что-то.

Теоретический, в Windows их тоже нет.

В Линуксе проблем не было еещ когда они были в Виндоусе :)

Toyoku-mono, как интересно. не лимитирован для FS, но лимитирован, сцуко, со стороны ОС, из-за используемого типа данных

Linda-chan, /8

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

Во времена до Windows 95 OSR2?

Toyoku-mono, нихрена неясного, я вот токо шо открыл limits.h и своими глазами прочитал)
короче, длинна полного пути файла сохраненного в хомяке - 4091-len(username)

Теперь осталось придумать путь в длинной в 4 килобайта :)

это если хомяк не на отдельном разделе. если на отдельном - 4095-len(username)

Сразу видно человека, в универе не учившегося!

Toyoku-mono, С:\Хрень по работе\Гемор\Тупые клиенты\Неплательщики\охуевшие\Уважаемый Сергей Анатольевич.doc

Сорян, у меня просто мания к овероптимизации, я себе такого позвоить не могу :(

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

Ну явно не в моем.

Linda-chan, %windir%\system32\drivers\etc\porno?

Это от родителей ^^ А я про каталог\проги\крутые\от васи\тоже проги\качать\здесь\1\2\3\4\5\6 etc.

Linda-chan, вот, а ты клиент дропбокса через strace запусти

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

Зашла через CarrotDAV и сократила имена файлов. Поздно.

Вопрос конечно в том как Дропбокс хранит данные на сервере. И каке ограничения в клиенте.

На сервер файл залился через вэб-интерфейс и прекрасно просматривался через него же. Но не качался клиентом.

Ну, как сказать. Из первого же результата по «MAX_PATH» в Google:

В приложениях, которые используют Win API для работы с файлами, рецепт избавления от ограничения MAX_PATH был известен с незапамятных времён – необходимо было использовать Unicode версию функции с окончанием «W» для работы с директорией или файлом и начинать путь с префикса \?. Это давало возможность использовать пути длинной до 32767 символов.

+

В Windows 10 (1607) поведение функций для работы с файлами изменилось: появилась возможность отключить проверку ограничений MAX_PATH на уровне системы.

Так что таки отменяли.

Странные лимиты. Прямо сейчас взяли сделал путь на диске с NTFS длиной 612 символов. Правда из Windows.

Да, действительно - файл с именем из 304 символов создать не вышло.

И вот тут бы пригодилось короткое имя файла, но увы ^^'

«\?\» – это таки костыль для обхода MAX_PATH. From Microsoft.

Я подозреваю, что там смысл в том, что так полное имя файла прикидывается UNC, на которые MAX_PATH не распространяется. А сделать «\.\» они не могли по причине всяких мэйлслотов и тому подобного, у которых имя файла записывается так: «\.\mailslot\1\2\3».

Linda-chan, как я счастлив, что избавлен от этого дерьма

Юзаешь Хромбук?

Toyoku-mono, не, просто ни одной венды дома нету

Главное не заразись макинтошкой.

Toyoku-mono, упаси Торвальдс

как ни странно, но таки есть и на длину пути и имена. иногда выскакивает, когда пытаешься например бекап хомяка с винды распаковать на месте в глубинах хранилища. Особенно припекает несоответствие
"NTFS - 255 characters" и "linups fs - 255 bytes"

О, так может поэтому 182 символа вызвали проблему в /0? Т.е. в байтах многовато вышло.

Точно, компоненты. Вот что даёт GetVolumeInformation() для NTFS диска:

Max component len: 255
File system name: NTFS

Taciturn, ну, если utf-8, как по дефолту, для ext4 до один символ, может быть и больше одного байта

Linda-chan, 255 чего?

lpMaximumComponentLength
Points to a doubleword value that receives the maximum length, in characters, of a filename component supported by the specified file system. A filename component is that portion of a filename between backslashes.
The value stored in variable pointed to by *lpMaximumComponentLength is used to indicate that long names are supported by the specified file system. For example, for a FAT file system supporting long names, the function stores the value 255, rather than the previous 8.3 indicator. Long names can also be supported on systems that use the New Technology file system.

Linda-chan, даблворд - это ж 4 байта на символ, не?

Обратная совместимость. Что поделать.

UTF-32 какое-то

Linda-chan, ну, всегда остается "волевое решение"

NTFS и VFAT хранят данные в UCS-2, поэтому так сразу в символах считается. А более другие ФС – в UTF-8, где длина строки очень разная в зависимости от языка.

Получается так. Имя файла было написано на русском.

Linda-chan, Ура. решение найдено. А обмен между вендой и лялихом шел?

Это переменная типа DWORD, которая получает число, соответствующее длине компонента пути. Это WinAPI функция.

А потом массовые «У нас программа не работает» от корпоративных клиентов.

В смысле?

А. Не, файл загрузили с Макоса.

Linda-chan, там что, тоже USC-2? По образу и подобию MS?
Короче, виновный найден - криворукие писатели дропбокс-клиента, которые нихрена не в курсе о кодировках, используемых в ФС

Linda-chan, Корпоративные клиенты либо сидят на одном стэке технологий, либо, не такие уж они корпоративные...

Без понятия.
А что должны быть сделать разработчики клиента Дропбокса? Покоцать имя файла? Транслитерировать его? Пересобрать ядро системы с другой кодировкой?

У тебя странное представление о корпоративных клиентах.

Linda-chan, перекодировать из USC-2 в uft-8.
Данные от том, с какой ОС подключился клиент - у них имеются

Linda-chan, это не у меня, это у Поставщиков Корпоративных Решений

У тебя, скажем, системная функция create_file(), которая принимает строку file_name. Очевидно, принимает она UTF-8. Давай, перекодируй имя файла из USC-2 в UTF-8.

Это не гибко, ну то есть усложнение. Ну вот они в клиенте могут проверить тип фс и выдавать, например, предупреждения, но толку?

Linda-chan, как ты убедилась, стащив файл в веба, это даже браузеры умеют. вернее, веб-морда, браузерам выдает то, что они умеют.
Веб-приложение, должно отдать клиенту то, что умеет клиент. Браузерам отдали, а собственному клиенту - не сумели

akagitsune, ну, давай нихрена не выдавать и не копировать файл, так лучше?

Они могут выдавать сообщение об ошибке, что не удаётся создать файл из-за ошибки «Слишком длинное имя файла», как это делает клиент ownCloud/Nextcloud в списке проигнорированных файлов. Про перекодирование имени файла – какой-то нонсенс.

Linda-chan, мне имя файла от сервера УЖЕ должно прийти в utf-8, ибо в заголовке запроса указано, что это Client DropBox/Linux

Graf, ну оно и так будет пытаться слить, а ошибку уже система выплюнет и клиент выдаст "не удалось создать".

Ты говоришь какую-то чушь. Броузеру выдаётся файл с таким-то именем, броузер предлагает сохранить этот файл, используя системный/тулкитный диалог. Если не сохраняется, пользователь меняет имя файла, как нужно. Клиент делает тоже самое, но ты предлагаешь ему самому догадаться, как разрулить ситуацию.

akagitsune, программа для пользователя или пользователь для программы? то что ты предлагаешь - это второй случай. "ну не шмогла я" и ебитесь как хотите

Linda-chan, я предлагаю запрашивать у клиента кодировку фс и выдавать ему данные в этой кодировке. Имхо, как-то логично

Блеать, у нас день сурка какой-то. Клиент получает имя файла и обращается к системной функции. Как и в какой кодировки хранится внутрях этой функции (а точнее, драйвера/библиотеки ФС) – дело уже не клиента.

Linda-chan, окай, не клиента. дело СЕРВЕРА дропбокса, отдать данные в правильной для клиента кодировке. Так лучше?

Ты думаешь, что клиент лично пишет байтики с именем файла и служебной информацией на диск? И он решает в какой кодировке это записывать?

Нет, чушь остаётся чушью.

Linda-chan, уверен, что нет. как ты писала выше, клиент тупо использует системную функцию. Следовательно, переконвертация кодировок для различных ФС и даже локалей, должна ложится на сервер.

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

Да причём тут кодировка, если проблема в лимите файловой системы? Ну вот перекодировал сервер, а дальше то что? Лимит никуда не делся, записать файл всё равно нельзя.

Системная функция принимает имя файла в кодировке N. Сервер, окей, присылает имя в кодировке N. Но имя всё равно не удовлетворяет лимитам ФС. Что должны сделать разработчики клиента?

На сервере Дропбокса файл может храниться с именем 123343412341.dat, а его имя может храниться в базе данных. Чё дальше.

Linda-chan, збс

Taciturn, тогда проехали, но как же она через веб-морду-то скачала?

Linda-chan, уела

Я не качала. Я посмотрела список файлов и увидела в чём проблема. Потом я взяла CarrotDAV и посмотрела ещё раз, а потом переименовала файл прямо на сервере. Чудеса без кодировок!

Да там небось он даже не как файл хранится, а как куча блоков - во славу дедупликации.

Он вообще может как запись в Бд храниться

Linda-chan, бля. ты ведьма. а я себе моск ломаю.
А у изначального заливальщика, что с файлом станет? тоже переименуется?

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

Данные хранить в базе непродуктивно, ИМХО.

Linda-chan, какие данные, какая база...

Он заливал не через клиент, а через фичу «File Request». Тоесть что-то типа входящих файлов: заливать может любой, у кого есть правильная ссылка, а смотреть залитое только я.

Linda-chan, кокой ужос(

Я в базах не очень.

Удобная штука.

Данные хранить непродуктивно

Linda-chan, в NoSQL хранилищах, вполне себе быстро и чотко можно хранить всякую бинарную хуету.

Toyoku-mono, Ораклу про это расскажи

В: О великий Оракул, эффективно хранить данные?
О: Эффективно хранить картоху и лук, консервы там всякие!

Toyoku-mono, ога, а так же патроны, тушенку, крупы...

... трупы.

Toyoku-mono, Трупы? Хранить? Какой с них профит?

тушенка кстати не прикольна, лучше морской экстренный паек.

Профит в отсутствии отсидки, например.

Toyoku-mono, скорми свиньям, и не будет вонять

А не проще на гуляш и холодец?

Linda-chan, в общем, если это что-то корпоративное и расчитано на кроссплатформенность, то имеет смысл запретить клиенту создавать и заливать файлы с именами и путями длиннее консенсусного максимума для кроссплатформенных клиентов. Ну или все на ntfs перевести, чтоб мозги не парили.

Toyoku-mono, крупные кости куда девать? Они ж вполне узнаваемы.
А после свиней - только коронки останутся...

Из костей сделать поделки, продавать на ближайшей ЖД станции.

Toyoku-mono, это ты такое творческое, а я даже стол никак не зопилю(

Стол из костей?

Toyoku-mono, не, из дерева. и найти еще 8 учеников
33 года, плотник, 13 учеников, вот это все... опоздал на 3 года уже

Лидером секты заделаться?

Toyoku-mono, пуркуа па?

вообще, это ФС-зависимо, но ни одна из известных мне использумых линупсоидами ФС не имеет ограничения в 182 (однобайтных) символа в имени файла (например, у tmpfs и ext4 - 255 байт)...
Впрочем, не то, чтобы я копал глубоко и был точно уверен, что это ограничение полностью на уровне фс

Где-то выше пришли к выводу, что таки ограничение на уровне ФС сработало. Имя файла было на русском, и в 255 байт не вписалось.