Page MenuHomePhabricator

Renaming a page in File namespace without a file associated triggers an error
Open, Needs TriagePublic

Description

While looking for a source of T226922 problem I noticed that moving any page in File namespace with no associated file (only a wikitext page) to any name in any wiki fails with error message:

The page could not be moved, for the following reason:
Could not delete the page or image specified. (It may have already been deleted by someone else.)

If there is a reason to block renaming such pages (however I doubt that this should be blocked), the errer message is at least misleading.

Tested on the following pages:

https://commons.wikimedia.org/wiki/File:Nov%C3%A9_Dvory_(Sedlec-Pr%C4%8Dice).jpg
https://pl.wikisource.org/wiki/Plik:Test
https://test2.wikipedia.org/wiki/File:Test30.svg

(trying to rename to another name with the same jpg/svg extension)

Event Timeline

Ankry created this task.Jul 9 2019, 3:06 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJul 9 2019, 3:06 PM
Ankry renamed this task from Renaming a page in File namespace without a file associated, triggers en error to Renaming a page in File namespace without a file associated triggers an error.Jul 9 2019, 3:09 PM
Wargo added a subscriber: Wargo.Jul 9 2019, 3:15 PM
Restricted Application added projects: Commons, Multimedia. · View Herald TranscriptJul 10 2019, 3:21 PM

What's the use case of moving such pages in File namespace? The pages should be deleted as they should not be created in the first place [1]. And indeed your two examples above have been deleted, only the pl.wikisource one remains and you created it for the purpose of this report.

[1]. The real bug here, I think, is to disallow creating pages in the File namespace completely. Commons and Enwiki (and probably other wikis) already have policies to speedily delete such pages. It should be enforced by the software.

Ankry added a comment.EditedApr 9 2020, 11:25 AM

What's the use case of moving such pages in File namespace? The pages should be deleted as they should not be created in the first place [1]. And indeed your two examples above have been deleted, only the pl.wikisource one remains and you created it for the purpose of this report.

[1]. The real bug here, I think, is to disallow creating pages in the File namespace completely. Commons and Enwiki (and probably other wikis) already have policies to speedily delete such pages. It should be enforced by the software.

These were rare cases, but I needed them while manipulating page history. I know two cases:

  • some edits were errorneously assigned to wrong files (likely due to some bug) (description of file A was assigned to file B and description of file B was assigned to file A; and the bug was not only about wikitext, but concerned revision description, also)
  • a file with deleted revisions was moved; and the revisions needed to be undeleted and merged with the file history after the move (they remained under the old filename)
  • some edits were errorneously assigned to wrong files (likely due to some bug)

In that case, the bug should be reported so that the root cause can be found and fixed to prevent more assignment of erroneous edit in the future. Masking the problem by manual workaround is not a good solution in my view.

  • a file with deleted revisions was moved; and the revisions needed to be undeleted and merged with the file history after the move (they remained under the old filename)

That looks like a separate bug to me. When a file is moved, the software should move it with its complete revisions deleted or not deleted. No revision should left behind for human admin to manually later 1. undelete, 2. merge, and 3. re-delete again.
I cannot verify this bug myself though. If you can confirm that's the case, it should be reported as a distinct bug.

Ankry added a comment.Apr 9 2020, 1:12 PM
  • a file with deleted revisions was moved; and the revisions needed to be undeleted and merged with the file history after the move (they remained under the old filename)

That looks like a separate bug to me. When a file is moved, the software should move it with its complete revisions deleted or not deleted. No revision should left behind for human admin to manually later 1. undelete, 2. merge, and 3. re-delete again.
I cannot verify this bug myself though. If you can confirm that's the case, it should be reported as a distinct bug.

I disagree. Moving also deleted images when undeleted ones are moved, will make current history splitting process impossible.
The process is

  • delete all revisions
  • restore only the revisions that should be moved under another name
  • move the file/page without leaving a redirect
  • restore remaining deleted revisions
Ankry added a comment.Apr 9 2020, 1:45 PM
  • some edits were errorneously assigned to wrong files (likely due to some bug)

In that case, the bug should be reported so that the root cause can be found and fixed to prevent more assignment of erroneous edit in the future. Masking the problem by manual workaround is not a good solution in my view.

This appeared during some incident with a broken software version, never observed again.
Our volunteer time is limitted, and sometimes we have to choose whether to fix on-wiki results of bugs or report side-effect issues that are unlikely to be useful for anybody in future.

Definitely worth reporting if this happens again. But neither reporting this, nor fixing the underlying software bug will fix on-wiki results of the bug, which this task is about.

Bugs happen (even if they should not) and we need to be able to do maintenance tasks to fix the result of the bugs (not ignore them or consider them non-existent)

Jony added a subscriber: Jony.Apr 10 2020, 9:24 AM