Hi Bernhard,
On Wed, 21 Nov 2007, Bernhard Kaindl wrote:
> I was trying to build OpenMoko on a NTFS-3g filesystem and ran into
> an error,
Szuper! Finally a serious reason to raise the priority of
http://ntfs-3g.org/support.html#filedelete
The same issue.
It's not fixed yet because it occures very rarely. The probability is like
0.001% if other, also rare conditions are true. So people didn't complain
about it thus it never became the top priority.
Personally this bug is the number one on my wish list since July of 2006
but work was focused on what users want us to do, not what we would like ;)
> and I found a way to reproduce it:
>
> dd if=/dev/zero of=ntfs.image bs=1M count=300
> losetup /dev/loop7 ntfs.image
> mkfs.ntfs -Q /dev/loop7
> ntfs-3g /dev/loop7 /mnt
For the last three commands this shorter one works too:
mkfs.ntfs -fQ ntfs.image
ntfs-3g ntfs.image /mnt
When possible, it's better to avoid the usage of the loop device because
it's buggy and can lockup the kernel, irrespectively of ntfs-3g use.
Hopefully the per device dirty throttling patches will fix this in 2.6.24.
> svn co http://svn.openmoko.org/ /mnt/openmoko
>
> This stops after 39MB download with:
>
> ...
> A
> /mnt/openmoko/trunk/src/target/OM-2007/artwork/themes/openmoko-standard-qvga/gtk-2.0/openmoko-mokotoolbox-with-search-background.png
> svn: In directory
> '/mnt/openmoko/trunk/src/target/OM-2007/artwork/themes/openmoko-standard-qvga/gtk-2.0'
> svn: Can't move source to dest
> svn: Can't move
> '/mnt/openmoko/trunk/src/target/OM-2007/artwork/themes/openmoko-standard-qvga/gtk-2.0/.svn/tmp/prop-base/light-brushed.png.svn-base'
> to
> '/mnt/openmoko/trunk/src/target/OM-2007/artwork/themes/openmoko-standard-qvga/gtk-2.0/.svn/prop-base/light-brushed.png.svn-base':
> Operation not supported
A shorter one:
while : ; do bonnie++ -s0 ; done
Usually this will reproduce the issue in the first 10-20 runs (no
guarantee).
Unfortunately going over the relevant index update cases and writing
efficient tests which give acceptable implementation and scenario coverage
is not trivial and quite time consuming. I still hope that it will be done
this year.
> BTW, the error didn't reproduce when I changed
>
> dd if=/dev/zero of=ntfs.image bs=1M count=300
> to
>
> dd if=/dev/zero of=ntfs.image bs=1M count=50
Most NTFS metadata is dynamic, depend on other things (e.g. volume size)
and often even compressed (gives variable internal metadata sizes). Hereby
the data structures can be quite different consequently the behavior too.
> Note: You have to run 'losetup -d /dev/loop7' before re-running the comand
> seqence
> to make the loopback driver use the new image!
Some of us are asking util-linux maintainers for transparent loop device
handling:
mount ntfs.img /mntpoint
umount /mntpoint
The current way without losetup:
mount -o loop ntfs.img /mntpoint
umount -d /mntpoint
Thanks,
Szaka
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
ntfs-3g-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel
