https://bugzilla.wikimedia.org/show_bug.cgi?id=40927
--- Comment #9 from Aaron Schulz <aschulz4...@gmail.com> 2012-10-17 00:16:40 UTC --- Title.php has to deal with some transactional things: a) The file moves b) The file DB metadata moves c) The actual description page move The first two are wrapped in a transaction as best as possible, it's possibly for partitions/errors to cause: a) no move but duplicate files to be at the destination (failure to delete target files on error) b) files at the destination and description/metadata still at the target (failure to commit()). The first two are in a transaction by themselves for contention reasons. One could wrap some code in Title::moveTo() in $file->lock()/$file->unlock() calls to get all three in on DB transaction, but that would hold locks while thumbnails are purged. For this to work, the purges would need to be deferred till the description page is moved. Even still, it would be vulnerable to network partitions (failure to revert files on error or commit failure). People have made various tweaks to this area to "improve" it (one of which caused a race condition that resulted in numerous lost files). To really fix this, we'd want to redo the file layout so we only create files (under hash names or uuid4s) but don't mutate them. A MW layor would do the "pretty name" and authentication (public vs deleted files) mapping to the actual files. File delete/restore/move would just be shuffling DB rows around (plus some purges outside of the transaction), which could be in one ACID transaction. I have my doubts that anyone is willing to invest in redoing are stupid file layout anytime soon. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
