Page 3 of 5

Posted: Mon Feb 21, 2005 11:24 am
by cyborg
NTFS Read Write in Linux is still in devel, after years of development, it is still a dangerous function, while Apple HFS+ has been implemented very fast.

I think that has a source: NTFS is hard to implement.

File Permissions are per-FS-base. You dont have to use the same permissions on all disks just because you use that on one.
While ext3 supports custom permissions too, so all this could be added

"More *NIX like: /mnt/c" - thats not more unix like. /mnt ist just one of many ideas where to mount your external mounts :) most modern *nixes like latest linux distris use /media and so on. i use /win for my static windows partitions, /mnt for temporary mounts like usbkeys, loopmounts, samba and /media for changeable drives like cdrom and fd.
if you want it *NIX like, you have to make it user-editable. thats what is all about (linux is about choices). And AFAIK UNIX in special dont use /mnt, its something linux specific, but dont nail me up on that =)
but thats going off-topic. of course I would suggest to use /mnt instead of /win in standard. but best would be to use /reactos/mnt/c. why? so u can install reactos parallel to linux. or maybe: keep it up to the user, to change that.

As I said, NTFS would be adorable, but seriously:
* nobody would use ReactOS in early stages on servers, so it is not very important to have NTFS before anything else
* the bigger part of the community will grow from the sector "between linux and windows" - people who hate to be stuck in the "superOS" but cant change to linux completely. they dont need ntfs hardly.
* ext3 is better documented. early readwrite of ext and fat and readonly for ntfs would conclude in increasing usage of this file systems. which means, users, who want to use reactos on servers, will think about using ext3 instead of ntfs. and thats a good choice, because ntfs doesnt have anything inside, ext3 cant do. and: ntfs is SLOW in comparison. ext3 is hell of a fast filesystem, while fat is still faster than ntfs.

Posted: Mon Feb 21, 2005 11:28 am
by cyborg
one more "filesystem" to use IMHO:
LINUX SWAP

using swap partitions in reactos would be cool. swap partitions are faster than swap files (tm)

Posted: Mon Feb 21, 2005 4:10 pm
by Gasmann
cyborg wrote:one more "filesystem" to use IMHO:
LINUX SWAP

using swap partitions in reactos would be cool. swap partitions are faster than swap files (tm)
Yes and I think it wouldn't be that hard to implement, too :wink:
And the best thing about this is that you can save hdd space if you have Linux and ReactOS :wink:

Posted: Mon Feb 21, 2005 4:12 pm
by Pentiumforever
I think ReactOS should support SWAP files and swap partitions! because when you have windows and reactOS you sava hdd space with swap files!

Posted: Mon Feb 21, 2005 4:27 pm
by Gasmann
pentiumforever wrote:I think ReactOS should support SWAP files and swap partitions! because when you have windows and reactOS you sava hdd space with swap files!
You're right, it's best to support both swapfiles and swappartitions :wink:
The same I think for general FS support, the more Filesystems are supported the better it is :wink:

Posted: Mon Feb 21, 2005 8:51 pm
by Dr. Fred
I've just noticed that a link I posted in another thread might be useful here, too. There is a implementation of swap for windows nt but I don't think that it is much faster.

Posted: Tue Feb 22, 2005 3:26 am
by Floyd
cyborg wrote:NTFS Read Write in Linux is still in devel, after years of development, it is still a dangerous function, while Apple HFS+ has been implemented very fast.

I think that has a source: NTFS is hard to implement.

File Permissions are per-FS-base. You dont have to use the same permissions on all disks just because you use that on one.
While ext3 supports custom permissions too, so all this could be added
....

As I said, NTFS would be adorable, but seriously:
* nobody would use ReactOS in early stages on servers, so it is not very important to have NTFS before anything else
....

* ext3 is better documented. early readwrite of ext and fat and readonly for ntfs would conclude in increasing usage of this file systems. which means, users, who want to use reactos on servers, will think about using ext3 instead of ntfs. and thats a good choice, because ntfs doesnt have anything inside, ext3 cant do. and: ntfs is SLOW in comparison. ext3 is hell of a fast filesystem, while fat is still faster than ntfs.
As I said
t really doesn't matter which file system is picked so long as the network permissions are compatible with Windows/NTFS. Ultimately this comes down to the 6 basic permissions NTFS has

F-full ownership
O-ability to change ownership
R-read (list)
X-execute (run or open)
D-delete
W-append and modify
We're happy you prefer Ext3; but for compatibility, NTFS or some NTFS-like implementation needs to be done. I don't believe anyone meant that it had to be implemented right away. And not using NTFS-like file permissions does causes problems across networks. I don't know about recent releases of SAMBA but they had a heck of time early on.

