linux-ntfs-dev — Development discussions and bug reports.

Re: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

[Anton A. <ai...@ca...>]

On Thu, 30 Nov 2006, Szakacsits Szabolcs wrote:
> I think it would work fine. The problem is with Vista volumes, not random
> volumes attached to Vista.

You know that do you?  Given you don't have Vista that is just an 
assumption...

> I asked very simple technical questions from you:
> 
>    - How the journal looks on Vista after resizing without your patch?
> 
>    - What did you fix?
> 
> The first would have taken about 1-2 minutes from you. I even showed how 
> you can do this. You keep it ignoring. Only you have Vista, unfortunately 
> I don't. You also don't know what in fact you have fixed.

I told you I don't have the time to do the former!  1-2 minutes.  Ha!  At 
that time of day more like 2 hours sitting in the car + at least 15-30 
minutes figuring out how to drive cvs to revert my code changes and doing 
it + 5 minutes to compile it + 15 minutes or so to boot vmware/vista, 
format the data partition with vista, +5 minutes ti shutdown vista/vmware 
and flush buffers, the a minute to run ntfsresize, then 5 minutes to look 
at journal.  So about 3 hours later I would have been able to give you an 
answer.  If I had 3 spare hours I would play with my children or spend an 
extra evening with my wife and not waste them on satisfying your 
curiosity, sorry.

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/

Re: [Linux-NTFS-Dev] [ntfs-3g-devel] About how to reduce the memory usage of ntfs-3g , I want to mount at least 6 partions at the same time , but my memory is only 32M .I want to modify the code , need help and experience

[roland <de...@we...>]

maybe via procfs ?

take a look into /proc/$PID/status - this gives some information about $PID

so - maybe

