[ros-kernel] Re: ReactOS GPL vs. proprietary drivers - NTFSDriverunder Linux + WINE

[Szakacsits Szabolcs]

Hi,

On Tue, 21 Oct 2003, Jan Kratochvil wrote:

> >    - security: trojans, etc
> 
> http://www.jankratochvil.net/project/captive/doc/Details.html.pl#sandbox

Very nice you thought about it (the whole documentation is very nice on
your site). But the CORBA part looks a bit scary. How about the
performance hit?
 
> > You won't be able to do it. Microsoft can not shrink volumes, only enlarge
> > it. No code in the drivers to move NTFS metadata. Oooops, immediately a
> > limitation ...
> 
> Partition Surprise rebuilds the filesystem metadata

How would you rebuild metadata? 

> (=formats

What would you exactly format?

> and writes all the data).

Metadata, data or both? Sometimes metadata is represented as ordinary
data. And ordinary data are also frequently embedded into metadata.

> It will only reuse the data blocks if they are already found on the
> right place:

You mean, they are left in their place?

> Captive:  =They can be moved in the source filesystem to the right place.
> GPLed fs: =They can be placed to the right place in the target filesystem.

What you refer here to 'GPLed fs'? What's the source and what's the target
filesystem? It's the same. I didn't check out yet in detail how Captive
works, so sorry for the confusion.

> If no FSCTL_MOVE_FILE would be used all the data blocks would be needed to
> reshuffled during filesystem resize. It would be only a performance hit.

NTFS has extensive attributes and they also need to be kept unchanged, not
lost. Just moving around data blocks isn't enough. FSCTL_MOVE_FILE must
take care about these but you can't use it for all the files.

In short, I can't see why your plan would work out. 

> As ntfsresize(1) looks safe it does not appear Captive driver for Partition
> Surprise is needed.

ntfsresize needs to be further enhanced to move more data around. E.g.
default NTFS puts some metadata at the middle of the volume what
ntfsresize can't move yet [well, maybe a one hour work, I didn't try it
out yet, but there are many other small issues also], so usually it can't
shrink to less than half of the volume (it just refuses to do so). 

In brief there is definitely need for further improvements being it
Captive, ntfsresize or whatever way.

> Various people see it various ways. I respect yours. I keep mine. 

Ok, I try to summarize. This is what you agreed related to Captive:

 - no tight (in ntfs.sys) host OS integration possible
 - no bug fixes possible
 - no performance improvements possible
 - no feature enhancements possible
 - purchase of Windows needed in some countries (even for those who only
   do recovery, forensic analyses, etc)
 - possible legal threats in some countries even if Windows was purchased

I also have no doubt that over 99% of the people also won't care how they
make their favourite OS read/write NTFS, being it legal or not, has
possible short/long term traps or not.

> IMO it makes more sense to develop GPLed filesystem such as
> ext3/Reiser/XFS.

Today and probably for the next decade(s) full NTFS interoperability is a
problem and Captive doesn't solve the above issues. On the oher hand it's
also possible there are some legal issues involved with all NTFS related
work (in some countries) so this all discussion is just a waste of time.

	Szaka