не совсем ясно зачем каждый раз выделять память под структуру FileInfo, можно ли обойтись без этого штатными средствами или это уже надо на уровень WinAPI ?
А также хотелось бы получить размер физически на диске сколько занимает файл.
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Re: Можно ли получить размер файла не выделяя память
Здравствуйте, okon, Вы писали:
O>не совсем ясно зачем каждый раз выделять память под структуру FileInfo, можно ли обойтись без этого штатными средствами или это уже надо на уровень WinAPI ?
А как надо ?
O>А также хотелось бы получить размер физически на диске сколько занимает файл.
Пожалуйста: GetFileSizeEx.
Только нужно сначала файл открыть через CreateFile, а для этого надо выделять память для IntPtr
Здравствуйте, okon, Вы писали:
O>не совсем ясно зачем каждый раз выделять память под структуру FileInfo, можно ли обойтись без этого штатными средствами или это уже надо на уровень WinAPI ?
Что из себя по вашему представляет процедура получения размера файла и почему выделение памяти вдруг имеет какое-то значение? Вы же не собираетесь "оптимизировать" (чтобы побыстрее и поменьше выделений памяти) всю цепочку вызовов написав свой драйвер?
И как обычно, можно глянуть на исходники, очень многие вопросы пропадают: да, это винапи, по сути вызывается метод который получает всю информацию о файле и да, разработчики winapi не видели проблемы вернуть кучу всего.. ай ай ай.
O>А также хотелось бы получить размер физически на диске сколько занимает файл.
Чем это число отличается? Вы о потерянных байтах или общем размере данных + описание файла? Вы же понимаете, что для разных файловых систем это число будет отличаться?
---
ПроГLамеры объединяйтесь..
Re[2]: Можно ли получить размер файла не выделяя память
Здравствуйте, Sinatr, Вы писали:
S>... и почему выделение памяти вдруг имеет какое-то значение?
Потому что это замедляет работу?
S> Вы же не собираетесь "оптимизировать" (чтобы побыстрее и поменьше выделений памяти)
Ну вот из-за таких рассуждений клоуны из M$ и сделали "всё или ничего". Хотя казалось бы, наструя козе баян??
Я почему обратил внимание на этот вопрос... да потому что сам не раз сталкивался с подобным! Вместо "побырому" получить список файлов и их размеры (что наверняка хранится в одном системном файле-директории, читаемом за раз), мы нудно запрашиваем каждый файл со всеми атрибутами, чтобы узнать единственное 8-байтовое число. Тупо!
Я сам сторонник изящного и универсального API, но извините, наверное не дураки придумали тот же File.WriteAllText ! Казалось бы, зачем? Открывай файл, мудри со stream'ами, пиши побайтово, снова закрывай... Универсально же! Но вот нет, кто-то всё же осознал, сколько абсолютно ненужного дерьма нужно сделать, чтобы тупо сбросить конфигурацию на диск! То же и с файлами — одна лишняя GetFileSizes не помешала бы.
И потом, для подобных вещей есть vote — если хотя бы десяток людей найдут эту функцию полезной, значит уже есть десяток применений подобным "сокращателям". Меньше кода — меньше ошибок.
Re[3]: Можно ли получить размер файла не выделяя память
Здравствуйте, Kolesiki, Вы писали:
K>И потом, для подобных вещей есть vote — если хотя бы десяток людей найдут эту функцию полезной, значит уже есть десяток применений подобным "сокращателям". Меньше кода — меньше ошибок.
Vote только должно быть деньгами. Проектирование, реализация, тестирование, и вечная поддержка фич, которые нужны всего десяти человекам, стоят слишком дорого.
Re[3]: Можно ли получить размер файла не выделяя память
Здравствуйте, Kolesiki, Вы писали: K>Я почему обратил внимание на этот вопрос... да потому что сам не раз сталкивался с подобным! Вместо "побырому" получить список файлов и их размеры (что наверняка хранится в одном системном файле-директории, читаемом за раз), мы нудно запрашиваем каждый файл со всеми атрибутами, чтобы узнать единственное 8-байтовое число.
А задуматься, почему так? Вот писали же явно не идиоты, а так сделали... Почему? Никогда не было интересно? На самом деле "размер файла" это не размер занимаемого файлом дискового пространства, а размер текущего потока данных. И это не фишка Microsoft, это Apple намутила в макинтошах. Правда потом забила, но у мелкомягких обратная совместимость это святое.
Всё, что нас не убивает, ещё горько об этом пожалеет.
Re[3]: Можно ли получить размер файла не выделяя память
Здравствуйте, Kolesiki, Вы писали:
K>Здравствуйте, Sinatr, Вы писали:
S>>... и почему выделение памяти вдруг имеет какое-то значение?
K>Потому что это замедляет работу?
даже не на миллисекунду. если эти накладные расходы кому-то там сильно важны, то могут спуститься на низкий уровень самостоятельно и сделать всё максимально быстро.
S>> Вы же не собираетесь "оптимизировать" (чтобы побыстрее и поменьше выделений памяти)
K>Ну вот из-за таких рассуждений клоуны из M$ и сделали "всё или ничего". Хотя казалось бы, наструя козе баян??
K>Я почему обратил внимание на этот вопрос... да потому что сам не раз сталкивался с подобным! Вместо "побырому" получить список файлов и их размеры (что наверняка хранится в одном системном файле-директории, читаемом за раз), мы нудно запрашиваем каждый файл со всеми атрибутами, чтобы узнать единственное 8-байтовое число. Тупо!
Клоуны из МС знали о существовании разных файловых систем и не завязывались на какой-то там системный файл-директорию.
МС пишут средней паршивости код для прикладного ПО. Пишите системную утилиту и важна скорость подобных операций — добро пожаловать в суровый мир, в котором оптимизацией придётся заниматься самостоятельно.
Не удобен имеющийся API — всегда можно сделать свою обёртку.
K>Я сам сторонник изящного и универсального API, но извините, наверное не дураки придумали тот же File.WriteAllText ! Казалось бы, зачем? Открывай файл, мудри со stream'ами, пиши побайтово, снова закрывай... Универсально же! Но вот нет, кто-то всё же осознал, сколько абсолютно ненужного дерьма нужно сделать, чтобы тупо сбросить конфигурацию на диск! То же и с файлами — одна лишняя GetFileSizes не помешала бы.
public static void WriteAllText(string path, string contents)
{
if (path == null)
throw new ArgumentNullException(nameof(path));
if (path.Length == 0)
throw new ArgumentException(SR.Argument_EmptyPath, nameof(path));
using (StreamWriter sw = new StreamWriter(path))
{
sw.Write(contents);
}
}
Как же много дерьма делает этот замечательный метод. Вот уж метод-спаситель. Главное — самому подобное для размеров файлов написать нельзя, нужно ждать реализации от МС, а лучше не ждать, а требовать, ведь они должны.
Только вызов этого метода тоже приводит к накладным расходам, а значит он замедляет работу.
K>И потом, для подобных вещей есть vote — если хотя бы десяток людей найдут эту функцию полезной, значит уже есть десяток применений подобным "сокращателям". Меньше кода — меньше ошибок.
Можно подумать люди не будут голосовать за фичи. Даже если человеку метод не нужен, он за него проголосует, потому что: пусть будет, вдруг понадобится.
Re[2]: Можно ли получить размер файла не выделяя память
Здравствуйте, Sinatr, Вы писали:
S>Здравствуйте, okon, Вы писали:
O>>не совсем ясно зачем каждый раз выделять память под структуру FileInfo, можно ли обойтись без этого штатными средствами или это уже надо на уровень WinAPI ? S>Что из себя по вашему представляет процедура получения размера файла и почему выделение памяти вдруг имеет какое-то значение? Вы же не собираетесь "оптимизировать" (чтобы побыстрее и поменьше выделений памяти) всю цепочку вызовов написав свой драйвер?
Данные в любом случае хранятся в виде таблицы и если мне надо посчитать суммарные размеры файлов в большом каталоге где миллион файлов то достаточно было бы считать эту таблицу и просуммировать данные.
А не делать new FileInfo миллион раз, про memory traffic возможно слышали.
S>И как обычно, можно глянуть на исходники, очень многие вопросы пропадают: да, это винапи, по сути вызывается метод который получает всю информацию о файле и да, разработчики winapi не видели проблемы вернуть кучу всего.. ай ай ай.
O>>А также хотелось бы получить размер физически на диске сколько занимает файл. S>Чем это число отличается? Вы о потерянных байтах или общем размере данных + описание файла? Вы же понимаете, что для разных файловых систем это число будет отличаться?
Физический размер файла это сколько места он физического отъедает у диска, например файл с 1м символом в 1 байт может отъедать 4Kb места, и мне не хотелось бы знать какая сейчас файловая система и ее опциии и считать это вручную.
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Re[3]: Можно ли получить размер файла не выделяя память
Здравствуйте, okon, Вы писали:
O>Данные в любом случае хранятся в виде таблицы
Да, если представить volume в качестве таблицы байт или кластеров — то точно в виде таблицы. Не поспоришь.
Предлагаете получать размеры файлов через прямой доступ к данным диска?
Re[3]: Можно ли получить размер файла не выделяя память
Здравствуйте, okon, Вы писали:
O>Данные в любом случае хранятся в виде таблицы и если мне надо посчитать суммарные размеры файлов в большом каталоге где миллион файлов то достаточно было бы считать эту таблицу и просуммировать данные.
Именно так и делают всякие Partition Magic и прочий низкоуровневый софт. Они знают как физически представлена файловая система (ФС) и для работы им достаточно низкоуровневых функций драйвера, чтобы читать/писать байты по секторам.
Windows работает немного подругому. У нее есть абстракция, которая будет работать с любой ФС одинаково, и системный, и прикладной софт работают через эту абстракцию. Да, возможно там не максимально оптимизировано под вашу задачу. Но вы серьезно готовы погрузится в шестнадцатиричный мир, чтобы все так же читать данные с диска, все так же использовать немного кеша, немного памяти (чтобы хранить отпарсенную инфу), чтобы сэкономить несколько байт в самом-самом конце?
O>А не делать new FileInfo миллион раз, про memory traffic возможно слышали.
Совершенно не проблема. На фирме, где я работаю, USB прибор и мегабайты трафика, причем под каждый маааленький пакет выделяется память и совершенно не было никакой нужды ничего оптимизировать. GC cправляется.
Если бы вы рассказали нам о некоей существующей проблеме, показали код, то да, возможно, что одно из решений проблемы было бы написание собственного драйвера или работа в обход OS. Впрочем скорее всего, решение бы уже было, в виде какой-то библиотеки. А так вы просто спрашиваете, что очень похоже на предварительную оптимизацию, а это зло.
O>Физический размер файла это сколько места он физического отъедает у диска, например файл с 1м символом в 1 байт может отъедать 4Kb места, и мне не хотелось бы знать какая сейчас файловая система и ее опциии и считать это вручную.
И.. зачем? Как это будет использоваться? Просто "показать" или вы решаете некую проблему, о которой пока ничего не сказали и тогда все обсуждение впустую, т.к. ваш вопрос об оптимизации получения размера файла не решает проблему целиком или даже просто всего лишь один из вариантов решения части проблемы, возможно далеко не самый оптимальный (см. XY problem).
Скорее всего вам понадобится библиотека, умеющая работать с различными файловыми системами на низком уровне, где это уже все есть: получение размера файл, получение физического размера и что-там вам еще дальше понадобится, чтобы закончить то, что вы пишете.
---
ПроГLамеры объединяйтесь..
Re[4]: Можно ли получить размер файла не выделяя память
Здравствуйте, Sinatr, Вы писали:
S>Скорее всего вам понадобится библиотека, умеющая работать с различными файловыми системами на низком уровне, где это уже все есть: получение размера файл, получение физического размера и что-там вам еще дальше понадобится, чтобы закончить то, что вы пишете.
И это все не будет работать с устройством, подключенным к винде, либо иметь значительные расхождения по информации, измененной через операционную систему. Кэш ОС, стек драйверов файловой системы, драйвер устройства, контроллер устройства, буфер устройства — все эти штуки могут содержать измененную информацию, которая еще не легла "на пластины" или в ячейки памяти.
Re[4]: Можно ли получить размер файла не выделяя память
Здравствуйте, Sinatr, Вы писали:
S>Здравствуйте, okon, Вы писали:
O>>Данные в любом случае хранятся в виде таблицы и если мне надо посчитать суммарные размеры файлов в большом каталоге где миллион файлов то достаточно было бы считать эту таблицу и просуммировать данные.
S>Именно так и делают всякие Partition Magic и прочий низкоуровневый софт. Они знают как физически представлена файловая система (ФС) и для работы им достаточно низкоуровневых функций драйвера, чтобы читать/писать байты по секторам.
S>Windows работает немного подругому. У нее есть абстракция, которая будет работать с любой ФС одинаково, и системный, и прикладной софт работают через эту абстракцию. Да, возможно там не максимально оптимизировано под вашу задачу. Но вы серьезно готовы погрузится в шестнадцатиричный мир, чтобы все так же читать данные с диска, все так же использовать немного кеша, немного памяти (чтобы хранить отпарсенную инфу), чтобы сэкономить несколько байт в самом-самом конце?
Я бы предполагал что в OS есть такая абстракция, достаточно кликнуть по файлу и посмотреть Properties. Там отображается как Size так и Size on Disk, скорее всего это обычные средства системы.
Задача не столь в экономии байт а в исключении не нужных выделений памяти, т.е. я понимаю что WinAPI все равно выделит и вернет структуру, но не хотелось бы эту структуру еще заворачивать в одну обертку и дополнительно для нее выделять память.
Оператор new достаточно ресурсоемкий не говоря уже о GC.Collect.
O>>А не делать new FileInfo миллион раз, про memory traffic возможно слышали. S>Совершенно не проблема. На фирме, где я работаю, USB прибор и мегабайты трафика, причем под каждый маааленький пакет выделяется память и совершенно не было никакой нужды ничего оптимизировать. GC cправляется.
Все зависит от скорости сколько объектов выделяется в секунду. Мегабайты трафика это не очень много.
S>Если бы вы рассказали нам о некоей существующей проблеме, показали код, то да, возможно, что одно из решений проблемы было бы написание собственного драйвера или работа в обход OS. Впрочем скорее всего, решение бы уже было, в виде какой-то библиотеки. А так вы просто спрашиваете, что очень похоже на предварительную оптимизацию, а это зло.
Это не то чтобы предварительная оптимизация, а разбор можно ли сделать проще и лучше. т.к new FileInfo(filename).Length и выглядит страшновато, особенно в цикле где миллионы файлов и траффик создает.
O>>Физический размер файла это сколько места он физического отъедает у диска, например файл с 1м символом в 1 байт может отъедать 4Kb места, и мне не хотелось бы знать какая сейчас файловая система и ее опциии и считать это вручную.
S>И.. зачем? Как это будет использоваться? Просто "показать" или вы решаете некую проблему, о которой пока ничего не сказали и тогда все обсуждение впустую, т.к. ваш вопрос об оптимизации получения размера файла не решает проблему целиком или даже просто всего лишь один из вариантов решения части проблемы, возможно далеко не самый оптимальный (см. XY problem).
Как зачем , чтобы определить сколько места освободиться на диске при удалении, ри большом количестве мелких файлов разница может быть в несколько раз ( объем данных и объем на диске )
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Re[5]: Можно ли получить размер файла не выделяя память
Здравствуйте, okon, Вы писали:
O>Это не то чтобы предварительная оптимизация, а разбор можно ли сделать проще и лучше. т.к new FileInfo(filename).Length и выглядит страшновато, особенно в цикле где миллионы файлов и траффик создает.
Если это холодный запуск, то как уже сказали выше забейте. Получить информацию о файлах с физического носителя (особенно HDD) займет намного больше времени, чем выделение/освобождение памяти под структуру и заполнение ее.
Если горячий (данные о файлах уже в кеше носителя или даже OS), то будет побыстрее и да, по идее можно было бы немного ускорить. Но если файлов мало — то вы не заметите разницу. А если много — то возможно данные для всех файлов в кеш не поместятся — см. выше.
O>Как зачем , чтобы определить сколько места освободиться на диске при удалении, ри большом количестве мелких файлов разница может быть в несколько раз ( объем данных и объем на диске )
Да вот так зачем. Вы хотите показать пользователю, удаляющему группу (миллион?) файлов, сколько у него освободится места с точность до байта? Зачем эму это? Или это миллион очень маленьких файлов и тогда сумма их размеров сильно отличается от размера занимаемых байт на диске из-за кластеров? Дык не показывайте вообще ничего. Или покажите в конце удаления сколько свободного места стало или разницу.
---
ПроГLамеры объединяйтесь..
Re: Можно ли получить размер файла не выделяя память
Здравствуйте, okon, Вы писали:
O>Стандарный способ получить размер файла на C# это
O>
O>new FileInfo(path).Length
O>
O>не совсем ясно зачем каждый раз выделять память под структуру FileInfo, можно ли обойтись без этого штатными средствами или это уже надо на уровень WinAPI ? O>А также хотелось бы получить размер физически на диске сколько занимает файл.
1) Очень часто кроме размера файла нужны ещё какие-то его характеристики. Новые запросы — опять дерибанить файловую систему, а она может быть занята другими делами.
2) Как уже указали выше, атомарные операции есть, но это Win32 API. А его всеми силами пытаются закопать (и это правильно, ИМХО).
Re[4]: Можно ли получить размер файла не выделяя память
Здравствуйте, karbofos42, Вы писали:
K>>Потому что это замедляет работу?
K>даже не на миллисекунду. если эти накладные расходы кому-то там сильно важны, то могут спуститься на низкий уровень самостоятельно и сделать всё максимально быстро.
С такой пофигистической логикой я и операционку могу написать "если сильно важно"! Но я не хочу. Мне нужны эффективные методы стандартными средствами платформы. Тем более, что за 15 лет пинания половых органов, мелкомягкие клоуны могли бы и улучшить код многих компонент.
K>Клоуны из МС знали о существовании разных файловых систем и не завязывались на какой-то там системный файл-директорию.
Венда один фиг работает на NTFS. FAT32 — для флешек, но и там директория — ОДИН ФАЙЛ. В любом случае, этот файл загружается разом.
K>МС пишут средней паршивости код для прикладного ПО.
Ну, сама M$ немного не так себе представляет свою .NET! Это платформа, где нет места для "средней паршивости", ибо никаких ресурсов нехватит!
K>> наверное не дураки придумали тот же File.WriteAllText !
K> public static void WriteAllText(string path, string contents)
K>Как же много дерьма делает этот замечательный метод.
Вы, мадам, логику слишком женскую применяете. Речь вообще не о WriteAllText, сюрприз! Сам додумайся почему.
K>Главное — самому подобное для размеров файлов написать нельзя
Я уже отвечал на подобную глупость: можно написать ВООБЩЕ ВСЁ. Только зачем?? Я не Дункан Маклауд, у меня времени мало! А у пинателей пенисов из M$ — много (это я сужу по той ахинестической лабуде, которую они называют "улучшениями" и гонят последние 10 лет).
K>>И потом, для подобных вещей есть vote — если хотя бы десяток людей найдут эту функцию полезной, значит уже есть десяток применений подобным "сокращателям". Меньше кода — меньше ошибок.
K>Можно подумать люди не будут голосовать за фичи. Даже если человеку метод не нужен, он за него проголосует, потому что: пусть будет, вдруг понадобится.
И что в этом плохого/криминального? Всяко полезнее, чем тупорылые пистоны и тайпскрипты прикручивать! А выбор git как VCS вообще убил наповал. Хотя почему убил?... От индусофта это вполне ожидаемо.
Re[3]: Можно ли получить размер файла не выделяя память
Здравствуйте, okon, Вы писали:
O>Данные в любом случае хранятся в виде таблицы и если мне надо посчитать суммарные размеры файлов в большом каталоге где миллион файлов то достаточно было бы считать эту таблицу и просуммировать данные. O>А не делать new FileInfo миллион раз, про memory traffic возможно слышали.
EnumerateFiles И GetFiles методы имеют следующие различия: При использовании EnumerateFiles, можно запустить выполнение перечисления коллекции имен перед возвращением всей коллекции; при использовании GetFiles, необходимо дождаться весь массив имен возвращается, чтобы можно было открыть массива. Таким образом, при работе с много файлов и папок, EnumerateFiles может оказаться более эффективным.
With best regards
Pavel Dvorkin
Re[5]: Можно ли получить размер файла не выделяя память
Здравствуйте, okon, Вы писали:
O>>>Физический размер файла это сколько места он физического отъедает у диска, например файл с 1м символом в 1 байт может отъедать 4Kb места, и мне не хотелось бы знать какая сейчас файловая система и ее опциии и считать это вручную.
Это если эта метрика может быть однозначно определена без учёта файловой системы (и не удаляя файл); а на самом деле нет.
O>Как зачем , чтобы определить сколько места освободиться на диске при удалении, ри большом количестве мелких файлов разница может быть в несколько раз ( объем данных и объем на диске )
Этот вопрос подразумевает, что вообще возможно определить, сколько места освободится на диске при удалении. В общем случае это невозможно, можно только удалить и посмотреть, что получилось.
Например, если стереть много мелких файлов на NTFS, свободного места на диске не прибавится. А если на FAT, то прибавится. А потом нужно учесть, что всё то же самое API должно бы работать с сетевыми дискаим, а что на той стороне сетевого диска — вообще закачаешься.
Здравствуйте, Sinatr, Вы писали:
S>Здравствуйте, okon, Вы писали:
O>>Это не то чтобы предварительная оптимизация, а разбор можно ли сделать проще и лучше. т.к new FileInfo(filename).Length и выглядит страшновато, особенно в цикле где миллионы файлов и траффик создает.
S>Если это холодный запуск, то как уже сказали выше забейте. Получить информацию о файлах с физического носителя (особенно HDD) займет намного больше времени, чем выделение/освобождение памяти под структуру и заполнение ее. S>Если горячий (данные о файлах уже в кеше носителя или даже OS), то будет побыстрее и да, по идее можно было бы немного ускорить. Но если файлов мало — то вы не заметите разницу. А если много — то возможно данные для всех файлов в кеш не поместятся — см. выше.
Попробовал на 1 млн файлов разница где-то 6 секунд между методом new FileInfo().Length и GetFileSizeEx() на фоне общих 40 сек это плата 15% времени за баловство с new FileInfo().
O>>Как зачем , чтобы определить сколько места освободиться на диске при удалении, ри большом количестве мелких файлов разница может быть в несколько раз ( объем данных и объем на диске )
S>Да вот так зачем. Вы хотите показать пользователю, удаляющему группу (миллион?) файлов, сколько у него освободится места с точность до байта? Зачем эму это? Или это миллион очень маленьких файлов и тогда сумма их размеров сильно отличается от размера занимаемых байт на диске из-за кластеров? Дык не показывайте вообще ничего. Или покажите в конце удаления сколько свободного места стало или разницу.
Очень не удобно когда не понимаешь сколько места освободиться, можно удалить одно а дьявол будет сидеть в другом месте, тут порядок разницы совсем не в байтах и килобайтах может быть.
Например миллион файлов общим объемом ~ 1 Мб после удаления освобождают 200 Mb, в 100 раз больше объема чем их реальный размер.
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Re[6]: Можно ли получить размер файла не выделяя память
Здравствуйте, Sharowarsheg, Вы писали:
S>Здравствуйте, okon, Вы писали:
O>>>>Физический размер файла это сколько места он физического отъедает у диска, например файл с 1м символом в 1 байт может отъедать 4Kb места, и мне не хотелось бы знать какая сейчас файловая система и ее опциии и считать это вручную.
S>Это если эта метрика может быть однозначно определена без учёта файловой системы (и не удаляя файл); а на самом деле нет.
По идее файловая система должна иметь возможность предоставить эту информацию, бывает что не поддерживается, но это должно быть так как со всеми остальными API — возвращается ошибка not supported
Если fs предоставляет информацию то нормальная система должна ею воспользоваться и сделать эту операцию быстрее.
O>>Как зачем , чтобы определить сколько места освободиться на диске при удалении, ри большом количестве мелких файлов разница может быть в несколько раз ( объем данных и объем на диске )
S>Этот вопрос подразумевает, что вообще возможно определить, сколько места освободится на диске при удалении. В общем случае это невозможно, можно только удалить и посмотреть, что получилось. S>Например, если стереть много мелких файлов на NTFS, свободного места на диске не прибавится. А если на FAT, то прибавится. А потом нужно учесть, что всё то же самое API должно бы работать с сетевыми дискаим, а что на той стороне сетевого диска — вообще закачаешься.
Стер 1 млн файлов в NTFS освободилось 200 Mb места ( размер данных у файлов 1 Мб в среднем по 1 байту на файл ).
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
