Submitted by Freeloader is now able to read files and follow symlinks from btrfs partition. One major issue is left here – case sensitivity.
Another step of progress.
Freeloader is now able to read files and follow symlinks from btrfs partition. One major issue is left here – case sensitivity.
Another step of progress.
I’m pretty sure case sensitivity is a minor issue… and they should just do the same thing windows does with NTFS. On creation or rename file case is prserved on the disk lets say you rename ABC to abc however… what happens? since the bootloader doesn’t modify files on disk… there is no problem.
C:\test>dir
ABC
C:\test>rename aBc abc
C:\test>dir
abc
NTFS iteslf *is* case sensitive and you can read the case of filenames but accesses to any file handle has it’s name/path case desensitized first. It’s the windows API that is case insensitive.
https://superuser.com/questions/266110/how-do-you-make-windows-7-ful…
Edited 2018-07-31 02:31 UTC
Windows API also provide Access to GUID to any of the private/public folder and files of thé file browser.
The original effort was to make available all files from the file explorer in a hierarchical absolute tree of everything.
This technique is générally used by low level developers to identify an information resource.
Researchers on information and information présentation also try to rely on a tree of everything you can find in a dictionary.
Database developers maintain relations, entities and sometimes refer to the atomic representation of the information : its name and its content.
Tickets to wonderland will show themselves to you when you get back to School, trying to get the best of REACTOS, with récent linux compatibility add-ons, Windows Me also allows to run flawlessly Windows compatible programs and IS really simple to hack or crack…
There was a huge discussion a while back about this…
http://www.osnews.com/thread?657730
For BTRFS to work like NTFS, it would need to support case-insensitive collation on it’s indexes. Afaik, it currently doesn’t. That isn’t to say that is the only way to support CI, but that is how NTFS does it.
tldr; While NTFS is a case-sensitive file system, it also has specific support built into it for case-insensitivity, it is not just something layered on top of it.
That’s interesting, but still you can implement that collation at a higher level and nothing above that knows.
Perhaps not ideal… but ensuring that the API is setup that way would make sense especially as you add support for more filesystems.
cb88,
What approach were you thinking about? The obvious approach of storing case insensitive filenames directly into a purely case sensitive file system can work, but it becomes rather inefficient at filename lookups. If the filenames are not collated by case, it implies a full directly scan, which is costly for large directories.
The discussion that galvanash linked to has an example of this.
An OS could theoretically eliminate the full scan by having a second externally maintained case insensitive index and/or pre-collating & normalizing the filenames before submitting to the case sensitive FS and storing the case information on its own. Non-standard extensions like this would make the FS less portable obviously with additional risk of getting out of sync, but could work.
I’d be skeptical for these extensions to make it into the kernel proper on linux, but there is a fuse implementation for anyone interested:
http://www.brain-dump.org/projects/ciopfs/
The performance is likely to be poor.
Edited 2018-08-01 06:41 UTC
Also since WinBtrfs is open source couldn’t you just implement it there? Or would that break compatiblity with Btrfs in some way I’m not understanding…
I thought about it a bit more and get what you are saying now. It would be a performance issue but not a functionality issue though…
quoting for the winehq wiki apparently Btrfs can support a case insensitive index perhaps as meta data or someting? “btrfs can easily support a case insensitive index”
Edited 2018-08-02 01:48 UTC
cb88,
I haven’t really followed btrfs development, but I would think it shouldn’t be that difficult either: normalize filenames prior to accessing the index and store the original names as metadata. Output the metadata when listing a directory.
I do see value in supporting case insensitive file systems. Obviously reactos has a very good reason: compatibility with windows. But even on linux case sensitivity in the file system often translates to unwanted case sensitivity in urls on web servers, which I dislike. However I’m not sure whether the official btrfs team would be willing to incorporate this functionality in the standard?
Apparently Moneysoft, erm, Microsoft is going to have people pay for Windows on a monthly rental basis… Personally, I for one am not happy about this and will obviously be looking at what alternatives there are out there once again when this becomes a reality.. Who knows, maybe these guys will be far enough through their project to make a real contribution!
https://www.computerworld.com/article/3293429/microsoft-windows/with…
Why does every post about ReactOS have to come back to Microsoft being money-grabbing baskets?
Well, what was the point of reactos, if not to create a free as in beer and free as in freedom os compatible with windows?
I’m not 100% convinced that the free as in freedom matters nearly as much to most people as the free as in beer part of that. So yeah, I expect a lot of those comments on reactos stories.
But the real problem is man power. They don’t have nearly enough to keep pace with the windows dev team, much less make up ground. It will never meet any goal of achieving feature parity with windows. It may be good enough for some people with specific use cases. For me, I’ll just buy windows if or when I need it. Which will only be when I’ve exhausted all other means of getting a solution.
I suspect a Windows XP “clone” without all the bloat and improved security will be very welcome for many people. I know countless people who were willing to swallow an upgrade to Windows 7 (because it’s stil familiar enough), but unwilling to swallow Windows 8 and newer because of the drastic departure in user interface.
There’s an abundance of useful Win32 software out there still – and until that disappears, I suspect it’s a viable and familiar platform for most people who have used Windows for the last 30 years.
I personally use Windows 10 because it still runs on my old POS hardware reasonably well and I’m flexible enough to conform to Microsoft’s shitshow UI disaster (I’m still waiting for all the control panel/settings panels to be ported to the new UI…). My biggest gripe is the forced updates that I have to constantly dance with every month. Without those, I’d find Win10 to be more amenable.
On the other hand, I could easily go back to using Windows XP/7 if I trusted that they would be maintained and updated with hardware and security updates – so switching to ReactOS would be fine for someone like me, assuming it was stable and secure.
Assuming security and stability, is not a great idea. I don’t think any security researchers are actively diving into the code base or probing.
I didn’t claim it was stable or secure. My point was that I could probably use it if it was.
On the bright side, ReactOS seems to borrow a lot of code from other long-standing FOSS projects, so it probably benefits from the maturity enjoyed by those projects.
I don’t think maturity works via inheritance.
Differentiating files using case is only a trouble make. That case is used “inside” the files, that’s not the problem. And on Linux you can even have files that are perfectly named the same, including case, yet using different code point. Just because making things consistent would be too easy. Why not saving the whole data in the file name if we’re going down that path ?
No, case sensitivity is great!
bob
Bob
boB
BOB
Try saying those out loud. I bet you’d pronounce them differently. Probably because they are different. Treating them the same is limiting the expression of the user.
Furthermore, what about accented or diacritical marks on chars? Should those be ignored too? What about Asian char sets that have multiple chars that have the same meaning? Should those be “case sensitive” or not?
What about the alternative UTF-8 versions of letters that look the same?
The rules that you’d have to follow in this world of trying to guess what the user means by entering in different chars, is a crazy, unexpected, unknowing one where each implementation of it will behave differently.
However… All of those crazy things I just mentioned can also be used to intentionally confuse users and cause them to approve things they shouldn’t.
Languages and charsets are messy.
So you think a user accidentally deleting Bob instead of bob is an user error? If so I hope you aren’t near anything directly interfacing to user, even if those users are bit pushers. It goes against psychology, user expectations, reason, and technology.
Um, ok. Duly Noted. How about going against moral fibre? Does it also go against the constitution? UN Declaration of Human rights? Asimov’s three laws? Federation’s Prime directive? Any more bold, grand declarations of extreme incorrectness you missed? There must be other ways to list my sins.
Computers are already a pitfall for users, even knowledgeable users, so why making things more complicated than it is already ? Because you want to have the ability to express your poetry in the file names ? Keep some things simple and stupid and skip listing your sins. A file name wouldn’t be enough.
We are talking about what a file system should be capable of.
Point of order, right things should be solved at the right level. If you are talking about an underlying system being too complex, the solution isn’t go make the system less complex, but to provide a better user interface on top that hides the complexity for the end user.
If I were writing an application that saved files, I might warn ore even prevent them from doing things that may confuse them. That’s the right way to make things easy for an end user, at the edge.
Many people have problems with the concept of a computer that can have multiple applications open at once. I don’t think the proper solution to that is to remove multitasking from the kernel… But for a kiosk, change the UI to prevent multi application use. No kernel hacks necessary.
I also note that no one has really addressed the points I made in the first point about other confusing aspects of file naming. Its a can of worms. Best dealt with at the UI level of the application. Provide a library, sure and promote it as a recommended pattern. But let a file system be a file system and not a user interface.
IDONOT~1.TXT
For me, that would mean normal users shouldn’t be exposed to the file system at all. The file system should remain a precision storage management for internal and scripting use.
For normal users, they should remain in the fuzzy world of probabilistic name/content, pseudo-hierarchical, matching.
AS/400 it is!
If the file system interface was “smart”, it could flag that there is a Bob file and a bob file, and ask the user confirmation of which one should be deleted…
A case preserving context is far more dangerous for user errors than a case sensitive context in that seeing that a Bob file name is echoed back by the system as Bob rather than BOB or bob suggests to the user that Bob is treated as different than BOB and bob…..
Regarding how users treat warnings to begin with…
The feedback an user receives about case in filenames is confusing.
An user creates a file named BoB. The operating system echoes the name as BoB. It is also shown as BoB in the list of files provided in the file-open dialog of an application.
So, the user legitimately assumes that BoB and bob would be distinct entities/files while they point to the same entity/file for the operating system.
The sin is in respecting the case in names for the user interface and ignoring it for operations on the entities represented by these names.
Go into ‘c:\WINDOWS\system32’, *not* ‘C:\Windows\System32’, and type ‘ReGeDiT.eXe’, *not* ‘regEdit.exe’, and *never* ‘regedit.exe’