cat /proc/*/status |egrep "Name|VmSize|VmRSS"

gives what you want. you may need to parse/re-sort that values for being 
better readable

regards
roland


----- Original Message ----- 
From: "zhanglinbao2000" <zha...@16...>
To: "roland" <de...@we...>; <lin...@li...>; 
<ntf...@li...>; "Szakacsits Szabolcs" <sz...@si...>; 
"Yuval Fledel" <yu...@gm...>; "Yura Pakhuchiy" <pak...@gm...>
Sent: Thursday, November 30, 2006 12:05 PM
Subject: Re: [ntfs-3g-devel] About how to reduce the memory usage of ntfs-3g 
,I want to mount at least 6 partions at the same time ,but my memory is only 
32M .I want to modify the code ,need help and experience


> hi ,
>
>    My "ps" command is too poor , it only output limit info ,like this , it 
> doesn't any parameters as the "ps" on PC
> # ps
>  PID TTY     Uid        Size State Command
>    1         root       1584   S   init
>    2         root          0   S   [keventd]
>    3         root          0   S   [ksoftirqd_CPU0]
>    4         root          0   S   [kswapd]
> .............
>    others ...
>
> Do you have any method to query the physical memory usage of ntfs-3g ?
>
>   ----- Original Message ----- 
> From: "roland" <de...@we...>
> To: "zhanglinbao2000" <zha...@16...>; 
> <lin...@li...>; <ntf...@li...>; 
> "Szakacsits Szabolcs" <sz...@si...>; "Yuval Fledel" 
> <yu...@gm...>; "Yura Pakhuchiy" <pak...@gm...>
> Sent: Thursday, November 30, 2006 5:48 PM
> Subject: Re: [ntfs-3g-devel] About how to reduce the memory usage of 
> ntfs-3g ,I want to mount at least 6 partions at the same time ,but my 
> memory is only 32M .I want to modify the code ,need help and experience
>
>
>> maybe you could take a closer look, how your processes growing - for 
>> getting
>> a feeling, if 32mb is enough at all for what you want to do  ?
>>
>> for example:
>>
>> while true;do sleep 1; echo;echo `date`; ps -eo vsz,rss,comm 
>> |sort -rn|head
>> ;done >/tmp/ps.log
>>
>> ok, you don`t have rss if i understand correctly, but maybe this 
>> one-liner
>> is helpful
>>
>>
>> 

Re: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

[Szakacsits S. <sz...@si...>]

On Thu, 30 Nov 2006, Anton Altaparmakov wrote:
> 
> I understand the impact 100% which is why my patch is so big.  It had to 
> touch a lot of utilities to adapt for the changed libntfs behaviour.

The impact to resizing any kind of NTFS. There are many special cases and
ntfsresize works quite differently as you believe. It has its own attribute
resizer, cluster allocator, modifies mft records and not inodes, has strict
ordering of the modifications, etc.

You don't know what you fixed and how fixed. Still you think it doesn't have
any side-effects anywhere because it seems it workes a few times. And you
simply ignore all the cases which did work beforehand.

> How would you tell if it is a Vista partition or not?  

Detect Vista specific files which are always present.

> How do you know that the partition you are resizing is not going to be
> attached to a Vista machine next?  

I think it would work fine. The problem is with Vista volumes, not random
volumes attached to Vista.

> You just can't cope with the idea that someone touches code you have
> written...

I asked very simple technical questions from you:

   - How the journal looks on Vista after resizing without your patch?

   - What did you fix?

The first would have taken about 1-2 minutes from you. I even showed how 
you can do this. You keep it ignoring. Only you have Vista, unfortunately 
I don't. You also don't know what in fact you have fixed.

I'm only interested in the technical explanation but that's not coming.  
Only "works for me" which I can't consider responsible software engineering,
especially considering that how many people are using the software. Sorry.

Regards,
		Szaka

Re: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

[Anton A. <ai...@ca...>]

On Thu, 30 Nov 2006, Szakacsits Szabolcs wrote:
> On Thu, 30 Nov 2006, Anton Altaparmakov wrote:
> > I have not the faintest idea what was wrong before. [...] to my surprise
> > it now made Vista work.  Why - no idea, and I could not care less.
> 
> So, you have no idea of
> 
> 	- what was wrong before

Yes.

> 	- why ntfsresize works on your Vista now

Yes.

> 	- internal knowledge of ntfsresize

I have quite a bit now that I have looked at it.

> 	- what are the impacts of your change

I understand the impact 100% which is why my patch is so big.  It had to 
touch a lot of utilities to adapt for the changed libntfs behaviour.

> but you would still make a new "stable" release. For me, these aren't very
> solid and convincing technically at all.

It works.  As soon as Frans or others have confirmed that ntfsresize now 
works for them also that is quite good enough for me.

> My plan was to make an urgent release which would have included only the
> denial of the Vista NTFS resizing, based on what I've suggested earlier.
> Then there would have been enough time to investigate what's going on when
> Vista becomes publicly available.

How would you tell if it is a Vista partition or not?  How do you know 
that the partition you are resizing is not going to be attached to a Vista 
machine next?  Impossible to know if you ask me.

> But this is your project, and of course you can do whatever you want.
> Recently you messed up ntfsclone and now ntfsresize. Nothing I could do
> about these, unfortunately. The responsibility is yours from now because
> obviously I can't support code I disagree with and even you don't understand
> why it works.

This is ridiculous.  Grow up.  I have neither messed up ntfsclone nor 
ntfsresize.  You just can't cope with the idea that someone touches code 
you have written...

Both work perfectly after my changes and better than they did before.  
Just because you perhaps cannot understand the fixes/improvements does not 
mean they are messed up.  Show me examples of what my changes have broken 
that was not broken to start with and I will take my words back and 
personally remove my patches.

Anyway, be my guest.  Revert my fixes and fix them in a different/better 
way.  I could not care less.  As long as the bugs are gone.  But please do 
not touch any of the libntfs/utilities other than ntfsresize/ntfsclone in 
the process, i.e. please work within the framework of the improved/fixed 
libntfs.  If you want the old behaviour of libntfs back then supply 
NTFS_MNT_FORENSIC to ntfs_mount() and libntfs will not write anything to 
the volume during the mount process, i.e. it will not clear the journal 
and it will not set the volume dirty.  Then if you alse revert my changes 
to ntfsresize you have your old broken ntfsresize back.  Now lets see you 
fix it if you know so much better, o wise one!

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/

Re: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

[Szakacsits S. <sz...@si...>]

On Thu, 30 Nov 2006, Anton Altaparmakov wrote:

> I have not the faintest idea what was wrong before. [...] to my surprise
> it now made Vista work.  Why - no idea, and I could not care less.

So, you have no idea of

	- what was wrong before
	- why ntfsresize works on your Vista now
	- internal knowledge of ntfsresize
	- what are the impacts of your change

but you would still make a new "stable" release. For me, these aren't very
solid and convincing technically at all.

My plan was to make an urgent release which would have included only the
denial of the Vista NTFS resizing, based on what I've suggested earlier.
Then there would have been enough time to investigate what's going on when
Vista becomes publicly available.

But this is your project, and of course you can do whatever you want.
Recently you messed up ntfsclone and now ntfsresize. Nothing I could do
about these, unfortunately. The responsibility is yours from now because
obviously I can't support code I disagree with and even you don't understand
why it works.

	Szaka

Re: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

[Anton A. <ai...@ca...>]

On Thu, 30 Nov 2006, Szakacsits Szabolcs wrote:
> On Thu, 30 Nov 2006, Anton Altaparmakov wrote:
> > This fixes ntfsresize on Vista for me.
> 
> You didn't answer how the journal looks after running ntfsresize without
> your changes. That is, the non-empty journal file detection indeed works on
> Vista.

I have not the faintest idea what was wrong before.  All I noticed was 
that libntfs was not resetting the journal and was not marking volumes 
dirty.  This is what ntfsfix was doing.  So I moved it to libntfs 
ntfs_mount as it belongs there and then dealt with all the fall out from 
that...  I then tried running ntfsresize and to my surprise it now made 
Vista work.  Why - no idea, and I could not care less.  It works now.

> I'd like to emphasize that your change is very dangerous. You did something
> which is not understood at all. Perhaps Vista can boot now in your case, but
> it's also possible that it will cause serious problems in other scenarios.

It will not.  At least my changes to ntfsresize are perfectly well 
undersstood:  As you said I moved the functionality to libntfs, that's 
all.  Why it works as a consequence I have no idea.  I assumed I would 
have to do more work on ntfsresize afterwards but for some bizzare reason 
that was enough.  So ntfsresize was not doing something or doing something 
wrong and now that libntfs is doing the job it just works.  If you want to 
know why you are welcome to spend your own time figuring that out.  I am 
afraid I have too much work to do to care...

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/

Re: [Linux-NTFS-Dev] [ntfs-3g-devel] About how to reduce the memory usage of ntfs-3g , I want to mount at least 6 partions at the same time , but my memory is only 32M .I want to modify the code , need help and experience

[zhanglinbao2000 <zha...@16...>]

aGkgLCANCg0KICAgIE15ICJwcyIgY29tbWFuZCBpcyB0b28gcG9vciAsIGl0IG9ubHkgb3V0cHV0
IGxpbWl0IGluZm8gLGxpa2UgdGhpcyAsIGl0IGRvZXNuJ3QgYW55IHBhcmFtZXRlcnMgYXMgdGhl
ICJwcyIgb24gUEMgDQojIHBzDQogIFBJRCBUVFkgICAgIFVpZCAgICAgICAgU2l6ZSBTdGF0ZSBD
b21tYW5kDQogICAgMSAgICAgICAgIHJvb3QgICAgICAgMTU4NCAgIFMgICBpbml0IA0KICAgIDIg
ICAgICAgICByb290ICAgICAgICAgIDAgICBTICAgW2tldmVudGRdDQogICAgMyAgICAgICAgIHJv
b3QgICAgICAgICAgMCAgIFMgICBba3NvZnRpcnFkX0NQVTBdDQogICAgNCAgICAgICAgIHJvb3Qg
ICAgICAgICAgMCAgIFMgICBba3N3YXBkXQ0KLi4uLi4uLi4uLi4uLg0KICAgIG90aGVycyAuLi4N
Cg0KRG8geW91IGhhdmUgYW55IG1ldGhvZCB0byBxdWVyeSB0aGUgcGh5c2ljYWwgbWVtb3J5IHVz
YWdlIG9mIG50ZnMtM2cgPyANCg0KICAgLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZy
b206ICJyb2xhbmQiIDxkZXZ6ZXJvQHdlYi5kZT4NClRvOiAiemhhbmdsaW5iYW8yMDAwIiA8emhh
bmdsaW5iYW8yMDAwQDE2My5jb20+OyA8bGludXgtbnRmcy1kZXZAbGlzdHMuc291cmNlZm9yZ2Uu
bmV0PjsgPG50ZnMtM2ctZGV2ZWxAbGlzdHMuc2YubmV0PjsgIlN6YWthY3NpdHMgU3phYm9sY3Mi
IDxzemFrYUBzaWVuZXQuaHU+OyAiWXV2YWwgRmxlZGVsIiA8eXV2YWxmbEBnbWFpbC5jb20+OyAi
WXVyYSBQYWtodWNoaXkiIDxwYWtodWNoaXlAZ21haWwuY29tPg0KU2VudDogVGh1cnNkYXksIE5v
dmVtYmVyIDMwLCAyMDA2IDU6NDggUE0NClN1YmplY3Q6IFJlOiBbbnRmcy0zZy1kZXZlbF0gQWJv
dXQgaG93IHRvIHJlZHVjZSB0aGUgbWVtb3J5IHVzYWdlIG9mIG50ZnMtM2cgLEkgd2FudCB0byBt
b3VudCBhdCBsZWFzdCA2IHBhcnRpb25zIGF0IHRoZSBzYW1lIHRpbWUgLGJ1dCBteSBtZW1vcnkg
aXMgb25seSAzMk0gLkkgd2FudCB0byBtb2RpZnkgdGhlIGNvZGUgLG5lZWQgaGVscCBhbmQgZXhw
ZXJpZW5jZQ0KDQoNCj4gbWF5YmUgeW91IGNvdWxkIHRha2UgYSBjbG9zZXIgbG9vaywgaG93IHlv
dXIgcHJvY2Vzc2VzIGdyb3dpbmcgLSBmb3IgZ2V0dGluZyANCj4gYSBmZWVsaW5nLCBpZiAzMm1i
IGlzIGVub3VnaCBhdCBhbGwgZm9yIHdoYXQgeW91IHdhbnQgdG8gZG8gID8NCj4gDQo+IGZvciBl
eGFtcGxlOg0KPiANCj4gd2hpbGUgdHJ1ZTtkbyBzbGVlcCAxOyBlY2hvO2VjaG8gYGRhdGVgOyBw
cyAtZW8gdnN6LHJzcyxjb21tIHxzb3J0IC1ybnxoZWFkIA0KPiA7ZG9uZSA+L3RtcC9wcy5sb2cN
Cj4gDQo+IG9rLCB5b3UgZG9uYHQgaGF2ZSByc3MgaWYgaSB1bmRlcnN0YW5kIGNvcnJlY3RseSwg
YnV0IG1heWJlIHRoaXMgb25lLWxpbmVyIA0KPiBpcyBoZWxwZnVsDQo+IA0KPiANCj4gIA==

Re: [Linux-NTFS-Dev] [ntfs-3g-devel] About how to reduce the memory usage of ntfs-3g , I want to mount at least 6 partions at the same time , but my memory is only 32M .I want to modify the code , need help and experience

[zhanglinbao2000 <zha...@16...>]

aGVsbG8gcm9sYW5kICwgDQoNCkZpcnN0ICx0aGFua3MgZm9yIHlvdXIgcmVwbHlpbmcgISANCg0K
QW5vdGhlciBkcml2ZXIgIlBhcmFnb24gTlRGUyBkcml2ZXIiICwgb24gbXkgYm9hcmQgLCBpZiBJ
IHVzZSB0aGlzIGRyaXZlciAocmFuIGluIGtlcm5lbCBzcGFjZSApICwgSSBjYW4gbW91bnRlZCBz
aXggcGFydGl0aW9ucyBhdCB0aGUgc2FtZSB0aW1lICwgYW5kIGNvcHkgMkcgZmlsZSBib3RoIG9u
IDIgcGFydGl0aW9ucyAsIHRoZXkgYXJlIE9LICwgb3RoZXJzIHBhcnRpdGlvbnMgYXJlIGFsbCBP
SyBhbmQgSSBjYW4gYWNjZXNzIHRoZW0gcXVpY2tseSBkdXJpbmcgdGhlIGNvcHlpbmcgYWN0aW9u
cyAuIA0KDQoNClNvIEkgZmVlbCB0aGF0IG1heWJlIG50ZnMtM2cgZXhwZW5kIG1vcmUgbWVtb3J5
ICwgbWF5YmUgSSBjYW4gb3B0aW1pemUgaXQgYW5kIG1ha2UgaXQgc3V0aWFibGUgZm9yIGVtYmVk
IGFwcGxpY2F0aW9uICxiZWNhdXNlIG9uIEFSTSBib2FyZCAsIGdlbmVyYWxseSAsMzJNICw2NE0g
LCBubyBhbnkgbW9yZSAuIA0KDQotLWJvYiwNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0t
LSANCkZyb206ICJyb2xhbmQiIDxkZXZ6ZXJvQHdlYi5kZT4NClRvOiAiemhhbmdsaW5iYW8yMDAw
IiA8emhhbmdsaW5iYW8yMDAwQDE2My5jb20+OyA8bGludXgtbnRmcy1kZXZAbGlzdHMuc291cmNl
Zm9yZ2UubmV0PjsgPG50ZnMtM2ctZGV2ZWxAbGlzdHMuc2YubmV0PjsgIlN6YWthY3NpdHMgU3ph
Ym9sY3MiIDxzemFrYUBzaWVuZXQuaHU+OyAiWXV2YWwgRmxlZGVsIiA8eXV2YWxmbEBnbWFpbC5j
b20+OyAiWXVyYSBQYWtodWNoaXkiIDxwYWtodWNoaXlAZ21haWwuY29tPg0KU2VudDogVGh1cnNk
YXksIE5vdmVtYmVyIDMwLCAyMDA2IDU6NDggUE0NClN1YmplY3Q6IFJlOiBbbnRmcy0zZy1kZXZl
bF0gQWJvdXQgaG93IHRvIHJlZHVjZSB0aGUgbWVtb3J5IHVzYWdlIG9mIG50ZnMtM2cgLEkgd2Fu
dCB0byBtb3VudCBhdCBsZWFzdCA2IHBhcnRpb25zIGF0IHRoZSBzYW1lIHRpbWUgLGJ1dCBteSBt
ZW1vcnkgaXMgb25seSAzMk0gLkkgd2FudCB0byBtb2RpZnkgdGhlIGNvZGUgLG5lZWQgaGVscCBh
bmQgZXhwZXJpZW5jZQ0KDQoNCj4gbWF5YmUgeW91IGNvdWxkIHRha2UgYSBjbG9zZXIgbG9vaywg
aG93IHlvdXIgcHJvY2Vzc2VzIGdyb3dpbmcgLSBmb3IgZ2V0dGluZyANCj4gYSBmZWVsaW5nLCBp
ZiAzMm1iIGlzIGVub3VnaCBhdCBhbGwgZm9yIHdoYXQgeW91IHdhbnQgdG8gZG8gID8NCj4gDQo+
IGZvciBleGFtcGxlOg0KPiANCj4gd2hpbGUgdHJ1ZTtkbyBzbGVlcCAxOyBlY2hvO2VjaG8gYGRh
dGVgOyBwcyAtZW8gdnN6LHJzcyxjb21tIHxzb3J0IC1ybnxoZWFkIA0KPiA7ZG9uZSA+L3RtcC9w
cy5sb2cNCj4gDQo+IG9rLCB5b3UgZG9uYHQgaGF2ZSByc3MgaWYgaSB1bmRlcnN0YW5kIGNvcnJl
Y3RseSwgYnV0IG1heWJlIHRoaXMgb25lLWxpbmVyIA0KPiBpcyBoZWxwZnVsDQo+IA0KPiANCj4g
DQo+IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQo+IEZyb206ICJ6aGFuZ2xpbmJhbzIw
MDAiIDx6aGFuZ2xpbmJhbzIwMDBAMTYzLmNvbT4NCj4gVG86IDxsaW51eC1udGZzLWRldkBsaXN0
cy5zb3VyY2Vmb3JnZS5uZXQ+OyA8bnRmcy0zZy1kZXZlbEBsaXN0cy5zZi5uZXQ+OyANCj4gIlN6
YWthY3NpdHMgU3phYm9sY3MiIDxzemFrYUBzaWVuZXQuaHU+OyAiWXV2YWwgRmxlZGVsIiA8eXV2
YWxmbEBnbWFpbC5jb20+OyANCj4gIll1cmEgUGFraHVjaGl5IiA8cGFraHVjaGl5QGdtYWlsLmNv
bT4NCj4gU2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDMwLCAyMDA2IDEwOjEzIEFNDQo+IFN1Ympl
Y3Q6IFtudGZzLTNnLWRldmVsXSBBYm91dCBob3cgdG8gcmVkdWNlIHRoZSBtZW1vcnkgdXNhZ2Ug
b2YgbnRmcy0zZyAsSSANCj4gd2FudCB0byBtb3VudCBhdCBsZWFzdCA2IHBhcnRpb25zIGF0IHRo
ZSBzYW1lIHRpbWUgLGJ1dCBteSBtZW1vcnkgaXMgb25seSANCj4gMzJNIC5JIHdhbnQgdG8gbW9k
aWZ5IHRoZSBjb2RlICxuZWVkIGhlbHAgYW5kIGV4cGVyaWVuY2UNCj4gDQo+IA0KPiA+IEhlbGxv
IFN6YWthICxZdXZhbCwgWXVyYSAsDQo+ID4NCj4gPiAgICBCZWNhdXNlIG15IG1lbW9yeSBpcyBm
ZXcgKG9ubHkgMzJNKSAsIGFuZCBteSBib2FyZCB3aWxsIHJ1biBvdGhlcnMgDQo+ID4gcHJvY2Vz
cyBiZXNpZGVzIG50ZnMtM2cgLGZvciBleGFtcGxlICwgc21iZCAsdXBucGQgLCB0aHR0cGQgLGFu
ZCBvdXIgb3duIA0KPiA+IHByb2dyYW1tcyAuDQo+ID4NCj4gPg0KPiA+IE5vdyAsIG15IHVzYiBo
YXJkZGlzayBoYXMgNiBudGZzIHBhcnRpb25zICwgaWYgSSBvbmx5IG1vdW50IG9uZSBwYXJ0aW9u
IA0KPiA+ICxzdGFiaWxpdHkgb2YgbnRmcy0zZyBiZWhhdmVzIHdlbGwgd2hpY2ggcHJlc2VudHMg
dGhlIHByZXZpb3VzIG1haWwgLg0KPiA+DQo+ID4gQnV0ICxpZiBJIG1vdW50ZWQgNiBudGZzIHBh
cnRpb25zICwgYW5kIHNpbXVsdGFuZWl0eSBkbyBjb3B5IGFjdGlvbnMgLCBJIA0KPiA+IGZvdW5k
IHRoYXQgLCBnZW5lcmFsbHkgLHRoZXJlIGFyZSBvbmUgb3IgdHdvICBudGZzLTNnIGFsaXZlICwg
b3RoZXJzIGFyZSANCj4gPiBraWxsZWQgIQ0KPiA+DQo+ID4gZm9yIGV4YW1wbGUgLCBJIGhhdmUg
NiBwYXJ0aXRpb25zICwgL2Rldi9zZGExIC4uLi4gNg0KPiA+DQo+ID4gICAgbnRmcy0zZyAvZGV2
L3NkYTEgL3NoYXJlL3VzYl9oZGRfMV8xDQo+ID4gICAgbnRmcy0zZyAvZGV2L3NkYTIgL3NoYXJl
L3VzYl9oZGRfMV8yDQo+ID4gICAgLi4uLi4uLi4uLi4uLi4uLg0KPiA+ICAgIG50ZnMtM2cgL2Rl
di9zZGE2IC9zaGFyZS91c2JfaGRkXzFfNg0KPiA+DQo+ID4gYW5kIHNoYXJlIHRoZW0gYnkgdXNp
bmcgU2FtYmEgLA0KPiA+DQo+ID4gYXQgdGhlIHNhbWUgdGltZSAsIGNvcHkgNTAwTSBmaWxlIGlu
dG8gdXNiX2hkZF8xXzEgLCBjb3B5IDUwME0gZmlsZSBpbnRvIA0KPiA+IHVzYl9oZGRfMV8yDQo+
ID4gYWZ0ZXIgYSB3aGlsZSAsIG15IHdpbmRvd3MgUEMgd2lsbCBzbG93ICwgYWZ0ZXIgYSB3aGls
ZSAsIEkgZm91bmQgICwgDQo+ID4gb3RoZXJzIG50ZnMtM2cgaGF2ZSBiZWVuIGtpbGxlZCAhICBv
bmx5IG9uZSBudGZzLTNnIHJlbWFpbnMgIQ0KPiA+DQo+ID4NCj4gPiArKysrKysrKysrKysrDQo+
ID4gIyBkZg0KPiA+IEZpbGVzeXN0ZW0gICAgICAgICAgIDFrLWJsb2NrcyAgICAgIFVzZWQgQXZh
aWxhYmxlIFVzZSUgTW91bnRlZCBvbg0KPiA+IHJvb3RmcyAgICAgICAgICAgICAgICAgICAxNDM2
NyAgICAgMTE2NTEgICAgICAyNzE2ICA4MSUgLw0KPiA+IC9kZXYvcmFtMCAgICAgICAgICAgICAg
ICAxNDM2NyAgICAgMTE2NTEgICAgICAyNzE2ICA4MSUgLw0KPiA+IC9kZXYvaGRhMSAgICAgICAg
ICAgICAzODgxMDEwMCAgIDEyNTQ2NDQgIDM3NTU1NDU2ICAgMyUgDQo+ID4gL2hhcmRkaXNrL2hk
fjIvZGF0YQ0KPiA+IC9kZXYvaGRhMiAgICAgICAgICAgICAgIDEwOTg4OCAgICAgICAyNTIgICAg
MTA5NjM2ICAgMCUgDQo+ID4gL2hhcmRkaXNrL2hkfjIvY29uZg0KPiA+IGRmOiAvc2hhcmUvdXNi
X2hkZF8xXzE6IFRyYW5zcG9ydCBlbmRwb2ludCBpcyBub3QgY29ubmVjdGVkDQo+ID4gZGY6IC9z
aGFyZS91c2JfaGRkXzFfMjogVHJhbnNwb3J0IGVuZHBvaW50IGlzIG5vdCBjb25uZWN0ZWQNCj4g
PiBkZjogL3NoYXJlL3VzYl9oZGRfMV8zOiBUcmFuc3BvcnQgZW5kcG9pbnQgaXMgbm90IGNvbm5l
Y3RlZA0KPiA+IGRmOiAvc2hhcmUvdXNiX2hkZF8xXzQ6IFRyYW5zcG9ydCBlbmRwb2ludCBpcyBu
b3QgY29ubmVjdGVkDQo+ID4gZGY6IC9zaGFyZS91c2JfaGRkXzFfNjogVHJhbnNwb3J0IGVuZHBv
aW50IGlzIG5vdCBjb25uZWN0ZWQNCj4gPiArKysrKysrKysrKysrKw0KPiA+DQo+ID4NCj4gPiAt
LS0tLS0tLS0tLS0tDQo+ID4gSW4gYSB3b3JkICwgZnJvbSBjb2RlIHBvaW50IHZpZXcgICwgLGhv
dyBkbyAgSSBtb2RpZnkgdGhlIGNvZGUgdG8gcmVkdWNlIA0KPiA+IHRoZSBtZW1vcnkgdXNhZ2Ug
b2YgbnRmcy0zZyAsIG9yIGhvdyB0byBvcHRpbWl6ZSBpdCB0byB1c2UgZmV3IG1lbW9yeSAgPw0K
PiA+IEkgaGF2ZSBlbm91Z2ggdGltZSB0byBzdHVkeSBpdCAhIE9uY2UgSSBvcHRpbWl6ZSBpdCBz
dWNjZXNzZnVsbHkgLCBJIGNhbiANCj4gPiBjb250cmlidXRlIG15IGNvZGUgLG1lYW53aGlsZSwg
SSBuZWVkIHlvdXIgaGVscCBhbmQgZXhwZXJpZW5jZSBhbmQgDQo+ID4ga25vd2xlZGdlIC4gIFRo
YW5rcyBhaGVhZCAhDQo+ID4NCj4gPiBib2IsDQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+
IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+DQo+ID4gRllJIDoNCj4gPg0KPiA+IGZyb20gbXkg
QVJNIGJvYXJkICwgZ2V0IHRoZSBpbmZvIGZyb20gInBzIg0KPiA+DQo+ID4NCj4gPiAjIHBzDQo+
ID4gIFBJRCAgICAgICAgIFVpZCAgICAgICAgU2l6ZSAgIFN0YXRlICAgICAgICAgICAgICAgICAg
ICAgQ29tbWFuZA0KPiA+IC4uLi4uLi4uLi4uLi4uLi4uLi4NCj4gPiAxMTYyICAgICAgICAgcm9v
dCAgICAgICAzNTE2ICAgUyAgIG50ZnMtM2cgL2Rldi9zZGExIC9zaGFyZS91c2JfaGRkXzFfMSAt
byANCj4gPiBsb2MNCj4gPiAxMTcwICAgICAgICAgcm9vdCAgICAgICAzNTE2ICAgUyAgIG50ZnMt
M2cgL2Rldi9zZGEyIC9zaGFyZS91c2JfaGRkXzFfMiAtbyANCj4gPiBsb2MNCj4gPiAxMTc4ICAg
ICAgICAgcm9vdCAgICAgICAzNTE2ICAgUyAgIG50ZnMtM2cgL2Rldi9zZGEzIC9zaGFyZS91c2Jf
aGRkXzFfMyAtbyANCj4gPiBsb2MNCj4gPiAxMTg2ICAgICAgICAgcm9vdCAgICAgICAzNTE2ICAg
UyAgIG50ZnMtM2cgL2Rldi9zZGE1IC9zaGFyZS91c2JfaGRkXzFfNCAtbyANCj4gPiBsb2MNCj4g
PiAxMTk0ICAgICAgICAgcm9vdCAgICAgICAzNTE2ICAgUyAgIG50ZnMtM2cgL2Rldi9zZGE2IC9z
aGFyZS91c2JfaGRkXzFfNSAtbyANCj4gPiBsb2MNCj4gPiAxMjAyICAgICAgICAgcm9vdCAgICAg
ICAzNTE2ICAgUyAgIG50ZnMtM2cgL2Rldi9zZGE3IC9zaGFyZS91c2JfaGRkXzFfNiAtbyANCj4g
PiBsb2MNCj4gPiAuLi4uLi4uLi4uLi4uLi4uLi4uLg0KPiA+IHRoZSBTaXplIHNob3VsZCBiZSB2
aXJ0dWFsIG1lbW9yeSAgLiBvbiBBUk0gLCBJIGNhbid0IHRoZSBudW1iZXIgb2YgDQo+ID4gcGh5
c2ljYWwgbWVtb3J5IG9mIG50ZnMtM2cgLGJlY2F1c2UgbXkgInBzIiBpcyBvZiBidXN5Ym94ICxp
dHMgZnVuY3Rpb25zIA0KPiA+IGlzIHNpbXBsZSAuDQo+ID4NCj4gPiBCdXQgZnJvbSBYODYgKHBz
IGF1eCAsICBzZWUgUlNTIHZvbHVtZSApLCB0aGUgcGh5c2ljYWwgbWVtb3J5IG9mIG50ZnMtM2cg
DQo+ID4gc2hvdWxkIGJlIDYwMGsgfjkwMGsNCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4N
Cj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4gLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0t
LSANCj4gPiBGcm9tOiAiemhhbmdsaW5iYW8yMDAwIiA8emhhbmdsaW5iYW8yMDAwQDE2My5jb20+
DQo+ID4gVG86IDxsaW51eC1udGZzLWRldkBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQ+OyA8bnRmcy0z
Zy1kZXZlbEBsaXN0cy5zZi5uZXQ+OyANCj4gPiAiU3pha2Fjc2l0cyBTemFib2xjcyIgPHN6YWth
QHNpZW5ldC5odT47ICJZdXZhbCBGbGVkZWwiIA0KPiA+IDx5dXZhbGZsQGdtYWlsLmNvbT47ICJZ
dXJhIFBha2h1Y2hpeSIgPHBha2h1Y2hpeUBnbWFpbC5jb20+DQo+ID4gU2VudDogVGh1cnNkYXks
IE5vdmVtYmVyIDMwLCAyMDA2IDI6MzQgUE0NCj4gPiBTdWJqZWN0OiBbU3RhdHVzIFJlcG9ydF0g
bWlsZXN0b25lIGFib3V0IG50ZnMtM2cgcnVubmluZyBvbiBBUk0gOiBudGZzLTNnIA0KPiA+IGNh
biBjb29wZXJhdGUgd2l0aCBzYW1iYSB3ZWxsICxhbmQgc3RhYmlsaXR5IGhpZ2ggLg0KPiA+DQo+
ID4NCj4gPj4gSGVsbG8gU3pha2EsWXV2YWwsIFl1cmEgIGFuZCBvdGhlciBlbWJlZGVkIGRldmVs
b3BlcnMgLA0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+PiAgICAgICAgIE5vdyAsbnRmcy0zZyBydW5u
aW5nIG9uIEFSTSAsIGl0IGxvb2tzIHdlbGwgd2hlbiBjb29wZXJhdGUgd2l0aCANCj4gPj4gU2Ft
YmENCj4gPj4NCj4gPj4gTXkgY29uZmlndXJhdGlvbiBpcyBsaWtlIHRoaXMgOg0KPiA+Pg0KPiA+
Pg0KPiA+Pg0KPiA+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+DQo+
ID4+ICMgY2F0IC9wcm9jL2NwdWluZm8NCj4gPj4gUHJvY2Vzc29yICAgICAgIDogWFNjYWxlLUlY
UDQyNS9JWEMxMTAwIHJldiAxICh2NWIpDQo+ID4+IEJvZ29NSVBTICAgICAgICA6IDI2Ni4yNA0K
PiA+PiBGZWF0dXJlcyAgICAgICAgOiBzd3AgaGFsZiB0aHVtYiBmYXN0bXVsdCBlZHNwDQo+ID4+
DQo+ID4+DQo+ID4+DQo+ID4+IEhhcmR3YXJlICAgICAgICA6IEludGVsIElYRFA0MjUgRGV2ZWxv
cG1lbnQgUGxhdGZvcm0NCj4gPj4gUmV2aXNpb24gICAgICAgIDogMDAwMA0KPiA+PiBTZXJpYWwg
ICAgICAgICAgOiAwMDAwMDAwMDAwMDAwMDAwDQo+ID4+DQo+ID4+IC0tDQo+ID4+DQo+ID4+IG1l
bSAgICAgICAgICAgIDogMzJNDQo+ID4+DQo+ID4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4NCj4gPj4gLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+Pg0K
PiA+PiAjIGNhdCAvcHJvYy9tZW1pbmZvDQo+ID4+ICAgICAgICAgdG90YWw6ICAgIHVzZWQ6ICAg
IGZyZWU6ICBzaGFyZWQ6IGJ1ZmZlcnM6ICBjYWNoZWQ6DQo+ID4+IE1lbTogIDMxMTM3NzkyIDMw
NDU3ODU2ICAgNjc5OTM2ICAgICAgICAwICAgNDIxODg4IDIyMTEwMjA4DQo+ID4+IFN3YXA6IDEz
OTgyMTA1NiAgNzY5MjI4OCAxMzIxMjg3NjgNCj4gPj4gTWVtVG90YWw6ICAgICAgICAzMDQwOCBr
Qg0KPiA+PiBNZW1GcmVlOiAgICAgICAgICAgNjY0IGtCDQo+ID4+IE1lbVNoYXJlZDogICAgICAg
ICAgIDAga0INCj4gPj4gQnVmZmVyczogICAgICAgICAgIDQxMiBrQg0KPiA+PiBDYWNoZWQ6ICAg
ICAgICAgIDE5MjI0IGtCDQo+ID4+IFN3YXBDYWNoZWQ6ICAgICAgIDIzNjgga0INCj4gPj4gQWN0
aXZlOiAgICAgICAgICAxODA4OCBrQg0KPiA+PiBJbmFjdGl2ZTogICAgICAgICA1MzEyIGtCDQo+
ID4+IEhpZ2hUb3RhbDogICAgICAgICAgIDAga0INCj4gPj4gSGlnaEZyZWU6ICAgICAgICAgICAg
MCBrQg0KPiA+PiBMb3dUb3RhbDogICAgICAgIDMwNDA4IGtCDQo+ID4+IExvd0ZyZWU6ICAgICAg
ICAgICA2NjQga0INCj4gPj4gU3dhcFRvdGFsOiAgICAgIDEzNjU0NCBrQg0KPiA+PiBTd2FwRnJl
ZTogICAgICAgMTI5MDMyIGtCDQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+IC0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+
DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+IEJhc2Ugb24gbXkgdGVzdCAsIHN0YWJpbGl0
eSBpcyB2ZXJ5IGhpZ2ggLG9ubHkgc3BlZWQgaXMgbG93IGVzcGVjaWFsbHkgDQo+ID4+IGJpZyBz
aXplIGZpbGUgLGV4YW1wbGUgMkcgZmlsZQ0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+PiBCZWNhdXNl
IG50ZnMtM2cgZG9uJ3Qgc3VwcG9ydCBzZXR0aW5nIHBlcm1pc3Npb24ob25seSA3NzcgLG5vdCBj
aGFuZ2VkKSANCj4gPj4gLHNvIHlvdSBuZWVkIG1vZGlmeSBzYW1iYSBzb3VyY2UgY29kZSBhYm91
dCBwZXJtaXNzaW9uIHNldHRpbmcgOg0KPiA+Pg0KPiA+PiBNeSBTYW1iYSBWZXJzaW9uIGlzIDMu
MC4xMSA6DQo+ID4+DQo+ID4+IG1vZGlmeSB0aGUgIHNvdXJjZS9zbWJkL29wZW4uYyAgLCAgIGlm
IHlvdSBkb24ndCBtb2RpZnkgLCBpbiBzb21lIHNhbWJhIA0KPiA+PiBjb25maWd1cmF0aW9uICB5
b3Ugb25seSBjb3B5IGEgZmlsZSAsIGJ1dCBvbmNlIGl0IGV4aXN0cyAsIHlvdSBjYW4ndCANCj4g
Pj4gb3ZlcndyaXRlIGl0ICENCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4gRm9y
IGkxOG4gc3VwcG9ydCAsIGdlbmVyYWwgZW1iZWQgYm9hcmQgZG9uJ3Qgc3VwcG9ydCBsb2NhbGUg
YW5kIGxvY2FsZSBpcyANCj4gPj4gYSBsaXR0bGUgY29tcGxleCBmb3IgQVJNIGVtYmVkZWQgZGV2
ZWxvcG1lbnQgLCB5b3UnZCBiZXR0ZXIgdXNlIGxpYmljb252IA0KPiA+PiB0byBzdXBwb3J0IGkx
OG4gLA0KPiA+Pg0KPiA+PiBwbGVhc2Ugc2VlIG15IG1haWxzIHNlbnQgYmVmb3JlIHdoaWNoIGRl
c2NyaWJlcyBob3cgdG8gdXNlIGxpYmljb252IHN0ZWFkIA0KPiA+PiBvZiBsb2NhbGUgLg0KPiA+
Pg0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0NCj4gPj4NCj4gPj4gLyogV2Ugb25seSBjYXJlIGFib3V0IG1hdGNoaW5nIGF0dHJpYnV0
ZXMgb24gZmlsZSBleGlzdHMgYW5kIHRydW5jYXRlLiAqLw0KPiA+PiAgaWYgKGZpbGVfZXhpc3Rl
ZCAmJiAoR0VUX0ZJTEVfT1BFTl9ESVNQT1NJVElPTihvZnVuKSA9PSANCj4gPj4gRklMRV9FWElT
VFNfVFJVTkNBVEUpKSB7DQo+ID4+ICAjaWYgMCAgICAgICAgLy8gbWF5YmUgeW91IHNob3VsZCBj
b21tbWVudCB0aGVzZSBjb2RlIHRvIG1ha2Ugc3VyZSBub3QgDQo+ID4+IGNvbmZsaWN0IHdpdGgg
bnRmcy0zZyg3NzcpICAsIHRoaXMgc3RlcCBpcyBvcHRpb25hbCAsZGVwZW5kIG9uIHlvdXIgc2Ft
YmEgDQo+ID4+IGNvbmZpZ3VyYXRpb24gLg0KPiA+PiAgIGlmICghb3Blbl9tYXRjaF9hdHRyaWJ1
dGVzKGNvbm4sIGZuYW1lLCBleGlzdGluZ19kb3NfbW9kZSwgDQo+ID4+IG5ld19kb3NfbW9kZSwN
Cj4gPj4gICAgICBwc2J1Zi0+c3RfbW9kZSwgbW9kZSwgJm5ld19tb2RlKSkgew0KPiA+PiAgICBE
RUJVRyg1LCgib3Blbl9maWxlX3NoYXJlZDogYXR0cmlidXRlcyBtaXNzbWF0Y2ggZm9yIGZpbGUg
JXMgKCV4ICV4KSANCj4gPj4gKDAlbywgMCVvKVxuIiwNCj4gPj4gICAgICAgZm5hbWUsIGV4aXN0
aW5nX2Rvc19tb2RlLCBuZXdfZG9zX21vZGUsDQo+ID4+ICAgICAgIChpbnQpcHNidWYtPnN0X21v
ZGUsIChpbnQpbW9kZSApKTsNCj4gPj4gICAgZmlsZV9mcmVlKGZzcCk7DQo+ID4+ICAgIGVycm5v
ID0gRUFDQ0VTOw0KPiA+PiAgICByZXR1cm4gTlVMTDsNCj4gPj4gICB9DQo+ID4+ICAjZW5kaWYN
Cj4gPj4NCj4gPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+DQo+ID4+DQo+
ID4+DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+IC0tLS0tLS0tLS0t
LQ0KPiA+Pg0KPiA+PiBGWUkgLCBteSB0ZXN0aW5nIHJlc3VsdCAsDQo+ID4+DQo+ID4+DQo+ID4+
DQo+ID4+IEkgdXNlIEJlbmNobWFyayBhbmQgd2ludGhyYXggdG8gdGVzdCBudGZzLTNnIGFuZCBz
YW1iYSAgLCB0aGUgc3RhYmlsaXR5IA0KPiA+PiBpcyBoaWdoICEgIGN1cnJlbnQgdGltZSAsIHRo
ZXkgaGF2ZSBiZWVuIHJ1bm5pbmcgMTQgaG91cnMgYW5kIG5vIGFueSANCj4gPj4gZXJyb3JzICAu
DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+IE15IHRlc3RpbmcgaXMgdGhhdCAsDQo+ID4+DQo+ID4+
IDE+IG50ZnMtM2cgL2Rldi9zZGExIC9zaGFyZS91c2JfaGRkXzFfMQ0KPiA+Pg0KPiA+PiAyPiBz
aGFyZSAvc2hhcmUvdXNiX2hkZF8xXzEgIGJ5IHNhbWJhICAobXkgdmVyc2lvbiBpcyAzLjAuMTEp
DQo+ID4+DQo+ID4+IDM+IHlvdSBjYW4gYWNjZXNzIFxceHgueHgueHgueHgueHhcdXNiX2hkZF8x
XzEgICBvbiB5b3VyIHdpbmRvd3MNCj4gPj4NCj4gPj4gND55b3UgY2FuIG1hcCBpdCBpbnRvIHlv
dXIgbG9jYWwgZGlzayAsZm9yIGV4YW1wbGUgICAgICBZOg0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+
Pg0KPiA+Pg0KPiA+PiBCZW5jaG1hcmsgdGVzdGluZyBpcyB0aGlzIDoNCj4gPj4NCj4gPj4gc2Vl
IEJlbmNobWFya193aW50aHJheF90b2dldGhlci5qcGcNCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4N
Cj4gPj4NCj4gPj4gLS0tLS0tLS0tLS0tLS0tLQ0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+PiBOZXh0
IHN0ZXAgLA0KPiA+Pg0KPiA+PiBmb2xsb3dpbmcgaXMgbW9yZSBoZWF2aWx5IGxvYWRpbmcgdGVz
dCA6DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+IHNlZSBhdHRhY2htZW50IDpXaW50aHJheF9oZWF2
eV9sb2FkaW5nX3Rlc3QuanBnDQo+ID4+DQo+ID4+IFdpbnRocmF4IGhhcyBiZWVuIHJ1bm5pbmcg
MTYgaG91cnMgLGhhcyBubyBlcnJvcnMgIQ0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+Pg0K
PiA+Pg0KPiA+Pg0KPiA+PiAtLS0tLS0tLS0tDQo+ID4+DQo+ID4+IGJvYiwNCj4gPj4NCj4gPj4N
Cj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4NCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4g
VGFrZSBTdXJ2ZXlzLiBFYXJuIENhc2guIEluZmx1ZW5jZSB0aGUgRnV0dXJlIG9mIElUDQo+ID4g
Sm9pbiBTb3VyY2VGb3JnZS5uZXQncyBUZWNoc2F5IHBhbmVsIGFuZCB5b3UnbGwgZ2V0IHRoZSBj
aGFuY2UgdG8gc2hhcmUgDQo+ID4geW91cg0KPiA+IG9waW5pb25zIG9uIElUICYgYnVzaW5lc3Mg
dG9waWNzIHRocm91Z2ggYnJpZWYgc3VydmV5cyAtIGFuZCBlYXJuIGNhc2gNCj4gPiBodHRwOi8v
d3d3LnRlY2hzYXkuY29tL2RlZmF1bHQucGhwP3BhZ2U9am9pbi5waHAmcD1zb3VyY2Vmb3JnZSZD
SUQ9REVWREVWDQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18NCj4gPiBudGZzLTNnLWRldmVsIG1haWxpbmcgbGlzdA0KPiA+IG50ZnMtM2ctZGV2ZWxA
bGlzdHMuc291cmNlZm9yZ2UubmV0DQo+ID4gaHR0cHM6Ly9saXN0cy5zb3VyY2Vmb3JnZS5uZXQv
bGlzdHMvbGlzdGluZm8vbnRmcy0zZy1kZXZlbCANCj4gDQo+IA==

Re: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

[Szakacsits S. <sz...@si...>]

On Thu, 30 Nov 2006, Anton Altaparmakov wrote:

> I read the code and it does it.  I do not believe in sniffing as you put 
> it.  That is useless as you never know what/why the software is doing 
> something.  The code itself shows exactly what happens.  I prefer to stick 
> with that.

I prefer understanding the code, testing the understanding is correct, and
getting continuous user confirmations that both of the previous are indeed
right.
 
> > Anyway, ntfsresize always unconditionally emptied the journal. So what did 
> > you do which made Vista booting? It's either incorrect journal checking on 
> > Vista or a side-effect of your changes.
> 
> I did two things to libntfs:
> 	- make the journal be emptied at mount time and 
> 	- set the dirty bit at mount time.
> Then at umount time:
> 	- clear the dirty bit again unless the volume was dirty when it 
> was mounted.
> 
> I then did these things to ntfsresize:
> 	- remove the journal emptying from ntfsresize as it is done by 
> libntfs now at mount time,
> 	- remove the setting dirty of volume as that is also done at mount 
> time;

In other words, they were moved to libntfs. No real change here.

> 	- make ntfsresize unmount the volume if one aborts which will 
> clear the dirty bit again if the volume was not dirty to start with; and 
> finally,
> 	- disable the unmount in ntfsresize once it is going to start 
> resizing ntfs as you said that unmounting at that point becomes dangerous.

This also has no effect during a successful resize process.

> This fixes ntfsresize on Vista for me.

You didn't answer how the journal looks after running ntfsresize without
your changes. That is, the non-empty journal file detection indeed works on
Vista.

I'd like to emphasize that your change is very dangerous. You did something
which is not understood at all. Perhaps Vista can boot now in your case, but
it's also possible that it will cause serious problems in other scenarios.

	Szaka

Re: [Linux-NTFS-Dev] [ntfs-3g-devel] About how to reduce the memory usage of ntfs-3g , I want to mount at least 6 partions at the same time , but my memory is only 32M .I want to modify the code , need help and experience

[roland <de...@we...>]

maybe you could take a closer look, how your processes growing - for getting 
a feeling, if 32mb is enough at all for what you want to do  ?

for example:

while true;do sleep 1; echo;echo `date`; ps -eo vsz,rss,comm |sort -rn|head 
;done >/tmp/ps.log

ok, you don`t have rss if i understand correctly, but maybe this one-liner 
is helpful



----- Original Message ----- 
From: "zhanglinbao2000" <zha...@16...>
To: <lin...@li...>; <ntf...@li...>; 
"Szakacsits Szabolcs" <sz...@si...>; "Yuval Fledel" <yu...@gm...>; 
"Yura Pakhuchiy" <pak...@gm...>
Sent: Thursday, November 30, 2006 10:13 AM
Subject: [ntfs-3g-devel] About how to reduce the memory usage of ntfs-3g ,I 
want to mount at least 6 partions at the same time ,but my memory is only 
32M .I want to modify the code ,need help and experience


> Hello Szaka ,Yuval, Yura ,
>
>    Because my memory is few (only 32M) , and my board will run others 
> process besides ntfs-3g ,for example , smbd ,upnpd , thttpd ,and our own 
> programms .
>
>
> Now , my usb harddisk has 6 ntfs partions , if I only mount one partion 
> ,stability of ntfs-3g behaves well which presents the previous mail .
>
> But ,if I mounted 6 ntfs partions , and simultaneity do copy actions , I 
> found that , generally ,there are one or two  ntfs-3g alive , others are 
> killed !
>
> for example , I have 6 partitions , /dev/sda1 .... 6
>
>    ntfs-3g /dev/sda1 /share/usb_hdd_1_1
>    ntfs-3g /dev/sda2 /share/usb_hdd_1_2
>    ................
>    ntfs-3g /dev/sda6 /share/usb_hdd_1_6
>
> and share them by using Samba ,
>
> at the same time , copy 500M file into usb_hdd_1_1 , copy 500M file into 
> usb_hdd_1_2
> after a while , my windows PC will slow , after a while , I found  , 
> others ntfs-3g have been killed !  only one ntfs-3g remains !
>
>
> +++++++++++++
> # df
> Filesystem           1k-blocks      Used Available Use% Mounted on
> rootfs                   14367     11651      2716  81% /
> /dev/ram0                14367     11651      2716  81% /
> /dev/hda1             38810100   1254644  37555456   3% 
> /harddisk/hd~2/data
> /dev/hda2               109888       252    109636   0% 
> /harddisk/hd~2/conf
> df: /share/usb_hdd_1_1: Transport endpoint is not connected
> df: /share/usb_hdd_1_2: Transport endpoint is not connected
> df: /share/usb_hdd_1_3: Transport endpoint is not connected
> df: /share/usb_hdd_1_4: Transport endpoint is not connected
> df: /share/usb_hdd_1_6: Transport endpoint is not connected
> ++++++++++++++
>
>
> -------------
> In a word , from code point view  , ,how do  I modify the code to reduce 
> the memory usage of ntfs-3g , or how to optimize it to use few memory  ?
> I have enough time to study it ! Once I optimize it successfully , I can 
> contribute my code ,meanwhile, I need your help and experience and 
> knowledge .  Thanks ahead !
>
> bob,
>
>
>
>
>
> ------------------------------------------------------------------------------
>
> FYI :
>
> from my ARM board , get the info from "ps"
>
>
> # ps
>  PID         Uid        Size   State                     Command
> ...................
> 1162         root       3516   S   ntfs-3g /dev/sda1 /share/usb_hdd_1_1 -o 
> loc
> 1170         root       3516   S   ntfs-3g /dev/sda2 /share/usb_hdd_1_2 -o 
> loc
> 1178         root       3516   S   ntfs-3g /dev/sda3 /share/usb_hdd_1_3 -o 
> loc
> 1186         root       3516   S   ntfs-3g /dev/sda5 /share/usb_hdd_1_4 -o 
> loc
> 1194         root       3516   S   ntfs-3g /dev/sda6 /share/usb_hdd_1_5 -o 
> loc
> 1202         root       3516   S   ntfs-3g /dev/sda7 /share/usb_hdd_1_6 -o 
> loc
> ....................
> the Size should be virtual memory  . on ARM , I can't the number of 
> physical memory of ntfs-3g ,because my "ps" is of busybox ,its functions 
> is simple .
>
> But from X86 (ps aux ,  see RSS volume ), the physical memory of ntfs-3g 
> should be 600k ~900k
>
>
>
>
>
>
>
>
>
>
>
> ----- Original Message ----- 
> From: "zhanglinbao2000" <zha...@16...>
> To: <lin...@li...>; <ntf...@li...>; 
> "Szakacsits Szabolcs" <sz...@si...>; "Yuval Fledel" 
> <yu...@gm...>; "Yura Pakhuchiy" <pak...@gm...>
> Sent: Thursday, November 30, 2006 2:34 PM
> Subject: [Status Report] milestone about ntfs-3g running on ARM : ntfs-3g 
> can cooperate with samba well ,and stability high .
>
>
>> Hello Szaka,Yuval, Yura  and other embeded developers ,
>>
>>
>>
>>         Now ,ntfs-3g running on ARM , it looks well when cooperate with 
>> Samba
>>
>> My configuration is like this :
>>
>>
>>
>> -------------------------------------------------------------------------------------------
>>
>> # cat /proc/cpuinfo
>> Processor       : XScale-IXP425/IXC1100 rev 1 (v5b)
>> BogoMIPS        : 266.24
>> Features        : swp half thumb fastmult edsp
>>
>>
>>
>> Hardware        : Intel IXDP425 Development Platform
>> Revision        : 0000
>> Serial          : 0000000000000000
>>
>> --
>>
>> mem            : 32M
>>
>> ----------------------------------------------------
>>
>> -------------------------------------------------------------------
>>
>> # cat /proc/meminfo
>>         total:    used:    free:  shared: buffers:  cached:
>> Mem:  31137792 30457856   679936        0   421888 22110208
>> Swap: 139821056  7692288 132128768
>> MemTotal:        30408 kB
>> MemFree:           664 kB
>> MemShared:           0 kB
>> Buffers:           412 kB
>> Cached:          19224 kB
>> SwapCached:       2368 kB
>> Active:          18088 kB
>> Inactive:         5312 kB
>> HighTotal:           0 kB
>> HighFree:            0 kB
>> LowTotal:        30408 kB
>> LowFree:           664 kB
>> SwapTotal:      136544 kB
>> SwapFree:       129032 kB
>>
>>
>>
>> -----------------------------------------------------------------
>>
>>
>>
>>
>>
>> Base on my test , stability is very high ,only speed is low especially 
>> big size file ,example 2G file
>>
>>
>>
>> Because ntfs-3g don't support setting permission(only 777 ,not changed) 
>> ,so you need modify samba source code about permission setting :
>>
>> My Samba Version is 3.0.11 :
>>
>> modify the  source/smbd/open.c  ,   if you don't modify , in some samba 
>> configuration  you only copy a file , but once it exists , you can't 
>> overwrite it !
>>
>>
>>
>>
>>
>> For i18n support , general embed board don't support locale and locale is 
>> a little complex for ARM embeded development , you'd better use libiconv 
>> to support i18n ,
>>
>> please see my mails sent before which describes how to use libiconv stead 
>> of locale .
>>
>>
>>
>>
>>
>> ------------------------------
>>
>> /* We only care about matching attributes on file exists and truncate. */
>>  if (file_existed && (GET_FILE_OPEN_DISPOSITION(ofun) == 
>> FILE_EXISTS_TRUNCATE)) {
>>  #if 0        // maybe you should commment these code to make sure not 
>> conflict with ntfs-3g(777)  , this step is optional ,depend on your samba 
>> configuration .
>>   if (!open_match_attributes(conn, fname, existing_dos_mode, 
>> new_dos_mode,
>>      psbuf->st_mode, mode, &new_mode)) {
>>    DEBUG(5,("open_file_shared: attributes missmatch for file %s (%x %x) 
>> (0%o, 0%o)\n",
>>       fname, existing_dos_mode, new_dos_mode,
>>       (int)psbuf->st_mode, (int)mode ));
>>    file_free(fsp);
>>    errno = EACCES;
>>    return NULL;
>>   }
>>  #endif
>>
>> ------------------------------
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> ------------
>>
>> FYI , my testing result ,
>>
>>
>>
>> I use Benchmark and winthrax to test ntfs-3g and samba  , the stability 
>> is high !  current time , they have been running 14 hours and no any 
>> errors  .
>>
>>
>>
>> My testing is that ,
>>
>> 1> ntfs-3g /dev/sda1 /share/usb_hdd_1_1
>>
>> 2> share /share/usb_hdd_1_1  by samba  (my version is 3.0.11)
>>
>> 3> you can access \\xx.xx.xx.xx.xx\usb_hdd_1_1   on your windows
>>
>> 4>you can map it into your local disk ,for example      Y:
>>
>>
>>
>>
>>
>> Benchmark testing is this :
>>
>> see Benchmark_winthrax_together.jpg
>>
>>
>>
>>
>>
>> ----------------
>>
>>
>>
>> Next step ,
>>
>> following is more heavily loading test :
>>
>>
>>
>> see attachment :Winthrax_heavy_loading_test.jpg
>>
>> Winthrax has been running 16 hours ,has no errors !
>>
>>
>>
>>
>>
>>
>>
>> ----------
>>
>> bob,
>>
>>
>>
>>
>>
>>
>>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share 
> your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> ntfs-3g-devel mailing list
> ntf...@li...
> https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel 

[Linux-NTFS-Dev] About how to reduce the memory usage of ntfs-3g , I want to mount at least 6 partions at the same time , but my memory is only 32M .I want to modify the code , need help and experience

[zhanglinbao2000 <zha...@16...>]

SGVsbG8gU3pha2EgLFl1dmFsLCBZdXJhICwgDQoNCiAgICBCZWNhdXNlIG15IG1lbW9yeSBpcyBm
ZXcgKG9ubHkgMzJNKSAsIGFuZCBteSBib2FyZCB3aWxsIHJ1biBvdGhlcnMgcHJvY2VzcyBiZXNp
ZGVzIG50ZnMtM2cgLGZvciBleGFtcGxlICwgc21iZCAsdXBucGQgLCB0aHR0cGQgLGFuZCBvdXIg
b3duIHByb2dyYW1tcyAuIA0KDQoNCk5vdyAsIG15IHVzYiBoYXJkZGlzayBoYXMgNiBudGZzIHBh
cnRpb25zICwgaWYgSSBvbmx5IG1vdW50IG9uZSBwYXJ0aW9uICxzdGFiaWxpdHkgb2YgbnRmcy0z
ZyBiZWhhdmVzIHdlbGwgd2hpY2ggcHJlc2VudHMgdGhlIHByZXZpb3VzIG1haWwgLiANCg0KQnV0
ICxpZiBJIG1vdW50ZWQgNiBudGZzIHBhcnRpb25zICwgYW5kIHNpbXVsdGFuZWl0eSBkbyBjb3B5
IGFjdGlvbnMgLCBJIGZvdW5kIHRoYXQgLCBnZW5lcmFsbHkgLHRoZXJlIGFyZSBvbmUgb3IgdHdv
ICBudGZzLTNnIGFsaXZlICwgb3RoZXJzIGFyZSBraWxsZWQgISAgDQoNCmZvciBleGFtcGxlICwg
SSBoYXZlIDYgcGFydGl0aW9ucyAsIC9kZXYvc2RhMSAuLi4uIDYgIA0KDQogICAgbnRmcy0zZyAv
ZGV2L3NkYTEgL3NoYXJlL3VzYl9oZGRfMV8xIA0KICAgIG50ZnMtM2cgL2Rldi9zZGEyIC9zaGFy
ZS91c2JfaGRkXzFfMg0KICAgIC4uLi4uLi4uLi4uLi4uLi4NCiAgICBudGZzLTNnIC9kZXYvc2Rh
NiAvc2hhcmUvdXNiX2hkZF8xXzYgDQoNCmFuZCBzaGFyZSB0aGVtIGJ5IHVzaW5nIFNhbWJhICwN
Cg0KYXQgdGhlIHNhbWUgdGltZSAsIGNvcHkgNTAwTSBmaWxlIGludG8gdXNiX2hkZF8xXzEgLCBj
b3B5IDUwME0gZmlsZSBpbnRvIHVzYl9oZGRfMV8yIA0KYWZ0ZXIgYSB3aGlsZSAsIG15IHdpbmRv
d3MgUEMgd2lsbCBzbG93ICwgYWZ0ZXIgYSB3aGlsZSAsIEkgZm91bmQgICwgb3RoZXJzIG50ZnMt
M2cgaGF2ZSBiZWVuIGtpbGxlZCAhICBvbmx5IG9uZSBudGZzLTNnIHJlbWFpbnMgIQ0KDQoNCisr
KysrKysrKysrKysNCiMgZGYNCkZpbGVzeXN0ZW0gICAgICAgICAgIDFrLWJsb2NrcyAgICAgIFVz
ZWQgQXZhaWxhYmxlIFVzZSUgTW91bnRlZCBvbg0Kcm9vdGZzICAgICAgICAgICAgICAgICAgIDE0
MzY3ICAgICAxMTY1MSAgICAgIDI3MTYgIDgxJSAvDQovZGV2L3JhbTAgICAgICAgICAgICAgICAg
MTQzNjcgICAgIDExNjUxICAgICAgMjcxNiAgODElIC8NCi9kZXYvaGRhMSAgICAgICAgICAgICAz
ODgxMDEwMCAgIDEyNTQ2NDQgIDM3NTU1NDU2ICAgMyUgL2hhcmRkaXNrL2hkfjIvZGF0YQ0KL2Rl
di9oZGEyICAgICAgICAgICAgICAgMTA5ODg4ICAgICAgIDI1MiAgICAxMDk2MzYgICAwJSAvaGFy
ZGRpc2svaGR+Mi9jb25mDQpkZjogL3NoYXJlL3VzYl9oZGRfMV8xOiBUcmFuc3BvcnQgZW5kcG9p
bnQgaXMgbm90IGNvbm5lY3RlZA0KZGY6IC9zaGFyZS91c2JfaGRkXzFfMjogVHJhbnNwb3J0IGVu
ZHBvaW50IGlzIG5vdCBjb25uZWN0ZWQNCmRmOiAvc2hhcmUvdXNiX2hkZF8xXzM6IFRyYW5zcG9y
dCBlbmRwb2ludCBpcyBub3QgY29ubmVjdGVkDQpkZjogL3NoYXJlL3VzYl9oZGRfMV80OiBUcmFu
c3BvcnQgZW5kcG9pbnQgaXMgbm90IGNvbm5lY3RlZA0KZGY6IC9zaGFyZS91c2JfaGRkXzFfNjog
VHJhbnNwb3J0IGVuZHBvaW50IGlzIG5vdCBjb25uZWN0ZWQNCisrKysrKysrKysrKysrDQoNCg0K
LS0tLS0tLS0tLS0tLQ0KSW4gYSB3b3JkICwgZnJvbSBjb2RlIHBvaW50IHZpZXcgICwgLGhvdyBk
byAgSSBtb2RpZnkgdGhlIGNvZGUgdG8gcmVkdWNlIHRoZSBtZW1vcnkgdXNhZ2Ugb2YgbnRmcy0z
ZyAsIG9yIGhvdyB0byBvcHRpbWl6ZSBpdCB0byB1c2UgZmV3IG1lbW9yeSAgPyANCkkgaGF2ZSBl
bm91Z2ggdGltZSB0byBzdHVkeSBpdCAhIE9uY2UgSSBvcHRpbWl6ZSBpdCBzdWNjZXNzZnVsbHkg
LCBJIGNhbiBjb250cmlidXRlIG15IGNvZGUgLG1lYW53aGlsZSwgSSBuZWVkIHlvdXIgaGVscCBh
bmQgZXhwZXJpZW5jZSBhbmQga25vd2xlZGdlIC4gIFRoYW5rcyBhaGVhZCAhIA0KDQpib2IsDQoN
Cg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCkZZSSA6DQoNCmZyb20gbXkgQVJNIGJv
YXJkICwgZ2V0IHRoZSBpbmZvIGZyb20gInBzIiANCg0KDQojIHBzDQogIFBJRCAgICAgICAgIFVp
ZCAgICAgICAgU2l6ZSAgIFN0YXRlICAgICAgICAgICAgICAgICAgICAgQ29tbWFuZA0KLi4uLi4u
Li4uLi4uLi4uLi4uLg0KIDExNjIgICAgICAgICByb290ICAgICAgIDM1MTYgICBTICAgbnRmcy0z
ZyAvZGV2L3NkYTEgL3NoYXJlL3VzYl9oZGRfMV8xIC1vIGxvYw0KIDExNzAgICAgICAgICByb290
ICAgICAgIDM1MTYgICBTICAgbnRmcy0zZyAvZGV2L3NkYTIgL3NoYXJlL3VzYl9oZGRfMV8yIC1v
IGxvYw0KIDExNzggICAgICAgICByb290ICAgICAgIDM1MTYgICBTICAgbnRmcy0zZyAvZGV2L3Nk
YTMgL3NoYXJlL3VzYl9oZGRfMV8zIC1vIGxvYw0KIDExODYgICAgICAgICByb290ICAgICAgIDM1
MTYgICBTICAgbnRmcy0zZyAvZGV2L3NkYTUgL3NoYXJlL3VzYl9oZGRfMV80IC1vIGxvYw0KIDEx
OTQgICAgICAgICByb290ICAgICAgIDM1MTYgICBTICAgbnRmcy0zZyAvZGV2L3NkYTYgL3NoYXJl
L3VzYl9oZGRfMV81IC1vIGxvYw0KIDEyMDIgICAgICAgICByb290ICAgICAgIDM1MTYgICBTICAg
bnRmcy0zZyAvZGV2L3NkYTcgL3NoYXJlL3VzYl9oZGRfMV82IC1vIGxvYw0KLi4uLi4uLi4uLi4u
Li4uLi4uLi4NCnRoZSBTaXplIHNob3VsZCBiZSB2aXJ0dWFsIG1lbW9yeSAgLiBvbiBBUk0gLCBJ
IGNhbid0IHRoZSBudW1iZXIgb2YgcGh5c2ljYWwgbWVtb3J5IG9mIG50ZnMtM2cgLGJlY2F1c2Ug
bXkgInBzIiBpcyBvZiBidXN5Ym94ICxpdHMgZnVuY3Rpb25zIGlzIHNpbXBsZSAuIA0KDQpCdXQg
ZnJvbSBYODYgKHBzIGF1eCAsICBzZWUgUlNTIHZvbHVtZSApLCB0aGUgcGh5c2ljYWwgbWVtb3J5
IG9mIG50ZnMtM2cgc2hvdWxkIGJlIDYwMGsgfjkwMGsgDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K
LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJ6aGFuZ2xpbmJhbzIwMDAiIDx6
aGFuZ2xpbmJhbzIwMDBAMTYzLmNvbT4NClRvOiA8bGludXgtbnRmcy1kZXZAbGlzdHMuc291cmNl
Zm9yZ2UubmV0PjsgPG50ZnMtM2ctZGV2ZWxAbGlzdHMuc2YubmV0PjsgIlN6YWthY3NpdHMgU3ph
Ym9sY3MiIDxzemFrYUBzaWVuZXQuaHU+OyAiWXV2YWwgRmxlZGVsIiA8eXV2YWxmbEBnbWFpbC5j
b20+OyAiWXVyYSBQYWtodWNoaXkiIDxwYWtodWNoaXlAZ21haWwuY29tPg0KU2VudDogVGh1cnNk
YXksIE5vdmVtYmVyIDMwLCAyMDA2IDI6MzQgUE0NClN1YmplY3Q6IFtTdGF0dXMgUmVwb3J0XSBt
aWxlc3RvbmUgYWJvdXQgbnRmcy0zZyBydW5uaW5nIG9uIEFSTSA6IG50ZnMtM2cgY2FuIGNvb3Bl
cmF0ZSB3aXRoIHNhbWJhIHdlbGwgLGFuZCBzdGFiaWxpdHkgaGlnaCAuDQoNCg0KPiBIZWxsbyBT
emFrYSxZdXZhbCwgWXVyYSAgYW5kIG90aGVyIGVtYmVkZWQgZGV2ZWxvcGVycyAsIA0KPiANCj4g
IA0KPiANCj4gICAgICAgICBOb3cgLG50ZnMtM2cgcnVubmluZyBvbiBBUk0gLCBpdCBsb29rcyB3
ZWxsIHdoZW4gY29vcGVyYXRlIHdpdGggU2FtYmEgDQo+IA0KPiBNeSBjb25maWd1cmF0aW9uIGlz
IGxpa2UgdGhpcyA6DQo+IA0KPiAgDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tDQo+IA0KPiAjIGNhdCAvcHJvYy9jcHVpbmZvDQo+IFByb2Nlc3NvciAgICAgICA6IFhT
Y2FsZS1JWFA0MjUvSVhDMTEwMCByZXYgMSAodjViKQ0KPiBCb2dvTUlQUyAgICAgICAgOiAyNjYu
MjQNCj4gRmVhdHVyZXMgICAgICAgIDogc3dwIGhhbGYgdGh1bWIgZmFzdG11bHQgZWRzcCANCj4g
DQo+ICANCj4gDQo+IEhhcmR3YXJlICAgICAgICA6IEludGVsIElYRFA0MjUgRGV2ZWxvcG1lbnQg
UGxhdGZvcm0NCj4gUmV2aXNpb24gICAgICAgIDogMDAwMA0KPiBTZXJpYWwgICAgICAgICAgOiAw
MDAwMDAwMDAwMDAwMDAwDQo+IA0KPiAtLQ0KPiANCj4gbWVtICAgICAgICAgICAgOiAzMk0NCj4g
DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N
Cj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+ICMgY2F0IC9wcm9jL21lbWluZm8NCj4gICAgICAgICB0
b3RhbDogICAgdXNlZDogICAgZnJlZTogIHNoYXJlZDogYnVmZmVyczogIGNhY2hlZDoNCj4gTWVt
OiAgMzExMzc3OTIgMzA0NTc4NTYgICA2Nzk5MzYgICAgICAgIDAgICA0MjE4ODggMjIxMTAyMDgN
Cj4gU3dhcDogMTM5ODIxMDU2ICA3NjkyMjg4IDEzMjEyODc2OA0KPiBNZW1Ub3RhbDogICAgICAg
IDMwNDA4IGtCDQo+IE1lbUZyZWU6ICAgICAgICAgICA2NjQga0INCj4gTWVtU2hhcmVkOiAgICAg
ICAgICAgMCBrQg0KPiBCdWZmZXJzOiAgICAgICAgICAgNDEyIGtCDQo+IENhY2hlZDogICAgICAg
ICAgMTkyMjQga0INCj4gU3dhcENhY2hlZDogICAgICAgMjM2OCBrQg0KPiBBY3RpdmU6ICAgICAg
ICAgIDE4MDg4IGtCDQo+IEluYWN0aXZlOiAgICAgICAgIDUzMTIga0INCj4gSGlnaFRvdGFsOiAg
ICAgICAgICAgMCBrQg0KPiBIaWdoRnJlZTogICAgICAgICAgICAwIGtCDQo+IExvd1RvdGFsOiAg
ICAgICAgMzA0MDgga0INCj4gTG93RnJlZTogICAgICAgICAgIDY2NCBrQg0KPiBTd2FwVG90YWw6
ICAgICAgMTM2NTQ0IGtCDQo+IFN3YXBGcmVlOiAgICAgICAxMjkwMzIga0INCj4gDQo+ICANCj4g
DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tDQo+IA0KPiAgDQo+IA0KPiAgDQo+IA0KPiBCYXNlIG9uIG15IHRlc3QgLCBz
dGFiaWxpdHkgaXMgdmVyeSBoaWdoICxvbmx5IHNwZWVkIGlzIGxvdyBlc3BlY2lhbGx5IGJpZyBz
aXplIGZpbGUgLGV4YW1wbGUgMkcgZmlsZSANCj4gDQo+ICANCj4gDQo+IEJlY2F1c2UgbnRmcy0z
ZyBkb24ndCBzdXBwb3J0IHNldHRpbmcgcGVybWlzc2lvbihvbmx5IDc3NyAsbm90IGNoYW5nZWQp
ICxzbyB5b3UgbmVlZCBtb2RpZnkgc2FtYmEgc291cmNlIGNvZGUgYWJvdXQgcGVybWlzc2lvbiBz
ZXR0aW5nIDoNCj4gDQo+IE15IFNhbWJhIFZlcnNpb24gaXMgMy4wLjExIDoNCj4gDQo+IG1vZGlm
eSB0aGUgIHNvdXJjZS9zbWJkL29wZW4uYyAgLCAgIGlmIHlvdSBkb24ndCBtb2RpZnkgLCBpbiBz
b21lIHNhbWJhIGNvbmZpZ3VyYXRpb24gIHlvdSBvbmx5IGNvcHkgYSBmaWxlICwgYnV0IG9uY2Ug
aXQgZXhpc3RzICwgeW91IGNhbid0IG92ZXJ3cml0ZSBpdCAhIA0KPiANCj4gIA0KPiANCj4gIA0K
PiANCj4gRm9yIGkxOG4gc3VwcG9ydCAsIGdlbmVyYWwgZW1iZWQgYm9hcmQgZG9uJ3Qgc3VwcG9y
dCBsb2NhbGUgYW5kIGxvY2FsZSBpcyBhIGxpdHRsZSBjb21wbGV4IGZvciBBUk0gZW1iZWRlZCBk
ZXZlbG9wbWVudCAsIHlvdSdkIGJldHRlciB1c2UgbGliaWNvbnYgdG8gc3VwcG9ydCBpMThuICwN
Cj4gDQo+IHBsZWFzZSBzZWUgbXkgbWFpbHMgc2VudCBiZWZvcmUgd2hpY2ggZGVzY3JpYmVzIGhv
dyB0byB1c2UgbGliaWNvbnYgc3RlYWQgb2YgbG9jYWxlIC4NCj4gDQo+ICANCj4gDQo+ICANCj4g
DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gLyogV2Ugb25seSBjYXJl
IGFib3V0IG1hdGNoaW5nIGF0dHJpYnV0ZXMgb24gZmlsZSBleGlzdHMgYW5kIHRydW5jYXRlLiAq
Lw0KPiAgaWYgKGZpbGVfZXhpc3RlZCAmJiAoR0VUX0ZJTEVfT1BFTl9ESVNQT1NJVElPTihvZnVu
KSA9PSBGSUxFX0VYSVNUU19UUlVOQ0FURSkpIHsNCj4gICNpZiAwICAgICAgICAvLyBtYXliZSB5
b3Ugc2hvdWxkIGNvbW1tZW50IHRoZXNlIGNvZGUgdG8gbWFrZSBzdXJlIG5vdCBjb25mbGljdCB3
aXRoIG50ZnMtM2coNzc3KSAgLCB0aGlzIHN0ZXAgaXMgb3B0aW9uYWwgLGRlcGVuZCBvbiB5b3Vy
IHNhbWJhIGNvbmZpZ3VyYXRpb24gLg0KPiAgIGlmICghb3Blbl9tYXRjaF9hdHRyaWJ1dGVzKGNv
bm4sIGZuYW1lLCBleGlzdGluZ19kb3NfbW9kZSwgbmV3X2Rvc19tb2RlLA0KPiAgICAgIHBzYnVm
LT5zdF9tb2RlLCBtb2RlLCAmbmV3X21vZGUpKSB7DQo+ICAgIERFQlVHKDUsKCJvcGVuX2ZpbGVf
c2hhcmVkOiBhdHRyaWJ1dGVzIG1pc3NtYXRjaCBmb3IgZmlsZSAlcyAoJXggJXgpICgwJW8sIDAl
bylcbiIsDQo+ICAgICAgIGZuYW1lLCBleGlzdGluZ19kb3NfbW9kZSwgbmV3X2Rvc19tb2RlLA0K
PiAgICAgICAoaW50KXBzYnVmLT5zdF9tb2RlLCAoaW50KW1vZGUgKSk7DQo+ICAgIGZpbGVfZnJl
ZShmc3ApOw0KPiAgICBlcnJubyA9IEVBQ0NFUzsNCj4gICAgcmV0dXJuIE5VTEw7DQo+ICAgfQ0K
PiAgI2VuZGlmDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+ICAN
Cj4gDQo+ICANCj4gDQo+ICANCj4gDQo+ICANCj4gDQo+IC0tLS0tLS0tLS0tLQ0KPiANCj4gRllJ
ICwgbXkgdGVzdGluZyByZXN1bHQgLCANCj4gDQo+ICANCj4gDQo+IEkgdXNlIEJlbmNobWFyayBh
bmQgd2ludGhyYXggdG8gdGVzdCBudGZzLTNnIGFuZCBzYW1iYSAgLCB0aGUgc3RhYmlsaXR5IGlz
IGhpZ2ggISAgY3VycmVudCB0aW1lICwgdGhleSBoYXZlIGJlZW4gcnVubmluZyAxNCBob3VycyBh
bmQgbm8gYW55IGVycm9ycyAgLg0KPiANCj4gIA0KPiANCj4gTXkgdGVzdGluZyBpcyB0aGF0ICwN
Cj4gDQo+IDE+IG50ZnMtM2cgL2Rldi9zZGExIC9zaGFyZS91c2JfaGRkXzFfMSANCj4gDQo+IDI+
IHNoYXJlIC9zaGFyZS91c2JfaGRkXzFfMSAgYnkgc2FtYmEgIChteSB2ZXJzaW9uIGlzIDMuMC4x
MSkNCj4gDQo+IDM+IHlvdSBjYW4gYWNjZXNzIFxceHgueHgueHgueHgueHhcdXNiX2hkZF8xXzEg
ICBvbiB5b3VyIHdpbmRvd3MgDQo+IA0KPiA0PnlvdSBjYW4gbWFwIGl0IGludG8geW91ciBsb2Nh
bCBkaXNrICxmb3IgZXhhbXBsZSAgICAgIFk6DQo+IA0KPiAgDQo+IA0KPiAgDQo+IA0KPiBCZW5j
aG1hcmsgdGVzdGluZyBpcyB0aGlzIDoNCj4gDQo+IHNlZSBCZW5jaG1hcmtfd2ludGhyYXhfdG9n
ZXRoZXIuanBnIA0KPiANCj4gIA0KPiANCj4gIA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLQ0KPiAN
Cj4gIA0KPiANCj4gTmV4dCBzdGVwICwgDQo+IA0KPiBmb2xsb3dpbmcgaXMgbW9yZSBoZWF2aWx5
IGxvYWRpbmcgdGVzdCA6DQo+IA0KPiAgDQo+IA0KPiBzZWUgYXR0YWNobWVudCA6V2ludGhyYXhf
aGVhdnlfbG9hZGluZ190ZXN0LmpwZw0KPiANCj4gV2ludGhyYXggaGFzIGJlZW4gcnVubmluZyAx
NiBob3VycyAsaGFzIG5vIGVycm9ycyAhIA0KPiANCj4gIA0KPiANCj4gIA0KPiANCj4gIA0KPiAN
Cj4gLS0tLS0tLS0tLQ0KPiANCj4gYm9iLCANCj4gDQo+ICANCj4gDQo+ICANCj4gDQo+ICANCj4g

Re: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

[Anton A. <ai...@ca...>]

On Thu, 30 Nov 2006, Szakacsits Szabolcs wrote:
> On Thu, 30 Nov 2006, Anton Altaparmakov wrote:
> > Szaka wrote: "pointless to empty journal if clean"...
> > It is NOT pointless to empty.  
> 
> It depends on how journaling works, on which we disagree. It's useless to 
> explain the consequences if you're right because I'm obviously aware of it. 
> You would have a good argument if you said that "sniff and observe Windows 
> reading all journal clusters during boot even if it's clean which means 
> quite probably that it also analyzes it".

I read the code and it does it.  I do not believe in sniffing as you put 
it.  That is useless as you never know what/why the software is doing 
something.  The code itself shows exactly what happens.  I prefer to stick 
with that.

> Anyway, ntfsresize always unconditionally emptied the journal. So what did 
> you do which made Vista booting? It's either incorrect journal checking on 
> Vista or a side-effect of your changes.

I did two things to libntfs:
	- make the journal be emptied at mount time and 
	- set the dirty bit at mount time.
Then at umount time:
	- clear the dirty bit again unless the volume was dirty when it 
was mounted.

I then did these things to ntfsresize:
	- remove the journal emptying from ntfsresize as it is done by 
libntfs now at mount time,
	- remove the setting dirty of volume as that is also done at mount 
time;
	- make ntfsresize unmount the volume if one aborts which will 
clear the dirty bit again if the volume was not dirty to start with; and 
finally,
	- disable the unmount in ntfsresize once it is going to start 
resizing ntfs as you said that unmounting at that point becomes dangerous.

This fixes ntfsresize on Vista for me.

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/

[Linux-NTFS-Dev] Free Space calculation in NTFS

[Manoj S. <xm...@gm...>]

I don't seem to understand how free space is calculated in NTFS.

I have a 512MB Drive (NTFS)
Cluster size = 4k (512b per sector, 8 sectors per cluster)

$BITMAP file has 4 clusters (Last Cluster is 4032 bytes)
so the total bytes would be 3*4*1024 + 4032 = 16320

so the total clusters it can address 16320*8 = 130560
now 130560*4096 = 510MB (total usable disk space i am guessing)

now if i calculate the total bits that are 0 in $Bitmap that should
give me the total free space
But total 0 bits are only 424.. that means only 424 clusters are free i.e.1696KB

But the disk is 441MB full and 68.6MB free.

(i have really checked my free 0's code it looks ok)

Can anyone please explain this to me?

Re: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

[Szakacsits S. <sz...@si...>]

On Thu, 30 Nov 2006, Anton Altaparmakov wrote:

> Szaka wrote: "pointless to empty journal if clean"...
> 
> It is NOT pointless to empty.  

It depends on how journaling works, on which we disagree. It's useless to 
explain the consequences if you're right because I'm obviously aware of it. 
You would have a good argument if you said that "sniff and observe Windows 
reading all journal clusters during boot even if it's clean which means 
quite probably that it also analyzes it".

Anyway, ntfsresize always unconditionally emptied the journal. So what did 
you do which made Vista booting? It's either incorrect journal checking on 
Vista or a side-effect of your changes.

	Szaka

Re: [Linux-NTFS-Dev] was: Bug#379628: CALL FOR HELP: Vista beta compatibility testing

[Anton A. <ai...@ca...>]

On Thu, 30 Nov 2006, Szakacsits Szabolcs wrote:
> Surely I would but I don't have much free time recently, and unfortunately 
> it doesn't help that seemingly you have checked in your entire private 
> ntfsprogs CVS in one commmit.

Nope, that was all written as a consequence to the changes to libntfs 
mounting/unmounting.  A lot of fixing of code was needed to work with the 
changes in the utilities.  )-:

(Well there are two tiny things that slipped in, one is an ntfscat 
modification and one is a ntfsinfo modification but the major bulk of 
changes was all due to the mount changes.)

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/

Re: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

[Anton A. <ai...@ca...>]

Szaka wrote: "pointless to empty journal if clean"...

It is NOT pointless to empty.  I think you do not understand how 
journalling in Windows works (or I don't understand it... (-;).  My 
understanding is that regardless whether the journal is clean or not 
Windows can/will parse the journal (at least in some cases, depends on the 
exact state of the journal) and redo various things/undo others as parts 
of its journalling startup.  Normally this has no effect as it just writes 
the same data over the existing data (unless a weird crash occurred in 
which case it will repair the volume).  However when you have modified the 
volume underneath with another ntfs driver or with ntfsresize or whatever, 
then doing such redo/undo operations are fatal.  Well they can be fatal 
anyway.  I guess in most cases they will silently corrupt stuff that one 
will not know about or even just write over now random locations on disk.  
The problem is this is totally unpredictable.  The only way to make not 
emptying the journal safe is to do journalling and keep the journal 
uptodate.  But none of us know how to do that so we better empty it to 
make sure everything is ok...

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/

[Linux-NTFS-Dev] [Status Report] milestone about ntfs-3g running on ARM : ntfs-3g can cooperate with samba well , and stability high .

[zhanglinbao2000 <zha...@16...>]

SGVsbG8gU3pha2EsWXV2YWwsIFl1cmEgIGFuZCBvdGhlciBlbWJlZGVkIGRldmVsb3BlcnMgLCAN
Cg0KIA0KDQogICAgICAgIE5vdyAsbnRmcy0zZyBydW5uaW5nIG9uIEFSTSAsIGl0IGxvb2tzIHdl
bGwgd2hlbiBjb29wZXJhdGUgd2l0aCBTYW1iYSANCg0KTXkgY29uZmlndXJhdGlvbiBpcyBsaWtl
IHRoaXMgOg0KDQogDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KIyBj
YXQgL3Byb2MvY3B1aW5mbw0KUHJvY2Vzc29yICAgICAgIDogWFNjYWxlLUlYUDQyNS9JWEMxMTAw
IHJldiAxICh2NWIpDQpCb2dvTUlQUyAgICAgICAgOiAyNjYuMjQNCkZlYXR1cmVzICAgICAgICA6
IHN3cCBoYWxmIHRodW1iIGZhc3RtdWx0IGVkc3AgDQoNCiANCg0KSGFyZHdhcmUgICAgICAgIDog
SW50ZWwgSVhEUDQyNSBEZXZlbG9wbWVudCBQbGF0Zm9ybQ0KUmV2aXNpb24gICAgICAgIDogMDAw
MA0KU2VyaWFsICAgICAgICAgIDogMDAwMDAwMDAwMDAwMDAwMA0KDQotLQ0KDQptZW0gICAgICAg
ICAgICA6IDMyTQ0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KIyBjYXQgL3Byb2MvbWVtaW5mbw0KICAgICAgICB0
b3RhbDogICAgdXNlZDogICAgZnJlZTogIHNoYXJlZDogYnVmZmVyczogIGNhY2hlZDoNCk1lbTog
IDMxMTM3NzkyIDMwNDU3ODU2ICAgNjc5OTM2ICAgICAgICAwICAgNDIxODg4IDIyMTEwMjA4DQpT
d2FwOiAxMzk4MjEwNTYgIDc2OTIyODggMTMyMTI4NzY4DQpNZW1Ub3RhbDogICAgICAgIDMwNDA4
IGtCDQpNZW1GcmVlOiAgICAgICAgICAgNjY0IGtCDQpNZW1TaGFyZWQ6ICAgICAgICAgICAwIGtC
DQpCdWZmZXJzOiAgICAgICAgICAgNDEyIGtCDQpDYWNoZWQ6ICAgICAgICAgIDE5MjI0IGtCDQpT
d2FwQ2FjaGVkOiAgICAgICAyMzY4IGtCDQpBY3RpdmU6ICAgICAgICAgIDE4MDg4IGtCDQpJbmFj
dGl2ZTogICAgICAgICA1MzEyIGtCDQpIaWdoVG90YWw6ICAgICAgICAgICAwIGtCDQpIaWdoRnJl
ZTogICAgICAgICAgICAwIGtCDQpMb3dUb3RhbDogICAgICAgIDMwNDA4IGtCDQpMb3dGcmVlOiAg
ICAgICAgICAgNjY0IGtCDQpTd2FwVG90YWw6ICAgICAgMTM2NTQ0IGtCDQpTd2FwRnJlZTogICAg
ICAgMTI5MDMyIGtCDQoNCiANCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KIA0KDQogDQoNCkJhc2Ugb24gbXkgdGVz
dCAsIHN0YWJpbGl0eSBpcyB2ZXJ5IGhpZ2ggLG9ubHkgc3BlZWQgaXMgbG93IGVzcGVjaWFsbHkg
YmlnIHNpemUgZmlsZSAsZXhhbXBsZSAyRyBmaWxlIA0KDQogDQoNCkJlY2F1c2UgbnRmcy0zZyBk
b24ndCBzdXBwb3J0IHNldHRpbmcgcGVybWlzc2lvbihvbmx5IDc3NyAsbm90IGNoYW5nZWQpICxz
byB5b3UgbmVlZCBtb2RpZnkgc2FtYmEgc291cmNlIGNvZGUgYWJvdXQgcGVybWlzc2lvbiBzZXR0
aW5nIDoNCg0KTXkgU2FtYmEgVmVyc2lvbiBpcyAzLjAuMTEgOg0KDQptb2RpZnkgdGhlICBzb3Vy
Y2Uvc21iZC9vcGVuLmMgICwgICBpZiB5b3UgZG9uJ3QgbW9kaWZ5ICwgaW4gc29tZSBzYW1iYSBj
b25maWd1cmF0aW9uICB5b3Ugb25seSBjb3B5IGEgZmlsZSAsIGJ1dCBvbmNlIGl0IGV4aXN0cyAs
IHlvdSBjYW4ndCBvdmVyd3JpdGUgaXQgISANCg0KIA0KDQogDQoNCkZvciBpMThuIHN1cHBvcnQg
LCBnZW5lcmFsIGVtYmVkIGJvYXJkIGRvbid0IHN1cHBvcnQgbG9jYWxlIGFuZCBsb2NhbGUgaXMg
YSBsaXR0bGUgY29tcGxleCBmb3IgQVJNIGVtYmVkZWQgZGV2ZWxvcG1lbnQgLCB5b3UnZCBiZXR0
ZXIgdXNlIGxpYmljb252IHRvIHN1cHBvcnQgaTE4biAsDQoNCnBsZWFzZSBzZWUgbXkgbWFpbHMg
c2VudCBiZWZvcmUgd2hpY2ggZGVzY3JpYmVzIGhvdyB0byB1c2UgbGliaWNvbnYgc3RlYWQgb2Yg
bG9jYWxlIC4NCg0KIA0KDQogDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQov
KiBXZSBvbmx5IGNhcmUgYWJvdXQgbWF0Y2hpbmcgYXR0cmlidXRlcyBvbiBmaWxlIGV4aXN0cyBh
bmQgdHJ1bmNhdGUuICovDQogaWYgKGZpbGVfZXhpc3RlZCAmJiAoR0VUX0ZJTEVfT1BFTl9ESVNQ
T1NJVElPTihvZnVuKSA9PSBGSUxFX0VYSVNUU19UUlVOQ0FURSkpIHsNCiAjaWYgMCAgICAgICAg
Ly8gbWF5YmUgeW91IHNob3VsZCBjb21tbWVudCB0aGVzZSBjb2RlIHRvIG1ha2Ugc3VyZSBub3Qg
Y29uZmxpY3Qgd2l0aCBudGZzLTNnKDc3NykgICwgdGhpcyBzdGVwIGlzIG9wdGlvbmFsICxkZXBl
bmQgb24geW91ciBzYW1iYSBjb25maWd1cmF0aW9uIC4NCiAgaWYgKCFvcGVuX21hdGNoX2F0dHJp
YnV0ZXMoY29ubiwgZm5hbWUsIGV4aXN0aW5nX2Rvc19tb2RlLCBuZXdfZG9zX21vZGUsDQogICAg
IHBzYnVmLT5zdF9tb2RlLCBtb2RlLCAmbmV3X21vZGUpKSB7DQogICBERUJVRyg1LCgib3Blbl9m
aWxlX3NoYXJlZDogYXR0cmlidXRlcyBtaXNzbWF0Y2ggZm9yIGZpbGUgJXMgKCV4ICV4KSAoMCVv
LCAwJW8pXG4iLA0KICAgICAgZm5hbWUsIGV4aXN0aW5nX2Rvc19tb2RlLCBuZXdfZG9zX21vZGUs
DQogICAgICAoaW50KXBzYnVmLT5zdF9tb2RlLCAoaW50KW1vZGUgKSk7DQogICBmaWxlX2ZyZWUo
ZnNwKTsNCiAgIGVycm5vID0gRUFDQ0VTOw0KICAgcmV0dXJuIE5VTEw7DQogIH0NCiAjZW5kaWYN
Cg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCiANCg0KIA0KDQogDQoNCiANCg0K
LS0tLS0tLS0tLS0tDQoNCkZZSSAsIG15IHRlc3RpbmcgcmVzdWx0ICwgDQoNCiANCg0KSSB1c2Ug
QmVuY2htYXJrIGFuZCB3aW50aHJheCB0byB0ZXN0IG50ZnMtM2cgYW5kIHNhbWJhICAsIHRoZSBz
dGFiaWxpdHkgaXMgaGlnaCAhICBjdXJyZW50IHRpbWUgLCB0aGV5IGhhdmUgYmVlbiBydW5uaW5n
IDE0IGhvdXJzIGFuZCBubyBhbnkgZXJyb3JzICAuDQoNCiANCg0KTXkgdGVzdGluZyBpcyB0aGF0
ICwNCg0KMT4gbnRmcy0zZyAvZGV2L3NkYTEgL3NoYXJlL3VzYl9oZGRfMV8xIA0KDQoyPiBzaGFy
ZSAvc2hhcmUvdXNiX2hkZF8xXzEgIGJ5IHNhbWJhICAobXkgdmVyc2lvbiBpcyAzLjAuMTEpDQoN
CjM+IHlvdSBjYW4gYWNjZXNzIFxceHgueHgueHgueHgueHhcdXNiX2hkZF8xXzEgICBvbiB5b3Vy
IHdpbmRvd3MgDQoNCjQ+eW91IGNhbiBtYXAgaXQgaW50byB5b3VyIGxvY2FsIGRpc2sgLGZvciBl
eGFtcGxlICAgICAgWToNCg0KIA0KDQogDQoNCkJlbmNobWFyayB0ZXN0aW5nIGlzIHRoaXMgOg0K
DQpzZWUgQmVuY2htYXJrX3dpbnRocmF4X3RvZ2V0aGVyLmpwZyANCg0KIA0KDQogDQoNCi0tLS0t
LS0tLS0tLS0tLS0NCg0KIA0KDQpOZXh0IHN0ZXAgLCANCg0KZm9sbG93aW5nIGlzIG1vcmUgaGVh
dmlseSBsb2FkaW5nIHRlc3QgOg0KDQogDQoNCnNlZSBhdHRhY2htZW50IDpXaW50aHJheF9oZWF2
eV9sb2FkaW5nX3Rlc3QuanBnDQoNCldpbnRocmF4IGhhcyBiZWVuIHJ1bm5pbmcgMTYgaG91cnMg
LGhhcyBubyBlcnJvcnMgISANCg0KIA0KDQogDQoNCiANCg0KLS0tLS0tLS0tLQ0KDQpib2IsIA0K
DQogDQoNCiANCg0KIA0K

[Linux-NTFS-Dev] Incorrect mountpoint permission application on 9/20.

[Kurt R. <ko...@ch...>]

from /etc/fstab:
/dev/hde3  /media/i   ntfs-3g
defaults,locale=en_US.utf8,uid=0,gid=1002,umask=0007    0       0

/dev/hde5  /media/f   vfat        
rw,uid=0,gid=1002,umask=0007  0   0



>From /etc/group:
mounts::1002:koder


Problem:
friends@xenon:/media/i$ groups
friends audio video

friends@xenon:/media$ ls -l
drwxrwx---  1 root mounts 12288 2006-11-23 17:33 i
drwxrwx---  2 root mounts  4096 2006-11-29 18:46 test

friends@xenon:/media$ cd test
bash: cd: test: Permission denied

friends@xenon:/media$ cd i
friends@xenon:/media/i$


>From the cd onward, user 'friends' (group NOT mounts) can read and write
to the 'i' ntfs-3g mount freely (even though he shouldn't be able to do
so), thus defying the 0007 mount option (which translates to 0770 in
'chmod' octals).  The 'defaults' option doesn't make a difference
either.


root@xenon:/etc# uname -a
Linux xenon 2.6.17-10-generic #2 SMP Fri Oct 13 18:45:35 UTC 2006 i686
GNU/Linux

It's unlikely that it's a kernel issue, as the permissions work fine for
the vfat mount.

It's the 2006.09.20 build for debian (well ubuntu actually), but since
there wasn't mention of fixing the umask option on anything after 9/20
in the changelog, I'm simply assuming it wasn't fixed or was broken
starting with the 9/20 release's mention of a umask fix.  Please smack
me and correct me if I'm definitively wrong and this is old news.

Thanks for looking into it =)
-Kurt

Re: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing

[Szakacsits S. <sz...@si...>]

On Tue, 28 Nov 2006, Anton Altaparmakov wrote:
> 
> Thank you for persisting with this.  

Yes, thank you Frans and Andree for your help. We definitely found 
something.

> I have now looked at the code and you are right it does not do the same 
> thing.  This is because when Yura ported my $LogFile code from the kernel 
> for some unknown to me (or forgotten by me) reason he did not integrate 
> clearing the journal into the mount process.  He integrated the checking 
> but not the clearing.  This is a HUGE and VERY BAD bug in libntfs and 
> means that all ntfs utilities are _DANGEROUS_ to run and can cause 
> massive and very hard to detect data corruption.  )-:

If the journal is not clean then the mount is refused. This detection was 
added later, previously the journal cleaning was unconditional because we 
didn't know if it's clean or not.

So, I don't see a big problem here. The reliability of ntfsresize and 
ntfs-3g seems to confirm this. Nobody reported corruptions, in fact, people 
are finding bad hardwares (RAM, disk, cable) and softwares during usage and 
testing. Almost like ZFS :-)))

> No wonder Vista does not boot!!!  

I still wonder why it doesn't boot. As I explained in my previous email, 
ntfsresize resets the journal unless the empty journal detection fails.

> It is amazing it took so long to find this problem.  I cannot believe we 
> managed to get away with it for so long...

For me it seems it worked as it should have. If the journal is clean, 
then theoretically it's pointless to empty. If unclean then mount is 
unconditionally refused.

	Szaka

Re: [Linux-NTFS-Dev] was: Bug#379628: CALL FOR HELP: Vista beta compatibility testing

[Szakacsits S. <sz...@si...>]

On Tue, 28 Nov 2006, Anton Altaparmakov wrote:
> On Tue, 28 Nov 2006, Szakacsits Szabolcs wrote:
>
> > I didn't have time to check the patches yet but wasn't the Vista problem due
> > to a bug in libntfs and not because of ntfsresize?
>
> The problem is that with my first patch which does not turn on unmounting 
> you end up with an ntfsresize that is horrible:

Another ntfsresize design rule was that it doesn't make __ANY__ 
modification to NTFS until it checked and analyzed the volume and it found 
to be consistent and safe for resizing. This is very important. It's even 
explicitely written in the error messages when corrupt volumes are detected 
which happen relatively often:

  NTFS is inconsistent. Run chkdsk /f on Windows then reboot it TWICE!
  The usage of the /f parameter is very IMPORTANT! No modification was
  and will be made to NTFS by this software until it gets repaired.

A lot of softwares, drivers corrupt NTFS and this is a very strong 
argument for self-protection that it was not ntfsresize which corrupted it 
because it was already damaged when user wanted to do the resizing.

> Please take the time to review the patches...

Surely I would but I don't have much free time recently, and unfortunately 
it doesn't help that seemingly you have checked in your entire private 
ntfsprogs CVS in one commmit.

To be honest, I still can't even see what the problem was. You wrote the 
journal wasn't emptied. But ntfsresize explicitely does that. Which 
function became conditional. And perhaps the problem is that that the clean 
journal detection is broken for Vista. For example, because of journal 
format change.

I have checked the ntfsresize journal reset again, without your latest 
patches. After the resize:

  ntfscat -fi 2 /dev/hda1 | hexdump
  00000000  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
  *
  02a04000

So, the journal has been reset, entirely. You say that this is not the case 
for Vista? 

	Szaka

Re: [Linux-NTFS-Dev] New ntfsprogs release?

[Anton A. <ai...@ca...>]

Hi Yura,

On Tue, 2006-11-28 at 16:52 +0200, Yura Pakhuchiy wrote:
> =D0=A3 Tue, 28/11/2006 =D1=83 11:37 +0000, Anton Altaparmakov =D0=BF=D1=
=96=D1=88=D0=B0:
> > Are we in a state to make a release ASAP?  I want to get the fixed
> > ntfsresize out there quickly...
>=20
> Argh, I definitely do not want release current ntfsmount ATM. It
> requires so more work.

Ok.

> > Yura I am asking you in particular because you can say what state
> > ntfsmount is in...  It is releasable at the moment or are you in the
> > middle of working on things?
>=20
> Here is main problems:
>       * option parsing (see below)
>       * broken "touch a b; mv a b"
>       * writing big files is totally slow, except case when volume 0-1%
>         fragmented
>       * code is still endianness unsafe (I applied everything from
>         ntfs-3g about this, but Bob Zhang fixed not all problems, eg.
>         splitting index root to index allocation do not work)
>       * valgrind reports several memleaks
>       * some other minor things
>=20
> >   There is the blockdev fuse option that you
> > want to only happen for root for example you said you wanted to work on
> > so I assume you want to finish at least that off before we release.
> >=20
> > btw. On that blockdev option.  You could simply change:
> >=20
> >  vol =3D utils_mount_volume(device, ((ctx->ro) ? NTFS_MNT_RDONLY : 0) |
> >                  ((ctx->noatime) ? NTFS_MNT_NOATIME : 0) |
> > -                NTFS_MNT_NOT_EXCLUSIVE /*| NTFS_MNT_CASE_SENSITIVE*/,
> >                  ctx->force);
> >=20
> > To:
> >=20
> >  vol =3D utils_mount_volume(device, ((ctx->ro) ? NTFS_MNT_RDONLY : 0) |
> >                  ((ctx->noatime) ? NTFS_MNT_NOATIME : 0) |
> > +                (!geteuid() ? NTFS_MNT_NOT_EXCLUSIVE : 0) |
> > +                0/* NTFS_MNT_CASE_SENSITIVE*/,
> >                  ctx->force);
> >=20
> > That would only set the option when ntfsmount is invoked as root or whe=
n
> > the ntfsmount executable is setuid root, what do you think?
>=20
> ;-) Yes, I know. But I want rewrite whole option parsing because:
>       * It is one big ugly hack (it was written when FUSE had not
>         anything for option parsing, thus every FUSE user had to write
>         its own.)
>       * Several options are not updated in CVS and adding support for
>         this require more ugly hacks (or proper rewrite option parsing)
>       * With upgrade to new FUSE API incorrect mount options are not
>         reported (also requires use of new option parsing or hacks for
>         current implementation)
>=20
> So, I see 2 variants:
>      1. Give me 2 weeks. I will fix everything and we will release great
>         new ntfsprogs with full read/write.
>      2. Apply your last patches to 1.13.1 and release 1.13.2, leave
>         everything else for next major release.

