Размер ("вес" в общеупотребительной терминологии) файла не зависит от операционной системы (ладно, он может в некоторых случаях различаться в представлении пользователю). Вообще тут налеплено несколько слоёв абстракций, и для полного и интересного ответа нужно разобраться с ними всеми.
Итак, первый уровень - физический носитель. Данные можно хранить кучей способов, сейчас наиболее распространены магнитные (HDD/ленточные накопители), оптические (CD/DVD/BR/etc) и твердотельные (Flash/SSD) носители. Это далеко не все варианты, конечно.
На каждом носителе цифровые данные хранятся в своём аналоговом представлении: в виде разницы магнитного поля/наличия электрического заряда/формы участка поверхности. На этом уровне нет никаких файлов, папок, структуры, ничего - есть просто запись сигналов, вид и размер этой записи оптимален для этого конкретного носителя (ну или стремится к таковому).
Второй уровень - контроллер, штука, которая превращает аналоговую запись в цифровой вид и обратно (с учётом всех особенностей носителя определяет чего куда и как писать). Тут тоже нет файлов и прочего, только набор бит. Эта штука управляется собственным набором команд, которые более-менее стандартизированы, хотя и с кучей всяких интересных особенностей.
К примеру, SSD (твердотельный flash) аппаратно устроены так, что интерфейсы взаимодействия с HDD (намагниченные диски) для них не оптимальны. Однако производители вынуждены в целях совместимости реализовывать именно такие интерфейсы, а на контроллер ложится задача переводить команды в нечто своё.
Уровнем выше - драйвер файловой системы. Это уже программа, которая знает о файлах, каталогах, их атрибутах и прочем. Её задача - дать операционной системе удобный интерфейс взаимодействия с одной стороны, а с другой стороны - обеспечить аппаратному устройству ввод/вывод. То есть, когда операционная система передаёт драйверу команду "создай файл по пути /x/abc и запиши в него последовательность символов xyz", драйвер переводит эту команду в набор команд устройства и отправляет ему по аппаратному каналу (ох, этот уровень я, пожалуй, пропущу, для ответа он не так уж важен). Для чтения данных готовит другой набор команд, ну и т.д.
Ещё драйвер обычно занимается другими полезными вещами (следит за целостностью и устойчивостью ФС, обеспечивает разграничение доступов, и много чего ещё) но это уже за рамками ответа.
Вот мы и добрались непосредственно до файловой системы - нужного нам уровня абстракции, на котором можно говорить о наиболее привычной концепции размера. И теперь создаём в файловой системе каталог.
Кстати, файловая система может вообще ничего не знать о каталогах, ну вот просто не предоставлять такого понятия. В исходном FAT все файлы, например, лежали рядом, и ничего.
Но наша ФС о каталогах знает. Правда, мы не знаем какая это файловая система: Windows 10 поддерживает как минимум несколько версий NTFS/FAT/EXFAT/ISO/UDF, тем или иным образом можно добавить поддержку ext*, а если начать говорить о FUSE-реализациях и смежных областях, то мы запросто улетаем в бесконечность вариантов.
Думаете это всё? Фигушки, файловая система может реализовать каталог разными способами. Это может быть отдельная запись в служебном разделе, это может быть атрибут файла, каталог вообще может не существовать до появления в нём содержимого (в этом случае "пустого каталога" просто не существует). Это вообще этакая абстракция, придуманная для удобного представления файловых списков.
Но мы ограничим себя вариантами NTFS и FAT, где все известно и привычно, но, при этом, реализовано совершенно по разному.
В FAT данные о структуре хранятся в таблице (сначала хотел написать примитивной, но таковой её можно считать только относительно), в которой файл - это запись с кучей полей (имя, атрибуты доступа, метки времени создания/обновления, размера, около дюжины всего, а в VFAT - ещё полстолько) и ссылкой на данные. Заметьте, что размер здесь - это атрибут, который обновляется драйвером по факту; никто не мешает открыть носитель специальным редактором, найти этот участок данных и в обход ФС записать туда произвольное значение, которое, в результате, отобразит операционная система. По факту же размером можно считать суммарный размер кластеров, занимаемых данными файла. Ага, ещё одно новое понятие: при форматировании в FAT устанавливается размер кластера - некой минимальной области хранения данных, нужный для оптимизации адресации данных; один файл всегда занимает минимум один кластер, и раньше существовали целые стратегии выбора оптимального размера кластера под хранение тех или иных данных. Минимальный допустимый размер кластера - 512 байт, максимальный - 64 килобайта.
Каталог в этой ФС - это файл со специальной меткой, принудительно нулевым размером и всегда содержащий два пустых файла "." и "..". Эти файлы, кстати, реально пустые, поскольку обрабатываются именно драйвером, для них кластерная адресация особая. А вот для самого каталога кластер выделяется и - та-да! - забивается нулями.
Таким образом пустой каталог в FAT будет занимать от 512 байт до 64 килобайт выделенного места + место, занятое записью в файловой таблице (разнится от реализации к реализации).
С современной точки зрения, FAT - это такой набор костылей и примеров того как не надо делать. Но она реально простая и изученная вдоль и поперёк, а если хотите сложный вариант, то взглянем на NTFS.
NTFS - уже не таблица, а дерево, что интереснее, сложнее и выгоднее. Данные о файлах раскиданы в ней аж по нескольким служебным разделам, обобщённо называемым MFT, это как бы файлы, но особенные, скажем драйвер запрещает операционной системе с ними взаимодействовать (но, опять же, никто не мешает использовать специальные средства). И с этими разделами происходит такая хитрая чехарда, что чёрт ногу сломит: в зависимости от кучи параметров (размер хранилища, свободное место, количество файлов, фаза Луны) MFT может перестраиваться, фрагментироваться и оптимизироваться, атрибуты файлов могут храниться в MFT а могут не храниться, данные о каталогах могут резидентно храниться в MFT, а могут и не храниться. Но в целом можно рассчитывать на то, что одна минимальная запись в MFT занимает 1 килобайт, хотя из-за других особенностей ФС это знание ничего особенного нам не даст.
А теперь внимание, фокус: записи про существующий каталог в MFT может и не быть. Ну то есть она там, скорее всего будет, но если нет - ничего особенного, теоретически, не случится. Все файлы содержат в атрибутах имя родительского каталога, так что структура дерева ФС может быть построена и без этого (но если нужные данные есть в MFT - то построение структуры будет быстрее). Как раз случай, когда каталога как бы нет, но он, как бы есть, хотя бы в виде атрибута файла.
Ах да! Атрибуты (и сами данные) могут ведь быть зашифрованы и/или сжаты.
Вы всё ещё хотите копать дальше? Я, честно говоря, утомился, поэтому сразу возьмём некий граничный случай: однокилобайтовую запись о пустом файле, лежащем в каталоге, данных о котором нет в MFT. Да, каталог не будет пустым, но считая размер для пустого конкретного каталога мы рискуем защитить диссертацию.
Подытожу: в зависимости от того
P.S. Речь изначально шла о папках, но я не стал углубляться в различия между папками и каталогами - обычно одно называют другим ровно также, как размер файлов называют весом.