Hi Jean-Pierre,
I tried it, but it made no difference: baddir still gives exactly the
same CHKDSK error.
I'm not 100% sure if I'm using the patched version: To mount the partition
I'm running the patched ntfs-3g directly from its build directory:
./ntfs-3g_ntfsprogs-2017.3.23AR.5/src/ntfs-3g /dev/sdb1 /mnt
Will that be completely stand-alone and isolated from Ubuntu's built-in ntfs-3g
or could it e.g. pull in an old AR.3 shared lib or something? I couldn't find
any existing ntfs-3g stuff in /lib or /usr/lib. I'm not familiar with how
FUSE stuff works.
Thanks,
-- Chris
On Mon Aug 3 2020, at 12:16 AM, Jean-Pierre André
<[email protected]> wrote:
> Hi,
>
> Please find attached a hopefully better variant of the fix.
>
> Jean-Pierre
>
> Jean-Pierre André wrote on 8/1/20 12:35 PM:
>> Hi,
>>
>> Thank you for your report including a test pointing out
>> the issue.
>>
>> Attached is a patch expected to fix it.
>>
>> Please test and report.
>>
>> Jean-Pierre
>>
>> Chris Roehrig wrote on 7/30/20 1:01 AM:
>>> I'm trying to get my Linux-based NTFS backup drive to pass a CHKDSK and
>>> came upon this curious situation where CHKDSK finds errors.
>>>
>>> It seems to be some issue with how ntfs-3g modifies a directory index when
>>> renaming many files.
>>>
>>> The CHKDSK error always seems to be of the form:
>>> Stage 2: Examining file name linkage ...
>>> The first free byte, 0xc0, and bytes available, 0x150, for root index $I30
>>> in file 0x40 are not equal.
>>>
>>> I've attached a python script (mkbaddir.py) that creates two (apparently)
>>> identical directories, one of which reliably causes this CHKDSK error; the
>>> other doesn't.
>>>
>>> How to demonstrate:
>>> - Format an NTFS partition or thumbdrive using Windows or mkfs.ntfs.
>>> - Mount the partition on a Linux system.
>>> I used Mint 20 with ntfs-3g 2017.3.23AR.3 integrated FUSE 28 and
>>> python 3.8.2.
>>> - Chdir to the new NTFS partition and run the script:
>>> /tmp/mkbaddir.py # creates 'baddir' in current dir.
>>> /tmp/mkbaddir.py -G # creates 'gooddir' in current dir.
>>> diff -r baddir gooddir # no difference
>>> du -sB1 baddir gooddir # same size (128K)
>>> - Boot into Windows (10 v1903) and run (from a terminal) chkdsk X:
>>> (where X: is the NTFS drive).
>>> - This will say:
>>> "Errors found. CHKDSK cannot continue in read-only mode."
>>> - Delete baddir (I used cygwin's rm -rf), and run chkdsk X: again.
>>> - This will now have no errors.
>>>
>>> My guess at what's happening:
>>> The script creates a directory of 410 empty files and then renames them
>>> with slightly larger names, which as I understand leaves a bunch of unused
>>> nodes in the b-tree. The -G option just renames the 410 known files;
>>> without the -G option, it uses os.walk() to traverse the directory which
>>> I'm guessing leaves the b-tree in a slightly different state with even more
>>> unused nodes.
>>>
>>> The 410 was chosen by trial-and-error so that some internal threshhold is
>>> just exceeded by the baddir but not by the gooddir. With more than 410
>>> (using the -c option; say -c 500), both baddir and gooddir will cause
>>> CHKDSK errors.
>>>
>>> If I run the script on Windows/cygwin (Python 3.6.9) to create the folders,
>>> it does not give any CHKDSK errors even with many more files.
>>>
>>> So there seems to be some issue with how ntfs-3g modifies the b-tree when
>>> renaming many files that is causing CHKDSK to complain.
>>>
>>>
>>> I encountered this issue when trying to get my Linux-based NTFS backup
>>> drive to consistently pass a CHKDSK. I use a script to first rename POSIX
>>> names to valid windows names, replacing '?' with '@@3F', etc so I can
>>> reverse the renaming afterwards. I have some website mirror folders with
>>> many files of the form:
>>> details.asp?id=xxxxx&key=val
>>> which gave rise to this issue. (In the mkbaddir script I use only
>>> alphanumeric names to be clear this is not an illegal char issue).
>>>
>>>
>>
>
> <shorten_index-v2.patch>
_______________________________________________
ntfs-3g-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel
