LINUX.ORG.RU

Вышли новые версии ntfsprogs - 1.12.0 и 1.12.1.


0

0

В ntfsmount появилась возможность в некоторых случаях создавать/удалять файлы и директории, делать жесткие ссылки на файлы. В созданных ntfsmount директориях можно создать до 10 файлов/под-директорий до того как ntfsmount начнет возвращать 'Operation not supported'.

>>> Скачать

10/10/2005 - 1.12.1 - Minor fix to location of mount.ntfs-fuse and mkfs.ntfs.

        - Fix hardcoded location for uninstalling mount.ntfs-fuse hardlink to
          match the relocatable location for installing it.  (Anton, Szaka)
        - Move mount.ntfs-fuse and mkfs.ntfs to be symlinks instead of
          hardlinks and move both to /sbin rather than prefix/sbin.  Note we
          still obey $destdir so building packages works as well as installing
          into alternate chroot / other system still works.  (Anton)
        - ntfscmp: fix some corner cases and all memory leaks; handle corrupt
          NTFS more gracefully.  (Szaka)
        - If the system does not have realpath(), supply our own dummy version
          which just copies the string without any kind of checking or
          expansion.  (Anton)

07/10/2005 - 1.12.0 - Lots of fixes and enhancements!

        - Add ./configure detection for gnutls library and make minimum version
          1.2.3 which is the one that has the rsa key export fixed.  (Anton)
        - Put in a minimum version for libgcrypt of 1.2.0 as I do not know if
          our code works with earlier versions.  (Anton)
        - Fix some memory leaks in ntfsdecrypt and do some cleanups.  (Anton)
        - Fix ntfsdecrypt to also work with passwordless files.  Note this
          requires a patched gnutls library or it still does not work.  (Anton)
        - Add new APIs for index adding/remove:
            index.[ch]::ntfs_index_add_filename and index.[ch]::ntfs_index_rm.
          They support only basic cases, so can fail with EOPNOTSUPP.  (Yura)
        - Add new API for index context reinitialization:
            ntfs_index_ctx_reinit.  (Yura)
        - Add new high-level APIs for file and directory creation/deletion that
          rely on ntfs_index_{add_filename,rm}:
            dir.[ch]::ntfs_create and dir.[ch]::ntfs_delete.  (Yura)
        - Add @creation_time field to struct ntfs_inode and rename [acm]time
          fields to @last_{data_change,mft_change,access}_time. Update them in
          STANDARD_INFORMATION and FILE_NAMEs during inode sync.  (Yura)
        - layout.h: Add @v1_end and @v3_end markers for offsetof to struct
          FILE_NAME_ATTR. Change type of @clusters_per_index_block from u8 to
          s8, fix error in comment. Simplify a bit INDEX_ENTRY struct.  (Yura)
        - ntfstime.h: Use cpu_to_sle64 and sle64_to_cpu in utc2ntfs and
          ntfs2utc respectively. Update all users.  (Yura)
        - Add @indx_record_size and @inx_record_size_bits to struct ntfs_volume.          Set them during mount.  (Yura)
        - attrib.c: Set RESIDENT_ATTR_IS_INDEXED flag for FILE_NAME attribute in          ntfs_attr_add.  (Yura)
        - inode.c: Do not sync STANDARD_INFORMATION and FILE_NAMEs for
          freed inodes.  (Yura)
        - mft.c: Set *time and *size fields of struct ntfs_inode in
          ntfs_mft_record_alloc.  (Yura)
        - Make ntfsmount use new APIs for file and directory creation/deletion.
          Implement utime operation.  (Yura)
        - Hard link mkfs.ntfs and mkfs.ntfs.8 with mkntfs and mkntfs.8.  (Szaka)        - Only include sys/ioctl.h in libntfs/device.c if ./configure detected
          it to be present.  (Christophe)
        - ntfscluster: fix incorrect volume usage calculation.  (Szaka)
        - ntfscluster, utils.c::mft_next_record(): fix gigaleak.  (Szaka)
        - Define PATH_MAX if not defined in ntfsprogs/ntfsmount.c and
          libntfs/volume.c.  Needed to compile on DOS with djgpp.  (Christophe)
        - Switch ntfsmount to use getopt_long.  (Yuval, minor fixes by Yura)
        - ntfsmount: Fix 'df' output.  (Yuval)
        - Support journals which have been modified by chkdsk.  (Anton, Szaka)
        - Support journals ($LogFile) with only one restart page as well as
          journals with two different restart pages.  (Anton, Szaka)
        - Add @val parameter to ntfs_attr_add and @val and @size parameters to
          ntfs_resident_attr_record_add.  (Yura)
        - Fix attribute list adding for always resident attributes.  (Yura)
        - New API for hard link creating: dir.[ch]::ntfs_link.  (Yura)
        - ntfsresize: emphasize that disk partitioning must use sector as the
          unit instead of cylinder to avoid shifting of the partition.  (Szaka)
        - Rename API: ntfs_volume_set_flags() as it is misleading.  It does not
          set a flag, it overwrites the flags!  Rename it to
          ntfs_volume_write_flags() and clean it up a lot.  Update all
          callers.  (Anton)
        - Change everything to supply an ntfs_inode and NULL for mft record
          when calling ntfs_attr_get_search_ctx() except a very few cases which
          genuinely need this functionality as they work on a too low level.
          Make sure all those cases are ok.  (Anton)
        - ntfsclone: fix saving by sectors during --rescue (Scott Hansen, Szaka)        - Fix the definition of the CHKD ntfs record magic.  It had an off by
          two error causing it to be CHKB instead of CHKD.  (Anton)
        - Add new utility ntfscmp (make extra) which compares two NTFS volumes
          and tell the differences. It's used for development, debugging,
          testing, etc.  (Szaka)
        - ntfsresize, ntfsclone: accept incorrect $Bitmap size if it covers
          the entire volume.  (Szaka)
        - mkntfs: Fix silly bug where I forgot to add the "H:S:p:" string to
          the getopt() parsing string for those options.  Cannot be used very
          often if people only now noticed!  (Anton)
        - ntfsmount: Add 'locale' option.  (Yura)
        - ntfsmount: Change interface to 'ntfsmount device mount_point'.  (Yura)        - Hardlink ntfsmount to /sbin/mount.ntfs-fuse, thus it possible mounting          from fstab by specifying ntfs-fuse filesystem type.  (Yura, Szaka)
        - Fix stupid bug in mkntfs which caused it to fail even though only the
          backup boot sector could not be written because a 2.4 kernel is used
          and the partition has an odd number of sectors.  (Anton)
        - Add API (actually renamed from what Rich/FlatCap did):
          volume.[hc]::ntfs_libntfs_version() which returns a pointer to a
          static const string of the libntfs verion, i.e. at the moment this is
          "8.0.0".  This required moving the version specifications from
          libntfs/Makefile.am to configure.ac.  This should hopefully have the
          sideeffect that I will remember to increment it when incrementing the
          ntfsprogs version number when making a release given the two are
          right under one another.  (Anton)
        - Change ALL utilities to display the libntfs version they are running
          on.  This should make debugging easier in the case that people are
          running mismatched utilities/library.  (Anton)

