Что такое расширение файла на системном уровне?

Question

[lapka-admin]

Винда довольно жёстко привязывается к всевозможным расширениям и ассоциирует с ними различный софт, в linux расширений файла как таковых нет на сколько я понимаю, это просто часть имени.
Чем обусловлена такая разница подходов и где про это можно почитать что бы разобраться (подробности не до уровня байт-кода конечно))))

Comments

[Moskus]

В Windows это тоже часть имени. И в DOS была часть имени. То, что файлы по расширению ассоциируются с какими-то типами - исторически сложилось, не более.

[Saboteur]

Moskus, неправда. в fat16 это не часть имени. Файловая система выделяла отдельное место под имя (8 символов) и отдельное место для расширения.

[Moskus]

Saboteur, ваше возражение - терминологическое. Потому что зависит от того, что понимать под "именем". Если смотреть на структуры данных - да, это отдельная часть, которая может, в принципе, обрабатываться самостоятельно. Но с точки зрения архитектуры ОС, а не самой ФС, это - все равно часть названия, независимо от того, как оно хранится.
И я еще прекрасно помню Norton DiskEditor и всякие фокусы с "блокировкой" файлов через внедрение недопустимых символов в название, так что мне ли не помнить, как оно было.

[Saboteur]

Moskus, Не только терминологическое, а и фактическое и структурное.

В fat16 расширение хранилось на отдельных выделенных для них позициях в directory entry, где было четко зафиксировано - 8 символов под short name и три символа под extention.

То есть файл 1.exe, 12345678.exe и 1.ex будут храниться как

1       exe
12345678exe
1       ex

Пропущенные символы забивались пробелами

https://en.wikipedia.org/wiki/8.3_filename

[Moskus]

Saboteur, никак не противоречит тому, что я сказал. Вам лишь бы поспорить.

[sim3x]

Moskus, Перечитайте свои коментарии и сами найдите противоречие

[Moskus]

sim3x, я прекрасно знаю, что я имел в виду и что я написал. Если кому-то в моих словах видится противоречие, значит эти слова интерпретированы не в тот же самый смысл, какой в них закладывал я. Так бывает.

Этот односторонний спор уже становится непродуктивным.

[sim3x]

Moskus, если вас не поняли, то ето не проблема того кто воспринимает, а проблема того кто высказывает

[Moskus]

sim3x, весьма смелое утверждение. Чья это проблема - зависит от того, какова конечная задача. Мне, например, почти не важно, что вы меня не поняли - от этого ведь вообще ничего не зависит.

[Saboteur]

Moskus,
Если вы считаете, что мое утверждение чисто терминологическое, пожалуйста поставьте в виртуалке дос на FAT16 и создайте стандартными средствами файл типа 123456789.ex

Потом поговорим об адекватности.

[Moskus]

Saboteur, в качестве аргумента предлагать оппоненту сделать невозможное, хотя о нигде не утверждал, что это возможно (более того, утверждал обратное) - это уже самая настоящая демагогия https://ru.wikipedia.org/wiki/%D0%9F%D0%BE%D0%B4%D...
Заканчивайте спорить с воображаемыми вами "моими" утверждениями, это уже бред какой-то.

[Saboteur]

Moskus, Вы утверждаете, что в fat16 расширение это полноценная часть имени. Из этого следует, что 8+3 символов можно использовать как угодно. Но это не так, поскольку расширение это не часть имени, а технологически отдельно хранящаяся структура. Не хотите демагогии - не утверждайте бред.

[Moskus]

Saboteur, я нигде не утверждал, что в fat16 расширение - часть структуры данных, отвечающих за имя. Вы это выдумали, и использовать это, как аргумент - демагогия.

[Saboteur]

Moskus, "Но с точки зрения архитектуры ОС, а не самой ФС, это - все равно часть названия, независимо от того, как оно хранится."
Ваша цитата.

Теперь перейдем к архитектуре ОС.

