With the 4.3.2 patch we’ll be testing some new file optimization tech. As you may be aware, with previous major expansion patches (2.0, 3.0, 4.0, etc.) we’ve carried out a time-consuming process to reorganize the game files currently installed on your hard drive to integrate all previous patch files, essentially ‘cleaning up’ what’s on your computer and reducing the full installation size. This process used to require an amount of free hard drive space double that of the entire installation size to complete, which is why we’ve reserved them for large expansion-sized patches.
The new tech we’re testing with the 4.3.2 PTR will process these cleanups with no additional hard drive space required beyond what the patch is adding. Because of that you may see them appear more frequently with patches.
While the cleanup is occurring you’ll see a specific message on the launcher informing you the process is currently taking place. If you encounter any issues with the new process please be sure to visit our support site at http://www.battle.net/support/
Will this new tech help deal with the issue of huge game size via its /Data/Cache folder? You've mentioned that this tech supposedly reduces the install size via optimization, and I do have to say that the Cache folder currently utilized by WoW is anything but optimized (it's all duplicated files and "converted" files when any real patch method would have already had the files in their proper format in the first place).
I'm really hoping that this does address that problem, as WoW patching, and the resulting Cache building on an SSD, even an 80 GB SSD, can cause the SSD's NAND cells to be completely written to (even if some are technically "free"), causing severe write degredation. I've had recent issues where even on my 120 GB Vertex 3 SSD the write performance upon exiting the game was so abysmal that it literally took two full minutes just to write the preference files to their respective location. I know those are the tiny 4k writes that are worst case scenario for any drive, even an SSD, but it shouldn't take that long for an SATA3 SSD to write those files, especially when connected to an SATA3 controller as mine is.
My current install is:
29.6 GB on disk (29,587,202,302 bytes) for 6,412 items
My current Cache folder is:
10.6 GB on disk (10,604,149,257 bytes) for 63 items
Considering those files are all duplicates and conversions of data already in the MPQ files, that's a pretty huge chunk of wasted space. This is on top of the minimum of four write cycles to different NAND cell locations for each file that is swapped in or out (X -> Y location, A (replacement for X) -> B, and then a null cycle (marking the data as "empty" for the cells no longer referenced by the file marker).
Your Mac dev team recently succeeded in a first step toward fixing the 1080p->1080i redirect issue in OS X's client, so I know you folks do work on things that are intended to make quaiity of life better for us on our computers. Could you tell us whether or not this new patch method (or rather, a return to the old patch method you used to use, which didn't require the /Cache folder?) addresses the concern listed above?
P.S. - You may wish to refrain from ending a post with a / character. When a / is directly adjacent to a hashtag (quote, bold, underline, etc) the forum's software thinks its invalid code and won't let you preview or commit to a submission.
I wouldn't be surprised if this rears its head in the website API functions as well. Might want to pass this along to the webteam so they can find a workaround.