grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] bug fix for ntfs


From: Bean
Subject: Re: [PATCH] bug fix for ntfs
Date: Mon, 23 Apr 2012 23:26:06 +0800

Hi,

2012/4/23 Vladimir 'φ-coder/phcoder' Serbinenko <address@hidden>:
> On 23.04.2012 16:41, Bean wrote:
>> Hi all,
>>
>> This patch fix three issues:
>>
>> 1, In ntfsdoc, it says namespace = 0 means POSIX and it's case
>> sensitive. However, i found out this is not sure in Windows 7 as some
>> system directory use this value as well. Now i ignore this flag and
>> treat all files in ntfs as case insensitive.
> This would be wrong. It's certаinly possible to create files differing
> only in case in POSIX namespace, so it's case-sensitive. If some system
> directory uses this namespace it's case-sensitive

Do you know any tool that can create case sensitive file in ntfs ?
ntfsdoc is not official so it can get it wrong, or MS may change the
meaning of some flags. At least I can't create file in different case
as those directories so this should mean it's case insensitive.

>> 2, Previous version doesn't return blocklist information for small
>> files embed in MFT, this patch fixes it. For example, create a
>> 512-byte file test in ntfs and try this command:
>>
>> grub-fstest /ntfs.img blocklist /test
> It looks like this part of patch has issues. Like that it doesn't handle
> the case when the read is split across 2 sectors or if MFT entry is at
> offset >=1024. Or that it adds some checks (like "invalid mft offset")
> which weren't there previously and which would make GRUB bail out on
> weird FS even if user doesn't want blocklists.

MFT in ntfs is only 1024 bytes, and it must be sector aligned, so if
this test fails, there is serious problem with the fs (or the driver).

> AFAIR MFT is duplicated and so we can't just overwrite it, also MFT can
> more easily change place. In such cases we intentionally skip the
> blocklists (like we do for ZFS and BtrFS). In any case I feel like this
> part shouldn't go it until after 2.00 as it doesn't fix any end-user
> problem (blocklists for embed files would be rejected by any of
> blocklist users, other than blocklist command) and it may cause new
> problems.
no problem.

-- 
Best wishes
Bean



reply via email to

[Prev in Thread] Current Thread [Next in Thread]