2 weeks is no problem at all.  That was about what I had envisaged
anyway...

In two weeks we can review whether to branch 1.13.1 of for a point
release or not.

> BTW, about versions. I propose to change scheme to following to avoid
> such problems in the future.

Where is the problem?

> In CVS we have always x.y.0 version. That
> will be next major release. In case if we found some important bug, we
> make x.y-1.z release, by releasing diff in the patches directory (like
> vim maintainer does). We need to separate minor version from autotools
> and keep it only in some header file for this. If one of developers
> believes that we need new z version, then he sends email to -dev list
> with patch. And if there is no objections in 48 hours, then he can put
> it to patches dir somewhere on our server and after this patch becomes
> official and distros can update their packages. I think this will
> improve stability and make less work for everyone. What do you think?

I do not understand what you mean.  What is wrong with current working
practice?  We have branches in CVS and if we need to make a bug fix
release, we can checkout the 1.13.1 branch apply the fix, commit it as
1.13.2 branch and then make a 1.13.2 release.  But that is not needed.
We have not had a release of ntfsprogs in 6 months or so so it is about
time we made a new one so I am more keen on making a full blown release
rather than just a bug fix one.

Best regards,

        Anton
--=20
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/

[Linux-NTFS-Dev] ntfs mount error

[gopesh g. <gop...@ya...>]

