Comments 48
Эх, где мои 15 лет. Norton disk editor и файл, состоящий из пробелов...
Тоже про disk editor вспомнил
Эх, и мои 17... Yamaha MSX, MSX-DOS, дисковым редактором записи directory entry сдвигались вниз, после чего файл не отображался в директории, но спокойно жил на диске (чтение директории останавливалось на первой пустой записи). При необходимости всё возвращалось на место. Таким способом мы прятали игры от преподавателей, которые могли взять дискету на проверку. Да, на одной дискете помещалась и ОС, и средства разработки и несколько игрушек. Самые крутые игрушки были по 128 КБ, но и в 16 КБ помещалось что-то играбельное
Да, тоже так делал, даже без диск едитора. На доп. клавиатуре с альтом символ 250 (или может 255 - не помню), выглядит как пробел и, главное, в волковкомандоре отображался последним в списке, т.е. если не знать, что в конце есть еще один файл, то обнаружить его можно только случайно, выйдя курсором за конец списка.
Еще помню делал "защиту от копирования" зацикливая в фат последний сектор на первый и ставя размер больше гигабайта, это на дискете. Открыть посмотреть можно, а скопировать гигабайтный файл - на дискету не влазит и хардов тогда таких не существовало.
Еще прикол - рекурсивано зациклить каталог - можно бесконечно заходить в один и тот же каталог. Скопировать тоже затруднительно - только по одному файлу.
Делал скрытые файлы, записывая ноль в середину списка каталогов (про эту фичу тут anddybiiig уже написал). Добавлю, что для того чтобы скрытые файлы появились, достаточно было дописать в каталог еще один любой файл, который закрывал "дырку" и скрытые файлы магическим образом появлялись.
А еще, будучи уже студентом, на кафедре дискедитором сделал себе сскрытый раздел диска, отгрыз 50М. Тогда всяких партишенмаджиков и пр. еще не было (или может у нас были не известны), так что мой раздел долго никто не мог обнаружить.
Думаю, эти приколы и сейчас сработают на флэшке с fat.
а мне вспомнился давний прикол с именем файла ".." и рекурсией на самое себя. был .bat-ничек который создавал такое
Для nix'a мне показалось убогим разграничение на группу, владельца, некого юзера. Убого оно.
Как-то в мастдае даешь пачку разграничений на пачку групп и живёшь себе спокойно. А в линузе 3 уровня...
Можно включить nfsv4acl, калька с виндовых acl
точнее это требование с древнейших unix. тогда же были введены acl. другое дело, что они в явном виде не отображались.
Я бы сказал наоборот. NFS был задуман до того как Windows вообще написали. В 1984 году, если верить википедии. И тогда же уже были проблемы с группами, поэтому и появились ACL. А то многие говорят - о, в юниксе команды в командной строке как в досе :)
Просто для работы с этими сетевыми файловыми системами требовалось работать с ACL.
Исходно в LanManager (предке SMB и соответственно современного CIFS) было всё гораздо проще, в виду ограниченности ресурсов машин. и они были однопользовательскими изначально, в отличии от UNIX.
Посмотрите древа развития юниксов.
Давным-давно всё есть: https://wiki.archlinux.org/title/Access_Control_Lists
А чем именно убогие 3 уровня не дают вам спокойно жить?
Отказ от виндовых ACL (они тут зовутся NFSv4 ACL) - принципиальное решение именно в Linux, в других *nix поддержка есть.
Linux is the only one of the major Unix flavors that does not have any native NFS4 ACL support upstream in the kernel yet. There was a proposed implementation called RichACLs ... VFS maintainers believe that POSIX draft ACLs are sufficient and NFS4 ACLs don't fit well to Linux - wiki.samba.org
Забавно. Как-то, ради прикола, написал программу, создающую 100 ГБ файл, заполненный бинарными данными, правда на NTFS5, а не на *nix-овой ФС. Все нормально. Ни файловая, ни операционная (Виста) - системы не глюкнули, выдержали издевательство. :)
ее даже писать не надо, есть например dd под liux и windows
На линуксе, ради прикола, можете попробовать
truncate -s3T bigfileФайл без проблем создастся даже если у вас размер диска меньше 3Т. Фишка в том, что кластеры заполненные нулями на диске не сохраняются, пишется только инфа, что от сель и до сель столько-то нулей.
Гм. А почему они должны были глюкнуть? Речь же про обычный "бинарный" файл?
Длинна имени файла в линуксе не просто ограничена а ограничена так что не получается сделать нормальную сетевую папку для шиндоус клиентов. В 255 байт utf8 влезает вполовину меньше русских символов чем может создать виндоус клиент, а каких-нибудь японских и вовсе в 4 раза. С этим надо что то делать.
Перестать создавать файлы с безумно длинными именами.
Ну вот реально не понимаю зачем в названии файла нужно умещать "Войну и Мир"....
130 русских символов это не война и мир. 70 китайских тем более
на ntfs, внезапно, такие же ограничения. там имя файла с путём сохраняется.
Просто имейте в виду, что файл на NTFS — это более глубокое и глобальное понятие, чем можно себе вообразить просто просматривая каталоги диска. Ну и напоследок: имя файла может содержать любые символы, включая полый набор национальных алфавитов, так как данные представлены в Unicode — 16-битном представлении, которое дает 65535 разных символов. Максимальная длина имени файла — 255 символов. т.е. поле имени с путём!!! до 510 байт и соответственно 255 символов.
покажи мне в виндах подряд вложенные имена папок+имя файла больше 255 символов.
Легко, называется UNC Path и работать надо напрямую с Win32 API. На линуксах (ext4) человек тоже показывал, что ограничение только на один сегмент пути, а дальше лишь проблемы с невнятными API ядра и возможностью только наобум уместить весь путь к файлу (неизвестной длины) в созданный тобой буфер. Если очень надо, найду ссылку.
Смотрим в хелп microsoft: https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-createfilea
By default, the name is limited to MAX_PATH characters. To extend this
limit to 32,767 wide characters, prepend "\\?\" to the path
То есть полный путь ограничен 32767 широких символов, если немного постараться.
А начиная с Microsoft Windows 10 (версия 1607) можно уже и не добавлять \\?\.
а теперь внимательно смотрим сорсы NTFS IFS, точнее - иноды NTFS и системные ограничения и файловых систем вполне складываются друг с другом. для того, чтобы флешка, работавшая на WinXP на NTFS после извратов на Win10 не сломалась. т.к. версии NTFS различные и часть базовых структур не совместимы. Увы.
В первую очередь:
https://en.wikipedia.org/wiki/Comparison_of_file_systems#Limits
https://en.wikipedia.org/wiki/Comparison_of_file_systems#cite_note-note-12-174
"Windows NT does not support full pathnames longer than 32,767 bytes for NTFS. Older POSIX APIs which rely on the PATH_MAX constant have a limit of 4,096 bytes on Linux but this can be worked around. Linux itself has no hard path length limits."
cat /usr/include/linux/limits.h
https://github.com/torvalds/linux/blob/master/include/uapi/linux/limits.h
Собирал с NAME_MAX и XATTR_NAME_MAX(ставил 1023) - полет был нормальный. На боевых серверах не делать.
Программистам стоит помнить, что хранить не стоит создавать тысячи маленьких файлов без веской причины.
Во-первых, это неэффективно с точки зрения занимаемого места.
Во-вторых, можно нарваться на ситуацию, когда у Вас на диске свободно 10+ гигабайт, а операционная система говорит, что `No space left on device` (нет места). Такое бывает, когда закончилось место для inode (грубо говоря это запись о файле в файловой системе). Да, в линуксе на некоторых файловых системах количество файлов на диске ограничено х)
На Windows точно не знаю, но там тоже может присутствовать такое ограничение.
конечно. структуры файловых систем подобны друг-другу.
у фат файловых систем в зависимости от битности количество кластеров - в итоге количество файлов. т.е. грубо говоря на фат12 до 4000 файлов, фат16 до 65500 файлов, на фат32 до 4млрд. файлов. у HPFS, NTFS, юниксовые ФС - по количеству инод при создании, модификации ФС.
Длина имени файла ограничена. Структура, которая хранит информацию о файле не бесконечна.
Длина абсолютного пути до файла ограничена. Чуть менее очевидно, но причина идентична: размер буфера, в котором хранится абсолютный путь до файла, тоже не бесконечен.
Разделитель в пути, символ «/», использовать нельзя.
Нуль-символ использовать нельзя — это признак конца строки.
Внутри одного каталога не может быть двух файлов с одним именем.
Создавал свою файловую систему под линукс (статьи есть на хабре) поэтому чуть-чуть прокомментирую:
тут скорее линукс сам что-то подрежет при выдаче пользователю и вы не сможете этим пользоваться: линукс думает одно, файловая система (ФС) другое - одно другого не найдёт;
сам линукс пользуется структурой dentry, которую создаёт ФС. линуксу без разницы какие там длины и сколько вложенности, если ФС её создал - значит всё ок. по каталогам линукс скачет без имён. Вот если кто-то запросит полный путь - тогда линукс может дать обрезанную строку;
используй что хочешь - линукс это пользователю отдаст: хоть одинаковое всё, хоть точки (несколько и можно в середине списка). Другое дело что если такой путь вернуть обратно линуксу, то он его разобьёт на кусочки и скажет нет какого пути;
большинство файловых имён идёт с явным указанием длины и пиши там что хочешь. Вот при выдаче в юзермод там любят сишные строки и может текст порезаться. И опять линуксу будет всё равно - он эти имена отдаст. Если программа не сможет ими пользоваться - упс.
Хоть 2 одинаковых имени, хоть 10. Хоть все имена это строка две точки (..). Линукс всё сожрёт и выдаст пользователю. А дальше при открытии файла линукс спросит ФС: что за файл с таким-то именем? Вот что ФС ответит, то линукс и откроет. Это может быть первый файл, последний, или каждый раз другой. Учитываем, что про две точки (и одну точку) линукс ничего спрашивать не будет и сам всё обработает. Даже если ФС вернёт содержимое каталога без точек - переход в родительский каталог будет работать. Если файл .. указывает на что-то совершенно левое, то линукс всё равно пойдёт к родительской папке.
В общем, линукс здесь по файлам особо ничего не ограничивает. Но если программист не сможет пользоваться - "проблемы индейцев шерифа не волнуют". На самом деле (это собственное мнение) линукс делает правильно: разных ФС много, кто-то не различает большие-маленькие буквы, где-то время задаётся с гранулярностью в секунды, чётные секунды или ещё грубее. А линукс с этим работает единообразно и устойчиво.
Чуть в сторону вопрос: какие могут быть хитрости зашиты в microSD-карточке, что обычное посекторное копирование их не берёт?
Купил тут праворульку с магнитолой, пока везли из Японии, по дороге стащили флэшкарту из магнитолы. Без карты магнитола не работает. Карты есть в продаже на Авито, оригиналы и клонированные, купил и хотел сделать бэкап, естественно. Хитрая карта, 4 FAT раздела, виден один только, размер 9Гб в партиции, но 6Мб в интерфейсе. А вот не делается копия ничем - ни программами клонирования, ни просто посекторно. Или там надо в потроха лезть, чтобы она ещё и своё железо что-то определённое отвечала?
Куда можно покопать, не подскажете?
Насколько я знаю, у MicroSD есть механизмы защиты, в том числе для защиты от чтения. Википедия говорит, что это требование Secure Digital Music Initiative (SDMI), возможно, это аббревиатура поможет вам в поисках как именно защищается флешка.
В моем опыте были проблемы с флешками, на которые поставили пароль через телефоны Nokia на платформе S40. Даже отформатировать такую флешку с потерей данных было проблемно, поэтому они просто навсегда отправлялись на полку.
Чем вы пытались копировать. dd не работает?
Если и правда карта нетипичная, то вот документация, покупаете модуль для SD карт, подключаете к любому устройству со SPI шиной (продавцы часто продают их как модули для Ардуино, но можно присоединить хоть к программатору CH341, хоть к клонам малинки, вот только для Ардуино есть готовые библиотеки) и посылаете разные команды (придётся программировать).
DiskExplorer, Drive Cloner и другие утилиты. На уровне FS уверен, что копировал всё.
Спасибо, поизучаю
Думаю способы есть, но судя по поиску в интернете, на продаже таких карт хорошо зарабатывают, поэтому делиться опытом не будут.
Такие хитрые флешки не на уровне ФС надо, а на уровне разделов, то есть через dd клонировать не /dev/sdf1, а /dev/sdf целиком. Не припомню, чтобы нельзя было обнулить или создать образ с флешки какой-то, если так применить dd - кроме случаев именно неисправной флешки, но это в подавляющем числе случаев сразу видно в консоли по I/O error.
Я ж говорю, посекторно скопировал. Всё равно ведь ФС работает с флэшкой, вряд ли в магнитоле стоит дополнительная железяка для флэшки.
А так там 4 раздела, один из них кривой, скопировано всё 1:1, но нет
магнитоле стоит дополнительная железяка для флэшки.
Может и стоит. Точнее, впаяны нужные чипы и протоколы. И ключики доступа куда-то вшиты.
Тут рядом уже сказали - у SD Card первая буква 'Secure' - от наличия защиты от копирования взялась:
The SD memory card CPRM function has the following features:
Success of mutual authentication enables host to access card protected area.
Ну и еще есть всякое использование, на которое при обычном использовании как просто как внешнего хранилища файлов еще напороться надо.
В ноутах делают ведь white-list для дисков, почему в магнитоле не сделать? По производителю флешки, по серийнику или другим критериям. Ведь делают же они с панелькой уникальные связи, что от другой магнитолы панель не подходит, даже от такой же модели.
Есть приколы и с разными символами, которые запрещены к использованию в ФС. При этом в разных версиях софта (linux) обработка такого со временем менялась. Сам столкнулся - есть переносной диск с NTFS, где большой архив фото/видео, примерно с 2006 года. Изначально (так сложилось) всё это хранилось на HDD в компе, на ext4. И никаких ограничений по символам я особо не встречал, а про различия ограничений в разных ФС и в разных ОС как-то не задумывался. Да и скидывал на диск не только я, но и жена, которая не особо понимает, скопировалось и ладно.
А ограничения оказывается есть, например, нельзя точку с запятой использовать, нельзя двоеточие, и ещё какие-то символы, которые в ext4 спокойно можно. И получилось как-то так, что я скидывал каталоги на диск с NTFS с такими именами (где запрещённые символы), и под линуксом никаких ошибок или предупреждений не было. Уже после, через много лет, что-то там перемещал, и упорядочивал на этом диске, и наткнулся, что есть проблемы с такими символами - скопировать нельзя, изменить нельзя, и создать аналогично с такими символами тоже нельзя. Уже не помню как выкрутился, но в итоге отловил всё, что запрещено и исправил. Кстати, под windows тоже ругательства были на такое, а вот телевизор LG никогда не ругался и спокойно показывал все файлы из таких каталогов. Между созданием таких каталогов и выявлением проблем уже сменилось как минимум пара версий дистрибутивов на ПК, и с какой версии (ядра? или модуля ядра) произошли изменения, не знаю. По хорошему, надо бы перед копированием проверять на наличие таких символов, и это должен делать (мне кажется) файловый менеджер, и предупреждать хотя бы о возможных проблемах, или уметь автоматом или как-то ещё разруливать такое.
И с регистром символов встречается - в ext это влияет, а вот скопировать a.txt и A.txt на флешку, может стать проблемой, если в одном каталоге.
Нарушаем ограничения файловых систем *NIX