Description
On Mac OS X, and the default HFS+ volume (case preserving but case insensitive), visiting username when UserName page exists, does not open a new page creation page, like on Linux, but show UserName, displaying the name as username.
When you edit the page, the edit is done on UserName, but saved in the log as username, and then show as two entries in RecentChages.
This might confuse the user that such page exists, and he might try to link to it using ["username"], which also leads to UserName, displaying the non camelcase name.
Example
Here is RecentChanges after such edits:
Note that username and CaseInsensitive pages does NOT exists. The edits were done on UserName and caseinsensitive pages.
Details
MoinMoin 0.1 - 1.3
Discussion
You can see this as a Bug or a Mac specific feature we win by using the file system as database.
I see it as neither of them. It is just the inability of HFS (like Windows FAT/NTFS) to differentiate case. And this has ever been like that and is NOT a moin bug.
- You can enable case sensitivity on NTFS.
It does not make sense to have wiki pages using same name with different case, it just create confusion, so the mac behavior here is better then the Linux behavior.
As you don't know about peoples application of moin, you can't generally say that.
- It does not make sense in the common case.
When you try to visit username and you get UserName, you should see the real page name, and if you edit the page, it should be logged in the real name.
A possible fix is to check the correct page name, and if the case differ from the requested page name, redirect to the real page. This check should be active on case insensitive file systems.
Another fix is too treat upper case letter as unsafe, and quote them just like we quote other non safe letters. This way, UpperCase page will be saved as (55)pper(43)ase which is less readable but will work on any file system, with not surprises.
On Mac OS X, you get the real name by calling (thanks Bob Ippolito):
[20:37] <etrepum> Carbon.File.FSRef('filename').as_pathname() \
will give you the actual name on the filesystem
[20:37] <etrepum> >>> Carbon.File.FSRef('INSTALLTK.PY').as_pathname()
[20:37] <etrepum> 'installtk.py'
How can we do the same on Windows?
Fixed by correcting the page name to the real case on the file system in get_rev_dir, if a page exist. This practically fix most of the problems. See Page._setRealPageName docstring.
benchmarks show drop of 5-7% request per second when testing WhyWikiWorks. realPathCase is called 16 times for this page. Timing show that realPathCase is about 4 times slower then os.path.exists.
A realPathCase(path) function was added to util.filesys. There is a version for 'darwin' (Mac OS X), and a default version for all other platforms that returns None. To add Windows support, one has to add an nt version of this function.
Plan
Updated Help pages about this issue.
- Priority: Medium (problem with the edit-log and recent changes)
- Assigned to:
- Status: fixed on patch-907