Hi,

I tried to install the ntfs driver on my linux laptop.
here are the steps I followed after installation:

/sbin/fdisk -l

Disk /dev/sda: 60.0 GB, 60011642880 bytes
255 heads, 63 sectors/track, 7296 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id
 System
/dev/sda1   *           1         127     1020096   83
 Linux
/dev/sda2            1913        7296    43246980    f
 W95 Ext'd (LBA)
/dev/sda3             128        1784    13309852+  83
 Linux
/dev/sda4            1785        1911     1020127+  82
 Linux swap
/dev/sda5            1913        4717    22531131    7
 HPFS/NTFS
/dev/sda6            4718        7296    20715786    7
 HPFS/NTFS

Partition table entries are not in disk order

[root@localhost /]# mount /dev/sda5 /mnt/windows -t
ntfs -r -o umask=0222
mount: wrong fs type, bad option, bad superblock on
/dev/sda5,
       or too many mounted file systems
-------
[root@localhost /]# grep -i ntfs /var/log/messages
Nov 28 20:11:34 localhost kernel: NTFS driver 2.1.20
[Flags: R/W MODULE].
Nov 28 20:14:23 localhost kernel: NTFS-fs error
(device sda5): ntfs_read_locked_inode(): Inode is not
in use! You should run chkdsk.
Nov 28 20:14:23 localhost kernel: NTFS-fs error
(device sda5): ntfs_read_locked_inode(): Failed with
error code 5. Marking inode 0x4 as bad.
Nov 28 20:14:23 localhost kernel: NTFS-fs error
(device sda5): load_and_init_attrdef(): Failed to
initialize attribute definition table.
Nov 28 20:14:23 localhost kernel: NTFS-fs error
(device sda5): ntfs_fill_super(): Failed to load
system files.
Nov 28 20:14:45 localhost kernel: NTFS-fs error
(device sda6): ntfs_read_locked_inode(): Inode is not
in use! You should run chkdsk.
Nov 28 20:14:45 localhost kernel: NTFS-fs error
(device sda6): ntfs_read_locked_inode(): Failed with
error code 5. Marking inode 0x4 as bad.
Nov 28 20:14:45 localhost kernel: NTFS-fs error
(device sda6): load_and_init_attrdef(): Failed to
initialize attribute definition table.
Nov 28 20:14:45 localhost kernel: NTFS-fs error
(device sda6): ntfs_fill_super(): Failed to load
system files.
Nov 28 20:15:01 localhost kernel: NTFS-fs error
(device sda2): read_ntfs_boot_sector(): Primary boot
sector is invalid.
Nov 28 20:15:01 localhost kernel: NTFS-fs error
(device sda2): read_ntfs_boot_sector(): Mount option
errors=recover not used. Aborting without trying to
recover.
Nov 28 20:15:01 localhost kernel: NTFS-fs error
(device sda2): ntfs_fill_super(): Not an NTFS volume.
Nov 28 20:16:08 localhost kernel: NTFS-fs error
(device sda5): ntfs_read_locked_inode(): Inode is not
in use! You should run chkdsk.
Nov 28 20:16:08 localhost kernel: NTFS-fs error
(device sda5): ntfs_read_locked_inode(): Failed with
error code 5. Marking inode 0x4 as bad.
Nov 28 20:16:08 localhost kernel: NTFS-fs error
(device sda5): load_and_init_attrdef(): Failed to
initialize attribute definition table.
Nov 28 20:16:08 localhost kernel: NTFS-fs error
(device sda5): ntfs_fill_super(): Failed to load
system files.
Nov 28 20:20:23 localhost kernel: NTFS-fs error
(device sda5): ntfs_read_locked_inode(): Inode is not
in use! You should run chkdsk.
Nov 28 20:20:23 localhost kernel: NTFS-fs error
(device sda5): ntfs_read_locked_inode(): Failed with
error code 5. Marking inode 0x4 as bad.
Nov 28 20:20:23 localhost kernel: NTFS-fs error
(device sda5): load_and_init_attrdef(): Failed to
initialize attribute definition table.
Nov 28 20:20:23 localhost kernel: NTFS-fs error
(device sda5): ntfs_fill_super(): Failed to load
system files.
Nov 28 20:20:31 localhost kernel: NTFS-fs error
(device sda5): ntfs_read_locked_inode(): Inode is not
in use! You should run chkdsk.
Nov 28 20:20:31 localhost kernel: NTFS-fs error
(device sda5): ntfs_read_locked_inode(): Failed with
error code 5. Marking inode 0x4 as bad.
Nov 28 20:20:31 localhost kernel: NTFS-fs error
(device sda5): load_and_init_attrdef(): Failed to
initialize attribute definition table.
Nov 28 20:20:31 localhost kernel: NTFS-fs error
(device sda5): ntfs_fill_super(): Failed to load
system files.
Nov 28 20:24:48 localhost kernel: NTFS-fs error
(device sda5): ntfs_read_locked_inode(): Inode is not
in use! You should run chkdsk.
Nov 28 20:24:48 localhost kernel: NTFS-fs error
(device sda5): ntfs_read_locked_inode(): Failed with
error code 5. Marking inode 0x4 as bad.
Nov 28 20:24:48 localhost kernel: NTFS-fs error
(device sda5): load_and_init_attrdef(): Failed to
initialize attribute definition table.
Nov 28 20:24:48 localhost kernel: NTFS-fs error
(device sda5): ntfs_fill_super(): Failed to load
system files.
-----------
uname -a
Linux localhost.localdomain 2.6.9-11.EL #1 Fri May 20
18:17:57 EDT 2005 i686 i686 i386 GNU/Linux
---------
kernel-module-ntfs-2.6.9-11.EL-2.1.20-0.rr.6.0.i686.rpm
-----