cha0smaster
() автор топика
Ответ на: комментарий от anonymous

Это связано с мелкомягкими)

anonymous
()
Ответ на: комментарий от anonymous

>а с чем связано отсутствие нормального ntfs супорта в линухе ?

мелкософт не публикует спецификации этой файловой системы, поэтому написать нормальную ее поддержку - дело непростое. Очень непростое.

blaster999 ★★
()
Ответ на: комментарий от anonymous

Со сложностью и отсутствием _полной_ документации к нему от M$. Да и не так уж сильно оно надо, как может показаться.

Любопытно, насколько полна документация к hpfs от IBM?

anonymous_incognito ★★★★★
()
Ответ на: комментарий от anonymous

> а с чем связано отсутствие нормального ntfs супорта в линухе ?

С тем, что M$ открыла только маленькую часть спеков на ntfs, да и ту не очень точно. :)

atrus ★★★★★
()
Ответ на: комментарий от atrus

> С тем, что M$ открыла только маленькую часть спеков на ntfs, да и ту не очень точно. :)

Жаль, что реверсить код мелкомягких в ntfs.sys религия не позволяет...

anonymous
()
Ответ на: комментарий от anonymous

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

tier
()
Ответ на: комментарий от anonymous

>Жаль, что реверсить код мелкомягких в ntfs.sys религия не позволяет...

