Michael B. Trausch wrote:
When the system is unmounted, as I understand it, it's marked 'dirty' so that the next time you boot into it, Autochk will take a look at it before booting. Except that Autochk doesn't work on any system that I've worked on, so I had to create a BartPE disc to check the systems occasionally. Personally, I've never seen that driver wipe away a system, but if you were going to start with something, I suppose I'd try to start with that one.
What do you mean autochk does not work? autochk doesn't do anything for NTFS volumes unless you manually force a check. The entire idea of a transactional filesystem is that it will never need a disk checker to be run on it after the volume is unmounted in a dirty state.
The whole point, however, is that people have tried this and come and gone in the past, and it seems terribly daunting. Is it something that can really be done before a major stable version? If users want to convert their data, can't we build a disc for them that will do that, and if so wouldn't it be smart to move their data to a partition type first, and then install ROS on that partition with the data? It won't necessarily be a one-way-street, as there *are* ways to go back and forth, even if they aren't "pretty".
Converting a partition in place from one format to another isn't really any easier than writing a filesystem driver to access it normally. In fact, it is probably harder. Then the real point is, why would you want to convert to a filesystem that does not work as well?
OTOH, would it be feasible to maybe start with the driver that's been written for Linux? How hard would a Linux driver port to Win32? (Something I wouldn't know; I don't work that low-level with either of them...)
- Mike
Not really. The entire operating environment, upper interfaces, and lower interfaces for a filesystem driver are radically different on Linux than NT.
Steven Edwards wrote:
Windows would have this same problem with NTFS on Linux. If I am under Linux and make changes to files and create files how does linux-NTFS assign the proper SID and such to the files? This has been a long time problem that NTFS has with taking a drive from one Windows box to another. Its the same situation and mostly pointless. 99% of new ReactOS are not going to care and the resources we get from having a better filesystem now can be put in to developing a NTFS replacement.
So? I already said it is a problem translating the other way. The point still is that it is a problem for us to map our views of what a filesystem is and can do onto a unix filesystem, so why bother embracing those problems which at best, have kludgey solutions.
If the ext2fsd supported ext3 journals there would be nothing wrong with using it. I mean hell right now ReactOS does not have a security subsystem so this whole discussion is a moot point. Unless you feel like implementing lsass =)
Thanks Steven
There WOULD be a problem with using it, that is what I have been saying all along. It can't efficiently handle the feature set that ReactOS expects. Maybe you can come up with some way to force it to work, but at this point, I believe that any such solution is a poor one riddled with its own problems, so even if it can be done at all, it is not ideal.
Robert Shearman wrote: You get the same problems when sharing an NTFS filesystem on a dual-boot system or when moving one between computers, unless the SIDs are well-known. I would suggest you check out the Samba presentation at the following URL for information on how Samba4 does NTFS->Unix permissions conversion so you are not stabbing in the dark: http://wiki.winehq.org/WineConf
The problem you are describing has already been solved by them in a slightly-not-kludgey way.
Rob _______________________________________________
That is not the same problem at all. The foreign system does recognize the file structure, the standard file information, alternate data streams, EFS data ( though can not decrypt it obviously ), compressed files, and so on. With regards to the SIDs in the security descriptors, yes, the foreign system does not recognize the unknown SIDs but at least it knows that they are unknown SIDs. On a Linux system when you mount a foreign ext partition, the kernel ends up thinking that it does understand the uids, but it interprets them wrongly by mapping them to random valid users on that system. For example, Joe owns the file on the primary system but when the foreign system mounts the volume, Linux thinks that it is owned by Frank who happens to have been assigned the same uid. NT at least recognizes that it has no idea who Joe is and doesn't try to claim that Frank owns the file.
The problems I am referring to are more like when Linux tries to mount a FAT filesystem. There is no security information on the filesystem that Linux understands, so what does it do? Typically it just pretends that all the files are owned and are accessible to root with r/w/x access. You get the same problem when Linux tries to mount an NTFS volume ( or when ReactOS/NT tries to mount an ext volume ). The information that is actually stored on the disk is not consistent with the information that the OS can deal with, so the information must somehow be faked or translated on the fly, and this causes headaches.
ea wrote:
It seems MS engineers already solved the problem. Try installing the full SFU suite (NIS/AD bridge, NFS server etc.) on a Windows Server 2003 DC and look at a file's properties... _______________________________________________
I am not able to try this myself so can you explain?
I think that something has been lost in this discussion so I would like to restate it. I do not think that supporting ext is bad, I just think that it is not ideal due to the problems involved as a result of the disjoint feature sets. Because it is not ideal, it should not be the filesystem of choice. Because our goal is windows compatibility, NTFS implements all the features that we need quite well, and so it is a much better choice for a preferred filesystem than ext. That is not to say that there isn't something that may be even better than NTFS, only that NTFS is a better choice, all else being equal.