Description

I cannot rename a page from e. g. "TEST" to "Test".

Steps to reproduce

do this...

Example

Component selection

general

Details

MoinMoin Version
OS and Version
Python Version
Server Setup
Server Details
Language you are using the wiki in (set in the browser/UserPreferences)

Workaround

I rename it first to "Test1" and than to "Test".

Discussion

There are missing details, which MoinMoin version which OS and which filesystem -- ReimarBauer 2007-07-05 13:41:11

Rename page action is case sensitive, but your file system may be case insensitive. This happen on Windows and Mac OS X. If you can't create both "Test" and "test" file in the same directory, you will not be able to create both pages in moin, or rename one name to the other.

Technically this can be solved by quoting uppercase letters, so "Test" page will be saved as "(54)est".

I'm pretty sure that MoinMoin is able to detect the O/S it's running under, right? What about changing MoinMoin so that it determines the case sensitivity and "does as the Romans do"? Even if it's possible to force case-sensitive semantics on a case-insensitive environment, why? Case sensitivity is a curse, not a virtue IMHO. If I were running on a UNIX-based OS, I would love to see a way to make MoinMoin, everything actually, case-insensitive. (OK, I already have that wish.) What's most important is that MoinMoin's behavior matches the case-sensitivity of the system it's running on, unless it's set up to completely hide the underlying file system's case-handling. -- -- SteveDavison

This is more or less the way moin behave today. You can create page names just like files on the underlying file system, because they are really files This behavior cause several problems, for example see MoinMoinBugs/MacHfsPlusCaseInsensitive. [--NirSoffer] From this bug link, it sounds like this problem may be solved by implementing the NT hook for returning the true filename...? --SteveDavison

Those several problems are exactly what I'm talking about, and they arise because Moin does not fully take into account whether it's running on a case-sensitive file system or not. There are likely some issues with comparison and storage of names within other files, in addition to the the renaming issue. I assume there is (or was) code in MoinMoin that goes something like:

if os.fileexists(newname):
   ERROR: cannot rename oldname to newname, it already exists
else:
   os.rename( oldname, newname)
   Do internal rename stuff

Which could be corrected with this sort of check

if os.fileexists(newname) AND (os.casesensitive OR lowercase(newname) <> lowercase(oldname))
 . . .

In an ideal world, admins would be able to choose whether they wanted their wiki to be case-sensitive or not, independent of what O/S it's running on. Below, I do not consider the case-insensitive case (as distinct from case-following) because I don't think it's relevant to any modern file system.

Wiki and O/S case-handling	Logic
case-sensitive wiki on case-sensitive O/S	Treat all names literally. MoinMoin currunt behavior should already handle this as-is.
case-following wiki on case-sensitive O/S	a) Store all filenames in lowercase, and downcase all pagenames before accessing their data in the filesystem. This allows direct page access in the file system no matter how the name is specified, (no indexing or file searching, etc.). Also allows simple detection of name collisions. b) Store the exact (case-sensitive) page name in a file with the page's other data. When the name of a page is needed for display (or ???), read it from the file c) A page rename that that differed only in its case would not involve a file-system rename; it would need only to change the contents of certain file(s). d) Always do case-ignoring compares when dealing with page names.
case-sensitive wiki on case-following O/S	a) Provide fully case-sensitive filenames by somehow escaping capital letters (like mentioned above). If possible, do not limit what characters can be used in user-specified page names b) Convert to and from these naming domains as necessary. Care should be taken so as not to litter anything but the file system with this escaping (Who ever wants to see stuff like this, even in a url?? %3faction%3dfoo%26name%3dhoo%2ddoo%3b) c) Compare all names literally and store them verbatim inside of other files
case-following wiki on case-following O/S	a) Page name comparisons always ignore case b) When a page-title is to be displayed or otherwise used, ask the O/S for the correct case of the file (If "case-following wiki on a case-sensitive OS" were already supported, the logic would already be in place to read this from a file...) c) recognize that renames to change only the case are valid, even when the OS reports that the new name already exists.

Now that I've written it up, I think it would be a great thing to have. If the code were factored correctly to abstract out a few operations (page names match, page name identical, convert filename to pagename, convert pagename to filename... I think that's all ), it wouldn't even be a messy thing. -- SteveDavison 2007-07-07 04:03:00

Plan

Priority:
Assigned to:
Status:

CategoryMoinMoinBug CategoryForMoin2

MoinMoin: MoinMoinBugs/RenamepageCasesensitive (last edited 2010-01-12 14:10:55 by PascalVolk)