странная у тебя такая религия

зы. а про dmca ты слышал вообще?

anonymous
()
Ответ на: комментарий от tier

Я пользуюсь тем же парагоновским драйвером. Всё там Ок. Правда оооочень редко возникает необходимоть даже простого обращения к НТФС-разделам, не то что запись/удаление на них.

vovans ★★★★★
()
Ответ на: комментарий от tier

>неужели не могут зареверсинженирить этот драйвер, как поступили в свое время с SMB...

А зачем и кому это надо? Одно дело, это совместимость в сетке, а другое дело -- убогая ФС, которая в юнихах нах никому не нужна.

vovans ★★★★★
()
Ответ на: комментарий от anonymous

>Жаль, что реверсить код мелкомягких в ntfs.sys религия не позволяет...

Если тебе позволяет и ты живешь в одной из стран, где это законно - займись. Только помни об опыте Алана Кокса, который не рискнул лететь в Штаты на конференцию, опасаясь, что там его заслуги могут увидеть с другой точки зрения.

alt-x ★★★★★
()
Ответ на: комментарий от vovans

>А зачем и кому это надо? Одно дело, это совместимость в сетке, а другое дело -- убогая ФС, которая в юнихах нах никому не нужна.

Она скорее не столько убогая, сколько действительно не нужная.

alt-x ★★★★★
()

дык вроде же все и так работало через captive с родными дровами маздайскими?

anonymous
()
Ответ на: комментарий от anonymous

captive поломали еще в 2.6.12. Не то чтобы совсем, пока что исправляется одной строчкой, но в перспективе они lufs из ядра вычистят.

Вообще говоря captive - единственное решение, которое гарантировало бы работу со всеми версиями ntfs. Но, с лицензионной точки зрения - засада.

alt-x ★★★★★
()
Ответ на: комментарий от anonymous

> дык вроде же все и так работало через captive с родными дровами маздайскими?

Captive через lufs работает. Так что сейчас приходится цирк ради него устраивать: captive -> lufs-fuse -> fuse. ;-)

atrus ★★★★★
()
Ответ на: комментарий от atrus

А кстати, captive умеет ntfs.sys из SP2? По-моему - нет. А насколько SP2 совместим c SP1 я не знаю.

alt-x ★★★★★
()
Ответ на: комментарий от anonymous

> Жаль, что реверсить код мелкомягких в ntfs.sys религия не позволяет...

Мне всё позволяет. Я не разрабатываю ntfs драйвер.

Atrus
()
Ответ на: комментарий от a1s2d3

>vovans, если ты считаешь, что ntfs убогая, то как специалист ты гроша выеденного не стоишь.

Да, да.. Какая отличная FS for NT! Только фрагментация со времением у неё растё довольно прилично. Особенно, если раздел заполнен более чем на 80%. Тогда ещё и скорость чтения/записи существенно снижается. FS for NT, значит для серверов. Разве это не убогость для серверов? Да и для дому...

vovans ★★★★★
()
Ответ на: комментарий от tier

