= Description = I cannot rename a page from e. g. "TEST" to "Test". == Steps to reproduce == ## Describe the steps needed to reproduce the bug. If we can't reproduce it, we probably can't fix it. 1. do this... == Example == ##Add URL that show the bug, screenshot or test wiki markup that fail... ##URL: ##attachment:screenshot.png ##{{{ ##Example wiki markup that fail ##}}} == Component selection == ## Where you think is this bug happening ? (general, plugin [plugin name], theme [theme name], ... * general == Details == ## If you got a traceback, please save the traceback page as html and attach here: ## attachment:traceback.html ## if the bug is in this wiki, just kill the table and write: This Wiki. ## If a traceback is not available, please fill in the details here: || '''!MoinMoin Version''' || || || '''OS and Version''' || || || '''Python Version''' || || || '''Server Setup''' || || || '''Server Details''' || || || '''Language you are using the wiki in''' (set in the browser/UserPreferences) || || == Workaround == ## How to deal with the bug until it is fixed I rename it first to "Test1" and than to "Test". = Discussion = There are missing details, which MoinMoin version which OS and which filesystem -- ReimarBauer <> 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-'''in'''sensitive 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 <> = Plan = ## This part is for Moin``Moin developers: * Priority: * Assigned to: * Status: ---- ## If you are a moin core developer, replace the category to Category* in these cases: ## Category MoinMoinNoBug - if this is not a bug. ## Category MoinMoinBugConfirmed - if you can confirm the bug on current code. ## Category MoinMoinBugFixed - after the bug is fixed in current code. CategoryMoinMoinBug CategoryForMoin2