wrong handling large file on NTFS

[m]

My story of frustration:

1.) I was turned on my machine , but grub command prompt was shown instead of starting.
2.) I reboot to windows XP to find out what's up
3.) I tried to open root.disk ( over 10 GB ) , but

"Typ události: Informace
Zdroj události: Application Popup
Kategorie události: Není k dispozici
ID události: 26
Datum: 27. 4. 2011
Čas: 2:52:11
Uživatel: Není k dispozici
Počítač: DESKTOP
Popis:
Místní nabídka aplikace: MagicISO Virtual CD/DVD Manager: MAGICD~1.EXE - Poškozený soubor : Soubor nebo adresář C:\ubuntu\disks\root.disk je poškozen a je nečitelný. Spusťte pomůcku Chkdsk.

Další informace získáte v Centru pro nápovědu a pomoc na http://go.microsoft.com/fwlink/events.asp.
"
happened ( it is in czech language , because XP was czech ) , saying , that root.disk cannot be opened.

4.) I run scandisk , which says something about restart needed , because cannot access disk
5.) After restart , scandisk does something without any questions for me.
6.) I found , that root.disk is missing ( probably deleted by scandisk )
7.) In event log was following record :

[m (launch-spam)]

As discussed in original question , while handling large file on NT filesystem , the file may be corrupted and then lost.

If NTFS specification does not allow safe handling large files , option to use 2 files ( one is backup ) mirrored may be useful ( even if performance will be low ) !

If NTFS specification is not correctly implemented by Microsoft , we will decide separately.

If mounted NTFS volume is handled incorrectly by mount.ntfs process , it is a chance to fix.

As I am unsure , which of 3 possible causes is causing the problem , all 3 should be considered.

[m (launch-spam)]

If someone else is affected by this bug , feel free to join.

[bcbc (bcbc)]

I do see a few users who are affected by corruption of their root.disk files. My impression is that this is caused by the user doing hard poweroffs when their Ubuntu install appears to be hanging. This has only been acknowledged by a few users, and not all affected users though, so it's not confirmed.

On my own wubi install (running the development release) I had a normal shutdown followed by a Windows boot, and it triggered an automatic running of chkdsk which fixed one file (not sure which one; root.disk was okay). So it seems possible that there is potential for corruption without user cause (but perhaps this should be expected in alpha testing).

Whatever the cause, it's a bad problem since it can cause full loss of the wubi install - and based on what I see - most users do not back up their data, and are also unaware that a wubi install is not a good place for storing important data.

[bcbc (bcbc)]

With reference to my last comment, I have now found which file was repaired. It is likely an old root.disk I had deleted from Ubuntu (after creating a new bigger root.disk).

The strange thing is that Windows 7 did not even show the existence of the folder "found.000" until I had changed the setting in Windows Explorer to not "Hide protected OS files". Even then I couldn't enter the directory except from an Administrator command prompt:
C:\>cd found.000

C:\found.000>dir
 Volume in drive C is OS
 Volume Serial Number is B4B7-99A8

 Directory of C:\found.000

25/06/2011 01:41 PM 15,000,000,000 file0000.chk
               1 File(s) 15,000,000,000 bytes
               0 Dir(s) 207,932,407,808 bytes free

C:\found.000>

So, in my case, it was the intentional deletion of a large file from Ubuntu that (some time later) was detected and recovered by Windows. Not any corruption of the root.disk itself through normal use of Wubi. Which is good.