>а я вот пользуюсь парагоновским коммерческим драйвером и горя не знаю. >пишет на нтфс отлично. проблем вообще не замечал. весь драйвер - 300 >килобайт в архиве. удивляюсь, неужели не могут зареверсинженирить этот >драйвер, как поступили в свое время с SMB...

>tier (*) (12.10.2005 9:45:45)

Интересно , где достать _этот_ драйвер ? А то выкаченная когда мною версия из осла не работала с 2.6.11 :(

anonymous
()
Ответ на: комментарий от anonymous

> Надеюсь, будет работать с 2.6.x

будет!

vovans ★★★★★
()
Ответ на: комментарий от vovans

>>к вашему сведению ext2 тоже не свободна от этого недостатка

>Да, но есть ext3 && reiserFS

ext3 отличается от ext2 только наличием журнала. Так что с этим Вы все-таки мимо.

Как решена проблема фрагментации в Райзере я не знаю. Но подозреваю, что если забить весь винт файлами небольшого размера, например фотками, или мп3, потом стереть произвольным образом половину этих файлов, заполнить это место другими файлами, после чего стереть первую полофину и снова заполнить - фрагментация будет существенная. Можете проверить.

alt-x ★★★★★
()
Ответ на: комментарий от vovans

>>к вашему сведению ext2 тоже не свободна от этого недостатка

>Да, но есть ext3 && reiserFS

У меня что на ext2, что на ext3 -- при заполнении диска на 99% (остается свободными несколько десятков/сотен Мбайт) некоторые файлы и директории просто улетают в ПИЗДУ и на диске вновь 1-2 ГБайт свободного места. Притом это происходит примерно так: копирую себе на жёсткий диск данные с CD (700 Мб) -> на диске ~150-200 Мб свободного места -> ls -> всё вроде на месте -> пару раз cd <куда-то>; cd - -> ls -> НИ ХУЯ НЕТ -> df -h выдаёт 900 Мб свободно. Подчёркиваю было и на ext2 и НА EXT3!!!

Так что вот.

anonymous
()
Ответ на: комментарий от vovans

Не совсем. 6.6 Мег это может быть всего-то два блока. И что ты измеришь в этом случае? Не говоря о том, что оно закэшировано.

Проделай эксперимент о котором я говорю. Последнее копирование будет медленнее, чем первое. Особенно если размер винта >> размера ОЗУ.

Далее. NTFS не имеет ни какого отношения к FAT32, скорее уж к HPFS, которая переводится как High Perfomance File System, которая была разработана любимой здесь IBM.

Третье. Проблему фрагментации в принципе невозможно решить без потерь производительности. Представь, что ты в полностью заполненой фс стер два файла по 10 мег, и скопировал туда один на 20 мег. Будет он фрагментирован? Да, если скопировали быстро. Если же по ходу копирования решили дефрагментирвать - копирование произойдет в 2 раза медленее, поскольку сначала надо еще место освободить. Оно нам надо?

alt-x ★★★★★
()
Ответ на: комментарий от anonymous

Не может такого быть. Если это не слака, конечно. ;-) А вообще, похоже на битую память. Или на сильно поврежденную fs. fsck пробовал пройтись?

alt-x ★★★★★
()
Ответ на: комментарий от alt-x

>6.6 Мег это может быть всего-то два блока

6.6 метров осталось после копирования большого файла. Раздел совй я уже описывал. Системный. И ему больше года. По идее, фрагментация должна быть огромной.

vovans ★★★★★
()
Ответ на: комментарий от vovans

Неубидительно. Моему текущему системному ext3 разделу уже больше трех лет, из них два последних года он забит на 98-100%. fsck тем не менее показыват фрагментацию около 6%. Точнее не помню, поскольку перезагружался 3 месяца назад. 6% - это ерунда. Я уверен, что если я бы проделал описаный выше эксперимент - мог бы получить процентов 40. Так что факт, что для reiser'a проблема фрагментации менее актуальна чем для ext3 из твоего эксперимента не вытекает.

alt-x ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.