NTFS-3G: Read-Write Open Source Linux NTFS FUSE Driver
Moderator: Moderator Team
Re: NTFS-3G: Read-Write Open Source Linux NTFS FUSE Driver
NTFS-3G is safe from the point of view it will not destory a NTFS partition.
Its not safe for OS running on use. Reason it can loss means to write to the NTFS partition without windows help. So not fully functional.
Its not safe for OS running on use. Reason it can loss means to write to the NTFS partition without windows help. So not fully functional.
Re: NTFS-3G: Read-Write Open Source Linux NTFS FUSE Driver
JimGunn: Its great but of no use to ReactOS.
Re: NTFS-3G: Read-Write Open Source Linux NTFS FUSE Driver
You could use the great NTFS filesystem for ReactOS,.... isn't that of some use?Haos wrote:JimGunn: Its great but of no use to ReactOS.
Re: NTFS-3G: Read-Write Open Source Linux NTFS FUSE Driver
NTFS-3G is of no use to us since ROS can't run it. And we're not likely to extend the system ourselves in order to support FUSE.
Re: NTFS-3G: Read-Write Open Source Linux NTFS FUSE Driver
Hi Z98,
If you look at the source of pierre's branch you may see that this was imported from the linux kernel 2.5.xx.
The NTFS-3g driver contains a libntfs which he could import into his branch,NTFS-3g still does not support ACLs
or transparent compression,but much has been improved.The FUSE part of the code is unusable for ReactOS,
but NTFS 3G has a few things that the ReactOS driver does not have and it should be more endian independent,
because the can test it also on big endian architectures where you cant run reactos now.The decompression code could also
be imported to FREELDR that it can load a compressed kernel and HAL(if pierre writes the missing compression code ).
On the Linux kernel driver,there is not much work going on.
If you look at the source of pierre's branch you may see that this was imported from the linux kernel 2.5.xx.
The NTFS-3g driver contains a libntfs which he could import into his branch,NTFS-3g still does not support ACLs
or transparent compression,but much has been improved.The FUSE part of the code is unusable for ReactOS,
but NTFS 3G has a few things that the ReactOS driver does not have and it should be more endian independent,
because the can test it also on big endian architectures where you cant run reactos now.The decompression code could also
be imported to FREELDR that it can load a compressed kernel and HAL(if pierre writes the missing compression code ).
On the Linux kernel driver,there is not much work going on.
Re: NTFS-3G: Read-Write Open Source Linux NTFS FUSE Driver
Please note that NTFS-3G doesn't require the FUSE user space package anymore.Z98 wrote:NTFS-3G is of no use to us since ROS can't run it. And we're not likely to extend the system ourselves in order to support FUSE.
I guess this fact won't make any difference to your position.
Re: NTFS-3G: Read-Write Open Source Linux NTFS FUSE Driver
Yes. Its still linux-specific. FUSE or not, porting it to NT is a very difficult task without a 100% success rating.
Re: NTFS-3G: Read-Write Open Source Linux NTFS FUSE Driver
Sorry to revive such an old topic but I found new information. Someone released a compatible licensed version of FUSE for Windows!
http://dokan-dev.net/en/download/
IMHO this is one step closer to making NTFS-3g useful to ReactOS. Also, if anyone has played around with Linux distros lately you've probably noticed NTFS-3g is much, much better with handling NTFS partitions.
But, I suppose this is one of those touchy features that many people want but isn't focused on (like it has some sort of stigma.) Just look at real-time protection in ClamWin.
http://dokan-dev.net/en/download/
IMHO this is one step closer to making NTFS-3g useful to ReactOS. Also, if anyone has played around with Linux distros lately you've probably noticed NTFS-3g is much, much better with handling NTFS partitions.
But, I suppose this is one of those touchy features that many people want but isn't focused on (like it has some sort of stigma.) Just look at real-time protection in ClamWin.
Re: NTFS-3G: Read-Write Open Source Linux NTFS FUSE Driver
http://www.reactos.org/forum/viewtopic. ... 2&start=15 << Please read over here slobu
We have the same nail. You might have fuse in windows with the fuse api. But the Fuse driver uses posix and posix like device accesses. So not that far forward really. Read my other message there we are still a long way off from being able to use most of the fuse drivers.
We have the same nail. You might have fuse in windows with the fuse api. But the Fuse driver uses posix and posix like device accesses. So not that far forward really. Read my other message there we are still a long way off from being able to use most of the fuse drivers.
Re: NTFS-3G: Read-Write Open Source Linux NTFS FUSE Driver
Our requirement is very simple. Any FS driver that people want us to include has to be an IFS driver written using the Microsoft IFS SDK, or using the IFS headers that we have. Preferably MS', since ours are terribly incomplete. Since NTFS-3G does not fulfill this requirement, it will not be considered.
Re: NTFS-3G: Read-Write Open Source Linux NTFS FUSE Driver
But you should consider that there are numerous very useful fuse drivers (not only for NTFS), such as file system drivers for archives, ftp as well as for ZFS, JFS, UFS etc... These would almost never be implemented as IFS. Also note that all third-party IFS drivers I saw (even for Ext2 for example) had hazardous impact on system's stability. So I think an IFS-compatible driver that could use userspace Fuse plugins is life-necessary for ReactOS.
Although I agree with you that NTFS should be supported natively to allow ReactOS to boot from it.
Although I agree with you that NTFS should be supported natively to allow ReactOS to boot from it.
Re: NTFS-3G: Read-Write Open Source Linux NTFS FUSE Driver
Its great if it would work on ReactOS even though it wont allow booting. Still, it wont become a part of ROS code, because of various reasons.
-
- Test Team
- Posts: 802
- Joined: Thu Apr 03, 2008 2:17 pm
- Contact:
Re: NTFS-3G: Read-Write Open Source Linux NTFS FUSE Driver
That said, ROS could do with another developer. I'm sure HeisSpiters' work shouldn't be handled by one man alone.
Who is online
Users browsing this forum: No registered users and 2 guests