Please help.

thanks
gopesh




 
____________________________________________________________________________________
Yahoo! Music Unlimited
Access over 1 million songs.
http://music.yahoo.com/unlimited

Re: [Linux-NTFS-Dev] Bug#379628: Bug#379628: CALL FOR HELP: Vista beta compatibility testing

[Anton A. <ai...@ca...>]

Hi,

On Tue, 28 Nov 2006, Frans Pop wrote:
> On Tuesday 28 November 2006 13:08, Szakacsits Szabolcs wrote:
> > There are two NTFS during resizing. The original and the resized. When
> > the resizing is over then the latter is consistent and the old one is
> > irrelevant. ntfsresize doesn't work like the other utilities: mount,
> > modify, umount. It works like: mount and morph the original into a new
> > one.
> 
> I'm going to wait with further testing until you have sorted out this 
> difference of opinion.
> 
> I guess that in this context "being mounted" is something different than 
> the filesystem being mounted from a linux filesystem point of view?

Yes, it is a call to ntfs_mount() from libntfs which is the library 
provided by ntfsprogs which ntfsresize uses.

> Szakacsits' statements do make me wonder though what happens if you do 
> (try to) mount/unmount a resized NTFS partition after resizing it, maybe 
> using the available "force" options.

Works fine.

> It also makes me wonder what happens when linux is shut down. Does it get 
> unmounted then after all or is that not relevant as the partition is not 
> mounted from a linux point of view?

Not relevant.

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/

Re: [Linux-NTFS-Dev] was: Bug#379628: CALL FOR HELP: Vista beta compatibility testing

[Anton A. <ai...@ca...>]

On Tue, 28 Nov 2006, Szakacsits Szabolcs wrote:
> On Tue, 28 Nov 2006, Anton Altaparmakov wrote:
> > On Tue, 2006-11-28 at 14:20 +0100, Szakacsits Szabolcs wrote:
> > relocate_inodes() -> relocate_inode() -> at the end of the function
> > calls write_mft_record() which uses the ntfs_volume and the libntfs
> > function ntfs_mft_record_write() to do the writing.
> 
> Think about relocating $MFT.

I don't understand what you mean.  If you relocate the mft itself and you 
do not update the ntfs_volume structure and the mft bitmap attribute inode 
which is kept open for the duration of the mount then with each call of 
ntfs_mft_record_write() in your relocate_inodes() it would write to the 
old locations instead of the new relocated locations...

> > After that we have truncate_badclust_file() and truncate_bitmap_file()
> > both of which use write_mft_record() also...
> 
> The beginning of the $MFT is never relocated, so the MFT records belonging
> to these files can be safely modified in place, otherwise resizing is
> restricted to a safe size.
> 
> > Remember that what you were doing was not working for Vista and it works
> > now...
> 
> I didn't have time to check the patches yet but wasn't the Vista problem due
> to a bug in libntfs and not because of ntfsresize?

The problem is that with my first patch which does not turn on unmounting 
you end up with an ntfsresize that is horrible:

Every time you run ntfsresize and either you answer "no" to the "really 
proceed" question or ntfsresize aborts without doing anything because it 
hits a "this is not supported" case or you try to resize to a too small 
size or anything like that the volume is left dirty thus running 
ntfsresize again then fails.  This is because ntfsresize does not unmount 
the volume.  My complete patches up to CVS head cause the unmounting to 
happen but only until all the checks have passed and ntfsresize is about 
to start migrating clusters around.  At that point, before the first 
modification happens, I turn off the unmounting and from then on 
ntfsresize will run and independent of when it is going to stop (abort or 
complete), it will no longer unmount like you want it to be.  Then the 
volume is left dirty which is what you want to happen anyway.

I think it is now correct.  Please take the time to review the patches...

> You seem to mix here two different problems: the missing log file reset in
> libntfs and the unsafe umount you introduced by another patch to ntfsresize
> because you thought that it was missing by accident.

Not really, as you see above if you do not unmount at all you now end up 
marking the volume dirty unconditionally even if ntfsresize does not 
actually do anything at all.

> > Anyway, given ntfsresize is your code, if you want to insist on not
> > allowing unmounting, then can you please tell me the exact point in the
> > code at which unmounting becomes dangerous/wrong 
> 
> I must think about it. The design rule was being always consistent or
> trivially recoverable whenever we exit immediately without any cleanup.

The current code does that I believe.

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/

Re: [Linux-NTFS-Dev] Bug#379628: Bug#379628: CALL FOR HELP: Vista beta compatibility testing

[Anton A. <ai...@ca...>]

Hi,

Please note that the patch as it is has a very awkward side effect: Every 
time you run ntfsresize and either you answer "no" to the "really proceed" 
question or ntfsresize aborts without doing anything because it hits a 
"this is not supported" case or you try to resize to a too small size or 
anything like that the volume is left dirty thus running ntfsresize again 
then fails.  This is because ntfsresize does not unmount the volume.  My 
complete patches up to CVS head cause the unmounting to happen but only 
until all the checks have passed and ntfsresize is about to start 
migrating clusters around.  At that point, before the first modification 
happens, I turn off the unmounting and from then on ntfsresize will run 
and independent of when it is going to stop (abort or complete), it will 
no longer unmount like Szaka wants it to be.  Then the volume is left 
dirty which is what you want to happen anyway.

Best regards,

	Anton

On Tue, 28 Nov 2006, Carl-Daniel Hailfinger wrote:

> Hello Frans,
> hello Andree,
> 
> Frans Pop wrote:
> > On Tuesday 28 November 2006 13:08, Szakacsits Szabolcs wrote:
> >> There are two NTFS during resizing. The original and the resized. When
> >> the resizing is over then the latter is consistent and the old one is
> >> irrelevant. ntfsresize doesn't work like the other utilities: mount,
> >> modify, umount. It works like: mount and morph the original into a new
> >> one.
> > 
> > I'm going to wait with further testing until you have sorted out this 
> > difference of opinion.
> 
> Could you test the attached patches against ntfsprogs 1.13.1? It is my
> attempt at a backport for the first patch from Anton which seems to
> have agreement from Szaka.
> ntfsprogs-1.13.1-rename-MS_.diff is just a rename orgy to make
>  backporting easier and has to be applied first.
> ntfsprogs-1.13.1-vistahotfix.diff is a stripped version of Anton's
>  first patch.
> 
> Regards,
> Carl-Daniel
> 

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/