Posted: Tue Feb 22, 2005 11:35 pm
by niteice
I'm certain this has been discussed before, but what about ReiserFS? It's got all of NTFS's features and a well-working OSS implementation.

Posted: Wed Feb 23, 2005 3:21 pm
by mf
The win32 design doesn't allow for POSIX paths. The exact reason why you map POSIX paths to Windows driveletters in Wine. Sorry to rain on your parade, but when the whole coLinux thing lifts off there's gonna be a lot of pain translating driveletters to POSIX paths and vice-versa. Compatibility makes it a necessary evil, but it is most definitely nothing you WANT to implement.

Posted: Wed Feb 23, 2005 4:13 pm
by SirTalon
niteice wrote:I'm certain this has been discussed before, but what about ReiserFS? It's got all of NTFS's features and a well-working OSS implementation.
Look earlier on in this thread :lol:

I'm a big fan of Reiser FS (3 & 4). Also most Linux filesystems support full ACLs (like your forced to use w/ NTFS) along with the standard unix file permissions (I still think unix permissions are better in at least 90% of all cases, because ACLs are just overkill).

IFShelper

Posted: Thu Feb 24, 2005 12:56 am
by avryhof
This is just like the Media Player discussion. Your telling the developers to do something rather than to create proper tools for doing so.

ReactOS should be able to support any filesystem someone has written a driver for. That is why the title of this post is IFShelper.

ReactOS should use Installable filesystem APIs, and document how to write filesystem drivers for them.

That way support for almost anything could be written as filesystem drivers.

it could support: Fat12/16/32, NTFS, HPFS, HFS, NFS, UDF, ISO, ext2/3. ReiserFS, OpenBFS (spelling?), XFS, GmailFS, or any number of others.

Wtih a proper installable file system API, ReactOS could be the end all, do all system for reading/writing disks.


As for now, I think the ROS Dev team should do what they have been doing. Work towards making a working NT4(.5) clone. Which means, Fat and NTFS. Besides, once your in the mood to work on something it's kinda tough to pull away from it.

Sorry to drop a Vaild point.

Posted: Thu Mar 03, 2005 11:00 am
by oiaohm
Number one NTFS Driver's are not required reasons.

If the driver system is good enought it will be able to load windows NTFS driver and use it.

So no point developing anything more than a read only NTFS driver because people need read write will be able to use the real driver due to having a licence.

We sould be looking at the better file systems. IE Xfs Ext3 ReiserFS and Jfs.

Ext3 beats NTFS on size and stable even system protection if Reactos decided to use the linux fix. That fixed alot of problems methords of lids and/or selinux(extra data in filesystem to control what apps can do)

Bigest problem I have is that Reactos is not Grub or Lilo compad. Done right would let Reactos do one thing that windows cannot do. Run inside a linux parttion. Ie you would declare somewhere in the config This compad partion directory is drive C the remaining space on the partion is free this directory in a linux compad partion. First versions could be just drive images.

The directory offseting partions paths could also be used to protect existing windows system from damage from a crashing reactos.

This would also reduce the number of partions I would have to have to be windows compad this is what I want with out losing secuitry or a lot of speed.

Posted: Thu Mar 03, 2005 11:20 am
by forart
...bit old discussion. Here are some interesting links:

Linux-NTFS Project
NTFSDOS
...
ehm...

Anyway, i think OpenBeFS would be better for ReactOS:

OpenBFS Team Page

HaPpY CoDiNg !

Posted: Thu Mar 03, 2005 11:54 am
by A-v-S
I like OpenBFS as standard FS... NTFS read support, with possible to use MS driver .. (so copy it from the ntfs parittion with the read only driver)
so you can use your old ntfs partitions....

Posted: Thu Mar 03, 2005 9:46 pm
by SirTalon
patchworks wrote:Anyway, i think OpenBeFS would be better for ReactOS:

OpenBFS Team Page
I went to that link and according to that site it doesn't look like OpenBFS is anything special.
It is supposed to become a 64 bit, journaled, database-like, multithreaded filesystem with great performance when dealing with large files.
I believe Ext3 along with the other *nix filesystems work in 64 bit mode, most are journaling filesystems, what do they mean 'db' like? Like what Reiser4 is? I don't have a clue what a multithreaded filesystem is (why would a filesystem even have threads, thats an application concept I thought?).
---
Also I would like to add that Ext3 is an incredibly durable filesystem, my laptop has lost power many times recently (crappy dell charger and battery that don't work right), and I haven't had any data loss. Just try that with NTFS.