Ответ: Примечательные изображения
 

:4to:

Вложение 21991

кто-то перепутал floor и ceil? Всегда же было округление до размера кластера ФС...

Ответ: Примечательные изображения
 

Или это ошибка в ФС.

Ответ: Примечательные изображения
 

Вероятно - результат эксплуатации windows разреженных файлов.
http://geektimes.ru/post/78018/
https://ru.wikipedia.org/wiki/Разрежённый_файл
т.е. этот маленький файлик был размещён в чьей-то "дыре".
Во всяком случае, если его архивровать/разархивровать - размер на диске = 0.
Если скачать его одного с почты - размер аж 8 кб, вместе с группой файлов (с которой он хранится) архивом и извлечь : его и ещё одного мелкого файла - по нулю.
upd4: в первом случае, вероятно, браузер сразу резервирует полный размер (чтобы выполнить докачку), а во втором случае - архиватор уже извлекает файл, создавая его другим api-вызовом, позволяя ОС оптимизировать хранение.

upd: вспомнил, что пару недель назад создавал ещё один мелкий файл (в другой директории), который затем успешно синхронизировал при помощи съёмного носителя на других компах. Глянул - он тоже 0 байт (размер на диске). Вообще - много тут людей проверяет размер на диске да ещё мелких файлов (которые и так априори всюду "влезут")?

upd2: откопал файл аж за март прошлого года. Тоже - "0 байт на диске".
upd3:откопал файл за июнь 2013-ого - тот же эффект. Все файлики - несколько сотен байт.

Ответ: Примечательные изображения
 

Да забей кол на его месте, у меня таких файлов гора.
Как минимум 10 нашел, за минуту:


Они были созданы вообще под убунту, так что твои домыслы теряют смысл.

UPD: И вообще все файлы, которые были созданы в бубунте и меньше 512 байт = 0б (бывают исключения, но редко), вот такая закономерность.
UPD: в папке с nodeJS эти файлов просто дофига
UPD: что-то второй закон термодинамики не выполняется походу: куча файлов по 0b, суммарно 0, а данные то есть...
UPD: смущает тот факт, что второй файл из оффтопа выше был создан позже, чем изменен.

Ответ: Примечательные изображения
 

Спасибо за интерес и проведённый анализ.
Дата создания может быть присвоена в момент копирования файла:
создал, допустим в 12:00 на одном компе, в 12:30 внёс правки, потом вылил, например на флешку, а с неё на другой комп - будет именно этот эффект: дата создания - момент появления файла на данном компе, а дата изменения 12:30.
Вообще, с точки зрения менеджемента данных, наиболее важный критерий - именно дата изменения (хотя 2003 PowerPoint любил менять внутренности файла, оставляя старую дату изменения файла; а *.eml-файлы, в силу логики своего изначально смысла, обновляют дату в момент просмотра папки с ними виндовым проводником). Например, старые версии FreeFileSync использовали дату создания файла (как менее важную) для универсализации (кодировали в ней свою информацию), т.к. в FAT и NTFS даты хранятся в разных форматах (региональном или GMT) и без дополнительных мер, при переходе на зимнее/летнее время, алгоритм выдавал погрешность в 1 секунду (т.е. до перевода файлик был якобы изменён в 12:30:00, а через несколько часов, после перевода стрелок, уже детектируется виндой на флешке как 12:30:01,а на винте - 12:30:00). Кстати - один из плюсов, что в РФ перестали двигать стрелки.
На совместно используемом виндой и убунту винте? Хотя и в этом случае - это фича ФС. Другое дело - пользуется ли фичей операционка.
Они хранятся совместно с данными разреженного файла, поэтому фактически на диске ничего не весят. После копирования на носитель, где соответствующего разреженного файла нет - они снова приобретают размер с округлением до кластера.

Ответ: Примечательные изображения
 

Да, использую этот раздел для синхронизации винды и бубунты, конечно можно дрова ext4 поставить в винду, но есть опасность поломать раздел.

Ответ: Примечательные изображения
 

Скорее всего, так и есть! Я тоже об этом подумал... Вообще, для таких мелких файлов используют ФС с маленькими кластерами.