EXTERNAL:
        MOV     AL,[SPECDRV]
        MOV     [IDLEN],AL
        MOV     WORD PTR[COM],4F00H+"C" ;"CO"
        MOV     BYTE PTR[COM+2],"M"
        MOV     DX,OFFSET TRANGROUP:IDLEN
        MOV     AH,OPEN
        INT     33              ;Check if command to be executed
        MOV     [FILTYP],AL     ;0 for COM files, -1 for EXE files
        OR      AL,AL
        JZ      EXECUTE
        MOV     WORD PTR[COM],5800H+"E" ;"EX"
        MOV     BYTE PTR[COM+2],"E"
        INT     33              ;Check for EXE file
        OR      AL,AL
        JZ      EXECUTE
        MOV     WORD PTR[COM],4100H+"B" ;"BA"
        MOV     BYTE PTR[COM+2],"T"
        INT     33              ;Check if batch file to be executed
        OR      AL,AL
        JNZ     BADCOMJ
BATCOM:

Как вы видите, при запуске файла, интерпретатор MS-DOS command.com (да, исходники официально опубликованы), не парсит имя файла, а считывает сразу расширение по смещению, которое для него однозначно.
Таким образом в MS-DOS собственно в основном системном файле зашита часть работы с файловой системой, и является неотъемлимой частью ядра ОС.

Answer 1

[Saboteur]

Это просто исторически сложилось, и связано не столько с операционной системой, сколько с файловой системой.

В FAT16 расширение хранилось отдельно от имени, а операционная система распознавала расширение исполняемых файлов, чтобы запускать их.
В Windows пошли дальше - добавили ассоции для других файлов, к которым привязали запуск софта, ассоциации хранились в реестре и соответсвенно что запускать определялось системой, вне зависимости от вызывающей программы.
В современной NTFS расширение это уже тоже просто часть имени.

В Линукс изначально файловая система не хранила расширения отдельно, а запуск программы разбирался по заголовку файла. Вдобавок графический интерфейс появился гораздо позже, и запуск документов и других не-исполняемых программ по ассоциации делали именно в графическом интерфейсе, а не на уровне системы - сама система работает только с исполняемыми файлами, для чего есть аттрибут execute.

Вот собственно и все - то есть исторически возникло от организации файлов и файловой системы.
Оба подхода по-своему удобны.

Comments

[longclaps]

В FAT16 расширение хранилось отдельно от имени

В FAT16 (и FAT12 тоже) имя и расширение хранились одним 11буквенным массивом.
Старик Альцгеймер еще не лишил меня остатков памяти, а вы там держитесь )

[pfg21]

в *nix потому что имелось альтернативная связь файла и програмки
#! /bin/prog
https://ru.wikipedia.org/wiki/%D0%A8%D0%B5%D0%B1%D...

[Saboteur]

longclaps, Нет.

Потому что точка в fat16 (не помню как в fat32, где добавили длинные имена) - не хранилась вообще. хранилось имя отдельно, расширение отдельно, а не как одно целое.
Вы принципиально не могли создать имя файла, где на 9-й позиции не точка.

p.s. Именно поэтому, вы в виндовс при поиске файла пишете *.*, а в линуксе достаточно *

[Saboteur]

pfg21, #! это только для скриптовых файлов (это кстати упомянуто на вашей ссылке в вики)
Для бинарных файлов типа ELF и PE идет разбор загрузчика.

[longclaps]

Saboteur, да. Ну чтобы быть совсем точным, хранилась как структура с 8буквенным и 3буквенным полями, естественно без какого-либо разделителя. Т.е. при просмотре hex-вьювером это очень похоже на 11буквенный массив )

[Saboteur]

longclaps, ну это да, но при создании имени короче 8 символов, лишнее заполнялось пробелами до расширения - то есть обрабатываются эти два поля отдельно =)

[InoMono]

