I would very much like to see reiser4 as an FS-option when installing ROS. But until someone actually starts impementing it, all this talk doesn't really matter....
START CODING!
ReiserFS for ReactOS & Windows -- Full Source Code
Moderator: Moderator Team
I think any good File system will work....as long as (someday) an emergency boot disk created by ReactOS will be able to read it-It is more important for users to be able to access their information in an emergency situation than the FS (Fortunately, Windows XP users can use the CD to access an NTFS partition, but it's not for the faint of heart). Simple emergency floppy disk (or CD, etc.) access to the FS without the GUI should be of utmost importance IMHO
I can Microsoft parts forgot names.
Most common check for NTFS and fat32 are stuff like norton utils.
This is not a problem we really don't want this stuff playing with reiser.
Other stuff checks for NTFS and NTFS Version(yes Version) To make sure that the features it requires are present.
This can be worked around since this software never directly interfaces with the filesystem. Provide a override system this app ask if resier filesystem is ntfs responce Yes and Version number X. Because it provides the feature to X level. Extended Attributes should let every feature NTFS be created in resier even the features of Winfs are able to be created with speed loss.
Most of the stuff that asks is server class stuff. So not really that important at first. More important is a home filesystem that works and provides some of the features of NTFS. Ie user and other protections.
By the way reiser does have emergency boot disks. The linux ones Plenty of them knoppix is nice graphical able to access the partition even burn cdroms if you have two drives in you machine one for the knoppix disk and one the burner. Even a copy of openoffice and able to print. This is really nice.
In future yes reactos will have to create its own resuce disks but reiser does not provide a problem. NTFS does since not all linux boot disks can access it.
This is not a problem we really don't want this stuff playing with reiser.
Other stuff checks for NTFS and NTFS Version(yes Version) To make sure that the features it requires are present.
This can be worked around since this software never directly interfaces with the filesystem. Provide a override system this app ask if resier filesystem is ntfs responce Yes and Version number X. Because it provides the feature to X level. Extended Attributes should let every feature NTFS be created in resier even the features of Winfs are able to be created with speed loss.
Most of the stuff that asks is server class stuff. So not really that important at first. More important is a home filesystem that works and provides some of the features of NTFS. Ie user and other protections.
By the way reiser does have emergency boot disks. The linux ones Plenty of them knoppix is nice graphical able to access the partition even burn cdroms if you have two drives in you machine one for the knoppix disk and one the burner. Even a copy of openoffice and able to print. This is really nice.
In future yes reactos will have to create its own resuce disks but reiser does not provide a problem. NTFS does since not all linux boot disks can access it.
Wha else is there?
Hey is there anything else we might wanna use? I mean what other files systems are there that are open source that are good like ntfs? seurity and reliability?
Hmm seurity and reliability
NTFS would get security but not reliability. To hard to recover from when things go bad.
http://en.wikipedia.org/wiki/Comparison_of_file_systems
Good overview ntfs size max higher than everything less not inclinde to agree with.
Fully supported Linux filesystems all have been used to there max size. NTFS max size is only able to be used on partical versions of windows. Datacenter versions.
For the facts on the cripled version being served up at moment.
http://www.microsoft.com/resources/docu ... l_tdrn.asp
Xfs and Ext3 are nice and expandable.
Reiserfs4 Most likely be in the same level as NTFS uncripled specs are a bit thin on the ground what it can do.
Ufs2 kicks NTFS into the ground at on max filesystem size 1 Yib but has a file limit lower than NTFS at only 32 PiB data center version is the only one that beats this in NTFS
Xfs at 9 EiB max file and 9EiB max partition is a nice middle ground.
Xfs, Ext3 and Reiser4 will be supported by linux read write. Ufs2 is currently supported read only. This might change.
Zfs would be intresting thinking that this is the filesystem of Solaris 10. And Solaris 10 is kinda opensource under suns licence. This one might be the top of the tree when it comes to file systems. But specs are bit sort on the ground. And lack of support on other platforms at this time would be a problem. Mind you for a file system that has only just be made open source you cannot expect any better. Nice ask to sun before using might be a good idea just to check for patents.
About Be and other os filesystems forget them most of them a nailed before you start. Note ext2 and ext3 are mostly nailed these days due to there limited size but are supported by more os that most other filesystem while providing the required features and space to add more as required.
Only other filesystem even worth a look is HFS+ Apples filesystem. Since we will have a Power PC port and Apple will have a Intel port compad is the only reason for it.
No point fighting over the details Reiser will keep as in good stead for now.
http://en.wikipedia.org/wiki/Comparison_of_file_systems
Good overview ntfs size max higher than everything less not inclinde to agree with.
Fully supported Linux filesystems all have been used to there max size. NTFS max size is only able to be used on partical versions of windows. Datacenter versions.
For the facts on the cripled version being served up at moment.
http://www.microsoft.com/resources/docu ... l_tdrn.asp
Xfs and Ext3 are nice and expandable.
Reiserfs4 Most likely be in the same level as NTFS uncripled specs are a bit thin on the ground what it can do.
Ufs2 kicks NTFS into the ground at on max filesystem size 1 Yib but has a file limit lower than NTFS at only 32 PiB data center version is the only one that beats this in NTFS
Xfs at 9 EiB max file and 9EiB max partition is a nice middle ground.
Xfs, Ext3 and Reiser4 will be supported by linux read write. Ufs2 is currently supported read only. This might change.
Zfs would be intresting thinking that this is the filesystem of Solaris 10. And Solaris 10 is kinda opensource under suns licence. This one might be the top of the tree when it comes to file systems. But specs are bit sort on the ground. And lack of support on other platforms at this time would be a problem. Mind you for a file system that has only just be made open source you cannot expect any better. Nice ask to sun before using might be a good idea just to check for patents.
About Be and other os filesystems forget them most of them a nailed before you start. Note ext2 and ext3 are mostly nailed these days due to there limited size but are supported by more os that most other filesystem while providing the required features and space to add more as required.
Only other filesystem even worth a look is HFS+ Apples filesystem. Since we will have a Power PC port and Apple will have a Intel port compad is the only reason for it.
No point fighting over the details Reiser will keep as in good stead for now.
Against it
I have voted for "No".
Reason:
ReactOS in first point is a Windows replacement.
That means, that it must be handeled and used like the real MS Windows.
It is for people who prefer Windows with its filesystem and all the other things over other Operating Systems. Or for people who have experience with Windows, but not with other systems.
If you use ReiserFS, ReactOS will be incompatible to Windows with NTFS.
ReiserFS is a Linux-FS, which is case-sensitive.
But in Windows, there existing a lot of programs which have a file called "ThePicture.bmp" and in the program itself stands "thepicture.bmp" and the programs runs successfull.
If you use ReiserFS for it, this programs will no longer run on ReactOS.
In some parts Microsfts NTFS used still the DOS 8+3 format.
For example if you have in C:\ a directory "Program Files" you can type "cd progra~1" to change to it.
I don't say that it is a advantage or a disadvantage of the NTFS to have it.
But ReactOS would be incompatible, if it don't do the same.
(And btw: For old DOS-programs it is a advatage, that the NTFS have also a 8+3 format).
For all this reasons I was shocked, if I saw that 36 people are for ReiserFS and only 12 people against ReiserFS, as the "de facto filesystem driver" for ReactOS.
I think, there existing enough Unix-like OpenSource Systems.
There existing Linux, *BSD, Solaris, Darwin (the MacOSX base), etc.
And BeOS (Zeta, Haiku) are also using a POSIX-like system with all the GNU tools.
If you prefer Linux-Filesystems and Linux-things, then use Linux together with Wine.
If you want to create a complete new Operating System, then write it or fork ReactOS.
But don't plan to make ReactOS incompatible to Windows.
Where do you want to stop with the linuxing of ReactOS?
To use ReiserFS instead of NTFS is only one step.
But I have also heard here in the forum some voices, why not use KDE or GNOME insteaed of the ROS Explorer.
Other people don't like the Windows look and feel and also want to make the window frame more Linux like.
Again: All who prefer Linux, please use Linux and not ReactOS.
ReactOS is a replacement for Windows.
I prefer it to have tons of Windows-disadvantaged in ROS, instead of having a ROS, which is incompatible to Windows.
Reason:
ReactOS in first point is a Windows replacement.
That means, that it must be handeled and used like the real MS Windows.
It is for people who prefer Windows with its filesystem and all the other things over other Operating Systems. Or for people who have experience with Windows, but not with other systems.
If you use ReiserFS, ReactOS will be incompatible to Windows with NTFS.
ReiserFS is a Linux-FS, which is case-sensitive.
But in Windows, there existing a lot of programs which have a file called "ThePicture.bmp" and in the program itself stands "thepicture.bmp" and the programs runs successfull.
If you use ReiserFS for it, this programs will no longer run on ReactOS.
In some parts Microsfts NTFS used still the DOS 8+3 format.
For example if you have in C:\ a directory "Program Files" you can type "cd progra~1" to change to it.
I don't say that it is a advantage or a disadvantage of the NTFS to have it.
But ReactOS would be incompatible, if it don't do the same.
(And btw: For old DOS-programs it is a advatage, that the NTFS have also a 8+3 format).
For all this reasons I was shocked, if I saw that 36 people are for ReiserFS and only 12 people against ReiserFS, as the "de facto filesystem driver" for ReactOS.
I think, there existing enough Unix-like OpenSource Systems.
There existing Linux, *BSD, Solaris, Darwin (the MacOSX base), etc.
And BeOS (Zeta, Haiku) are also using a POSIX-like system with all the GNU tools.
If you prefer Linux-Filesystems and Linux-things, then use Linux together with Wine.
If you want to create a complete new Operating System, then write it or fork ReactOS.
But don't plan to make ReactOS incompatible to Windows.
Where do you want to stop with the linuxing of ReactOS?
To use ReiserFS instead of NTFS is only one step.
But I have also heard here in the forum some voices, why not use KDE or GNOME insteaed of the ROS Explorer.
Other people don't like the Windows look and feel and also want to make the window frame more Linux like.
Again: All who prefer Linux, please use Linux and not ReactOS.
ReactOS is a replacement for Windows.
I prefer it to have tons of Windows-disadvantaged in ROS, instead of having a ROS, which is incompatible to Windows.
Re: Against it
That's no problem. Ext2 drivers for Windows implement it properly, so I think this really wouldn't be a problem. Only problem to see is when someone from linux etc. created two files with same names, e.g. one named "thisfile.exe" and the other "THISfile.exe", this would have to be renamed somehow then (like the short names in fat filesystems) but it shouldn't be too problematic.theuserbl wrote:If you use ReiserFS, ReactOS will be incompatible to Windows with NTFS. ReiserFS is a Linux-FS, which is case-sensitive.
But in Windows, there existing a lot of programs which have a file called "ThePicture.bmp" and in the program itself stands "thepicture.bmp" and the programs runs successfull.
If you use ReiserFS for it, this programs will no longer run on ReactOS.
Well, that's maybe a problem, when the fs doesn't support it (don't know if reiserfs does), then it had to be emulated somehow, e.g. by creating this names "on-the-fly" while accessing (don't know how much this would slow it down, maybe a bit with many files in a folder, when you do a "dir" in a dos window).theuserbl wrote:In some parts Microsfts NTFS used still the DOS 8+3 format.
For example if you have in C:\ a directory "Program Files" you can type "cd progra~1" to change to it.
I don't say that it is a advantage or a disadvantage of the NTFS to have it.
But ReactOS would be incompatible, if it don't do the same.
(And btw: For old DOS-programs it is a advatage, that the NTFS have also a 8+3 format).
In this point I agree with you. But on the other side ReactOS will need a good fs and using an already existant is much easier and faster at a point where it can be used than developing another one.theuserbl wrote:Where do you want to stop with the linuxing of ReactOS?
To use ReiserFS instead of NTFS is only one step.
But I have also heard here in the forum some voices, why not use KDE or GNOME insteaed of the ROS Explorer.
Other people don't like the Windows look and feel and also want to make the window frame more Linux like.
Off-Topic: @oiaohm: Could you please use tinyurl instead of posting so long links, it is annoying for people using low screenresolution when the thread gets that wide (think of using 800x600, you have to scroll left-right all the time to read sth. in here)
ReiserFS
I think there was a mistaken concept somewhere. NTFS is still teh logical choice of ReactOS to be completely compatible with Windows. True, it is important. However Windows itself does not rely on FAT/FAT32/NTFS or anything to that nature. Some Applications, like Ant-Virus software must check the NTFS/FAT version in order to know what to check for. Every filesystem has it's weekness and because none are the same, each may hid files/viruses and/or corrupt in different ways. The ANTIVIRUS software reacts differently to each filesystem. NORTAN works with FAT and NTFS unless something has changed. Certain programs like that may be slightly effected but then I believe that NORTAN could just add another module to check for ReiserFS too. I mean ReactOS is open source.
Normal applications will not be effected. It is really rare that aplications require to know the filesystem. Programs that must verify the Filesystem integrity are basically it.
NTFS is closed source. I do not say and never meant to imply that NTFS development should cease. I just meant to say that NTFS development is going really slow. It has taken two steps forward and a step backwards from time to time, like the rewrite of code. It is really important, agreed. However there is also a show stopper that stops security from taking place in reactOS in the mean time. Let me explain, FAT cannot hold any of the NT security descriptors. It is not developed to do such things. However NTFS can. People have been trying to develop NTFS as open source for some time (YEARS) and yet it still does not have stable write access. It can corrupt the filsystem and destroy all data on the filesystem. Are we to wait to work on Security until NTFS is perfected? How many more years will that be?
One option I was suggesting as at least in the mean time is using ReiserFS as the de facto filesystem. Now before you go off about imcompatiblities, let me attempt to explain more clear why ReiserFS and not something more. ReiserFS has attributes called extended attributes that other options may be added for. This is supposed to allow for future growth and compatibility. The NTFS attributes can be added here, so althoguh the system will be ReiserFS and not NTFS, all the NTFS attributes will be available thru ReiserFS. ReiserFS is very comparable to NTFS and matches it almost identically in most options. However it is open source while NTFS is not. No other FS I know of can add NTFS attributes other than ReiserFS. Ext2 cannot add it, in fact anyone here tried the ext2/ext3 filesystem drivers out there. Security is non-existent on Windows.
I am not talking about unixizing or linuxizing ReactOS. I am talking about ways to get NTFS attributes into ReactOS, thus allowing two-fold, 1) Allowing security to begin to take shape and 2) Increasing compatibility to ReactOS by having stable write access to NTFS attributes.
A lot of people here have stated things in turn without reading the previous posts that all state this same thing in a more in depth form. PLEASE, before you reply, read the real reason ReiserFS is prefferred, I CAN GARANTEE IT IS NOT FOR LINUX/UNIX but is it is for ReactOS. It would also benifit Windows, I am a Windows user. I have it as my primary OS, I have used Linux and like somethings, but LINUX really does not belong in a area of filesystems. ReiserFS is the best choice, because it is open source, not because it is on Linux. It also has these extendable attributes. Please people quite comparing filesystems other than NTFS and RieserFS as no other has the capability of using NTFS attributes that I know of.
I think the KDE/GNOME Question is something completely different as that would alter compatibility, but a filesystem should not alter compatibility unless the program must verify integrity of a filesystem. KDE/GNOME cannot be used. It has been dismissed that easily by developers and users alike. I agree completely it cannot, I would never suggest such things. I am all for the ReactOS GUI, but filesystems must be used to develop security. What is one of the main reasons that NTFS is used and not FAT by default in Windows installations, to allow these NTFS attributes for encryption, compression, as well as many more. ReiserFS would also allow these in the same fashion.
Okay people if not ReiserFS then how will ReactOS security be developed? Are we to ignore encryption built in, indexing, as well as many other NTFS features? FAT does not cut it, sure there are ways to compress FAT, but it is not super effective and not as well as NTFS compression. Really how are we to develop NTFS security descriptors? FAT does not allow for these. NTFS has been under development in the open source area for years, so I ask a second time are we to wait for it to finnally get stable write access that will not wack your filesystyem? Longhorn could be out long before that becomes a reality. Maybe not and I hope not, but development in that area is very slow. Oh, all that is shared with Linux kernel, will that then make NTFS compatible with Linux and make it a Linus filesystem too, maybe ReiserFS could be a Windows filesystem too. Has anyone that uses XP installed shared connection sharing to a 98 or 2000 or even NT machine? You can use your XP CD to give it the correct protocol to talk by and update a few files. The XP CD has many applications to use on non XP Windows to make it compatible, what is stopping ReactOS from installing ReiserFS in setup (with option of choosing legacy FAT) and also using the ReactOS CD to install ReiserFS in Windows using a MSI installation package?
Normal applications will not be effected. It is really rare that aplications require to know the filesystem. Programs that must verify the Filesystem integrity are basically it.
NTFS is closed source. I do not say and never meant to imply that NTFS development should cease. I just meant to say that NTFS development is going really slow. It has taken two steps forward and a step backwards from time to time, like the rewrite of code. It is really important, agreed. However there is also a show stopper that stops security from taking place in reactOS in the mean time. Let me explain, FAT cannot hold any of the NT security descriptors. It is not developed to do such things. However NTFS can. People have been trying to develop NTFS as open source for some time (YEARS) and yet it still does not have stable write access. It can corrupt the filsystem and destroy all data on the filesystem. Are we to wait to work on Security until NTFS is perfected? How many more years will that be?
One option I was suggesting as at least in the mean time is using ReiserFS as the de facto filesystem. Now before you go off about imcompatiblities, let me attempt to explain more clear why ReiserFS and not something more. ReiserFS has attributes called extended attributes that other options may be added for. This is supposed to allow for future growth and compatibility. The NTFS attributes can be added here, so althoguh the system will be ReiserFS and not NTFS, all the NTFS attributes will be available thru ReiserFS. ReiserFS is very comparable to NTFS and matches it almost identically in most options. However it is open source while NTFS is not. No other FS I know of can add NTFS attributes other than ReiserFS. Ext2 cannot add it, in fact anyone here tried the ext2/ext3 filesystem drivers out there. Security is non-existent on Windows.
I am not talking about unixizing or linuxizing ReactOS. I am talking about ways to get NTFS attributes into ReactOS, thus allowing two-fold, 1) Allowing security to begin to take shape and 2) Increasing compatibility to ReactOS by having stable write access to NTFS attributes.
A lot of people here have stated things in turn without reading the previous posts that all state this same thing in a more in depth form. PLEASE, before you reply, read the real reason ReiserFS is prefferred, I CAN GARANTEE IT IS NOT FOR LINUX/UNIX but is it is for ReactOS. It would also benifit Windows, I am a Windows user. I have it as my primary OS, I have used Linux and like somethings, but LINUX really does not belong in a area of filesystems. ReiserFS is the best choice, because it is open source, not because it is on Linux. It also has these extendable attributes. Please people quite comparing filesystems other than NTFS and RieserFS as no other has the capability of using NTFS attributes that I know of.
I think the KDE/GNOME Question is something completely different as that would alter compatibility, but a filesystem should not alter compatibility unless the program must verify integrity of a filesystem. KDE/GNOME cannot be used. It has been dismissed that easily by developers and users alike. I agree completely it cannot, I would never suggest such things. I am all for the ReactOS GUI, but filesystems must be used to develop security. What is one of the main reasons that NTFS is used and not FAT by default in Windows installations, to allow these NTFS attributes for encryption, compression, as well as many more. ReiserFS would also allow these in the same fashion.
Acctually NTFS is also capable of that but the Windows driver that accesses the filesystem, IFS I believe does not allow case sensativity.ReiserFS is a Linux-FS, which is case-sensitive.
Okay people if not ReiserFS then how will ReactOS security be developed? Are we to ignore encryption built in, indexing, as well as many other NTFS features? FAT does not cut it, sure there are ways to compress FAT, but it is not super effective and not as well as NTFS compression. Really how are we to develop NTFS security descriptors? FAT does not allow for these. NTFS has been under development in the open source area for years, so I ask a second time are we to wait for it to finnally get stable write access that will not wack your filesystyem? Longhorn could be out long before that becomes a reality. Maybe not and I hope not, but development in that area is very slow. Oh, all that is shared with Linux kernel, will that then make NTFS compatible with Linux and make it a Linus filesystem too, maybe ReiserFS could be a Windows filesystem too. Has anyone that uses XP installed shared connection sharing to a 98 or 2000 or even NT machine? You can use your XP CD to give it the correct protocol to talk by and update a few files. The XP CD has many applications to use on non XP Windows to make it compatible, what is stopping ReactOS from installing ReiserFS in setup (with option of choosing legacy FAT) and also using the ReactOS CD to install ReiserFS in Windows using a MSI installation package?
Consider the user experience:
My Windows HD is divided into two FAT32 partitions, C: and D:. Generally speaking, the C: partition is for the operating system and the D: partition is for user-related stuff such as apps and data. If I have to format a partition to Reiser to install ReactOS, where does that leave the apps and data on my FAT32 D: partition?
My Windows HD is divided into two FAT32 partitions, C: and D:. Generally speaking, the C: partition is for the operating system and the D: partition is for user-related stuff such as apps and data. If I have to format a partition to Reiser to install ReactOS, where does that leave the apps and data on my FAT32 D: partition?
I back to put a few miths to rest.
chris319.
Consider the user experience I am.
C: and D: partitions most likely would stay.
But I think the user would have to consider 2 things.
If Windows XP... runs on reiserfs as it is going there is a real chance of this. And reiserfs is created not to need defragmention.
Is the D: partition that will be changing all the time really worth leaving as fat32? Less downtime due to defraging more work time. I think it a winner sort term pain for a real fix.
Really a FAT32 to Reiserfs would be a good idea just like windows FAT to NTFS tool.
NTFS is case sensitive it the drive if people would please read.
http://en.wikipedia.org/wiki/Comparison_of_file_systems
It sorts out a lot of miths and false hoods.
It only has one minor false hood regarding the max size of NTFS. Posted the information in a earlyer post.
Linux programs/systems can be made case insensitive by using a extention called caselow. So this is just a mith nothing more just add caselow to the filesystem driver by by problem.
And I am not Linuxing Reactos. I want Reactos to be a stable safe to use OS without any other os bring it down due to incompads. Windows even does it to itself. Linux systems do not. Features might be missing tools might have to be run to fix faults caused by a older version driver access the filesystem but no data loss because something access the filesystem and did not support all features it used. Yes worst is on ext3 when accessed by a ext2 setup you have to recreate the journaling information. This is not data loss like windows and NTFS.
I would not remove Fat support at this time because it would hurt to much.
Bond007s
Consider the user experience I am.
C: and D: partitions most likely would stay.
But I think the user would have to consider 2 things.
If Windows XP... runs on reiserfs as it is going there is a real chance of this. And reiserfs is created not to need defragmention.
Is the D: partition that will be changing all the time really worth leaving as fat32? Less downtime due to defraging more work time. I think it a winner sort term pain for a real fix.
Really a FAT32 to Reiserfs would be a good idea just like windows FAT to NTFS tool.
NTFS is case sensitive it the drive if people would please read.
http://en.wikipedia.org/wiki/Comparison_of_file_systems
It sorts out a lot of miths and false hoods.
It only has one minor false hood regarding the max size of NTFS. Posted the information in a earlyer post.
Linux programs/systems can be made case insensitive by using a extention called caselow. So this is just a mith nothing more just add caselow to the filesystem driver by by problem.
No this is not true. ReiserFS driver is being developed on sourceforge.net for windows. And it is hoped when finished that windows can be installed inside ReiserFS without anyother partitions. Supporting another filesystem does not mean that reactos will not be able to use the windows driver.If you use ReiserFS, ReactOS will be incompatible to Windows with NTFS.
This is emulation section that is not required all the time. Please not you can disable this feature from a NTFS partation or create the same feature inside ReiserFS and most of the top linux parts by software emulation(the wine and dosemu methord) or anding a extended attribute to store the extra bit of infomation. This feature was added after Microsoft already created the filesystem for backward compad.In some parts Microsfts NTFS used still the DOS 8+3 format.
And I am not Linuxing Reactos. I want Reactos to be a stable safe to use OS without any other os bring it down due to incompads. Windows even does it to itself. Linux systems do not. Features might be missing tools might have to be run to fix faults caused by a older version driver access the filesystem but no data loss because something access the filesystem and did not support all features it used. Yes worst is on ext3 when accessed by a ext2 setup you have to recreate the journaling information. This is not data loss like windows and NTFS.
I would not remove Fat support at this time because it would hurt to much.
Bond007s
anyone here tried the ext2/ext3 filesystem drivers out there. Security is non-existent on Windows.
[\quote]
Yes and I would aggree. The list of file system able to do windows attributes include ext2/ext3. Reason not in the windows version there was no reason at the time and xattr had not been aquire from IBM in xfs. Linux users just wanted to access there parts from windows anding security for windows was not important. And ext2/ext3 limit of attributes not being bigger than a block in size per file why XFS and Reiser are used in the high end of linux no limit on extended attributes(xattr).
The list I can say for sure are able to do it is ext2/ext3 Xfs Ufs2 Reiser and Reiser4. I use extended attribute locks on these filesystems all the time. Little custom locking drivers addons to linux. With flags like This file can only be opened by the list of read only non print programs by other users.
The only reason I leave ext2/ext3 in the list is that the driver for windows works and with a bit of extending/updating it could do the job in the short term most likely less time than any other filesystem to get to operational state.
My personal option is NTFS development of a driver can be placed on the back burner until we have at least one operational filesystem with secuirty features enabled. Reason Linux NTFS filesystem interface driver will not stop because we are not working on it. So if they get it working we will just have to port it. Until the time of NTFS working completely we still have the windows driver to get us out of trouble when required to interface with NTFS.
I think this is a complete mistake/error/ignorance that must never be done because if you do this then you will get errors because they will change from time to time. Imagine you have a program that stores its path on 8.3 format, and c:\program files\ is returned as c:\progra~1. Then another program makes a folder called 'Program Data' on C:\. next time Program Data is reported as Progra~1 and Program Files as Progra~2. So the first program is not able to find itself. You could also generate them by date not by Alphabetical Order but if we have Program Data and then Delete it we get the trouble again.gasmann wrote: creating this names (8.3) "on-the-fly" while accessing
As windows stores it twice we should do the same, even losing space and efficience.Next, on that comparison table of Wikipedia I found that ReiserFS does not allow some Windows timestamps. Is it wrong? Is it expected to be added as metadata? Will we get files with no creation date?
How can this be possible? AFAIK, ALL filesystems need fragmentation as they work with clusters and files are of different sizes. I've read there's no method to defragment it but this does not mean it doesn't need it. In fact it'd be an important disadvantage. I've not read ReiserFS layout (By the way, can anyone post a link for its official specification?) but I don't think this could be possible (well, you could be defragmenting on the background when you work with the HD but you'd NEED it). It was also said that NTFS didn't need it and it NEEDs. You can make it more difficult to frament but it will frament. Or not?oiaohm wrote:reiserfs is created not to need defragmention.
chris319: Why don't you simple make a third partition with the new FS?
Then what? The next logical step would be to copy all data and applications to the Reiser partition without losing a single byte; this means ROS or some utility would have to be able to read a FAT partition. You then have to deal with the installed applications which have been registered to the D: partition. I suppose you could relabel the original D: partition as something else and relabel the Reiser partition to D: and hope it all works. This is a fine solution for bitheads but it might be daunting to non-bitheads.chris319: Why don't you simple make a third partition with the new FS?
I'm not saying FAT should be the default but I think it would be a mistake to dismiss FAT compatability and exclude all support for it.
Who is online
Users browsing this forum: Semrush [Bot], Trendiction [Bot] and 75 guests