Добавлю что MacOS, даже еще в те времена когда она была не MacOSX - использовал идеологию ту же что и Windows. И еще непонятно кто у кого спер эту идею

Answer 2

[Stalker_RED]

Да, это и в винде просто часть имени. Можно переименовать любой файл как вам угодно, с другим расширением, или вообще без него, и все равно в большинстве случаев его можно будет открыть через "открыть с помощью", или через меню "файл-открыть", или просто перетащив на иконку программы, или еще как-нибудь.

Но в винде "из коробки" гораздо больше "магии" завязано на расширение. И началось это еще во времена DOS, если не раньше. Какие именно подробности вас интересуют? Начать можно отсюда.

Answer 3

[CityCat4]

На системном уровне "расширение" имени - от одной до (PATH_MAX - длина текста до последней точки) символов. В нем нет никакой магии и к функционированию ОС оно не имеет никакого отношения. Как в винде, так и в линухе можно заводить файлы без расширения вообще и ничего за это не будет. "Расширение" имени - это просто удобный способ договориться о том, что это за файл и как его следует открывать.
В линуховом гуе точно так же как в винде "расширение" имеет большое значение - потому что определяет - что будет запущено при клике на файле.
"Расширение" не является единственным способом идентификации типа файла и вполне может быть липовым - вирусня очень часто в винде использует фейковые расширения - старый-старый прием - дать имя с "типо расширением" ну например .doc, за которым стопицот пробелов и настоящее расширение (обычно .exe или другое исполняемое)
В консоли есть команда file - которая определяет тип файла, не используя "расширение".

Answer 4

[Станислав Бодро́в]

Что такое расширение файла на системном уровне?

Ничего. На системном уровне совершенно иные привязки, например, inode в некоторых ФС Linux, кластер в NTFS.

Винда довольно жёстко привязывается

Многие привязки можно переопределить через графическую оснастку.

Чем обусловлена такая разница подходов

Удобство.

Answer 5

[UndefinedBehaivor]

Там просто расширения ассоциируются через реестр. При двойном клике например передается управление в shell32.dll!ShellExecute оттуда идет парсинг расширения, после расширение ищется из ассоциированных и врубается соответствующая программа. Например, для .txt - по дефолту notepad.exe, тогда врубается notepad.exe file.txt, можно поставить собственный софт и будет врубаться он.

Кстати, по этому принципу можешь сделать свой проводник. Берешь убиваешь основной, свой ставишь в авторан, при старте прогружаешь все с авторана через ShellExecute ( парсишь реестр ветки Run/RunOnce, после из RunOnce удаляешь ), потом парсишь десктоп и отрисовываешь иконки, создавая ассоциативный массив с сектором пикселей и путем до файла. После двойного клика передаешь путь до файла через ShellExecute. Профит

Есть также жестко зашитые расширения, например "PE Executable" в реестре пишут - и это тогда передается в загрузчик винды через ntdll.dll!RtlCreateProcessAsUser с уведомлением csrss.exe. Примерно так. Можешь свои проги так попробовать поврубать, только они могут некорректно работать, т.к система будет не знать, что они запущены. Будет просто дескриптор процесса зареган в ядре и создан поток на EntryPoint ( ну или TLS-коллбеки, у кого что ).

Ты можешь зарегать например .program как PE Executable и переименовать все экзешники в нее и тогда они будут врубаться. Или вообще вставить путь до своего софта, тогда сможешь перехватить запуск любой программы через шелл-оболочку, но вызовы в обход shell32 будут игнорироваться. Чтобы и их ловить надо поставить фильтр в драйвере через ntoskrnl.exe!PsSetCreateProcessNotifyRoutine

Т.е попробуй из любого кода на нативном языке ( делфи/си и т.д ) вызвать ShellExecute(0, "open", "file.txt", 0, 0, SW_SHOW) - откроется нотпад с файлом, а если пропишешь CreateProcess утебя вернет ошибку