Make preventWDAAttachments true by default

It is simply too dangerous to be left false by default. The vast majority of Appium users know nothing about this folder (~/Library/Developer/Xcode/DerivedData/WebDriverAgent-xxx...xxx/Logs/Test and specifically its Attachments subfolder), and are most likely taking the screenshots they care about explicitly in their test code anyway. One day however they will find out about it (when their disk space runs out), and it will be too late.

Here’s what happened to me, after happily running appium tests on my CI system for weeks:

1. Yesterday, just when I’m about to start off my weekend, I find out an Appium machine has run out of space. It contains a 500GB HDD with basically nothing on it except OS X, Appium, and XCode, so I have no idea what’s taking up all that space.
2. I fire up Disk Inventory X but it seems to get stuck before revealing the offending folder[s] (Having an HDD [rather than SSD] that slows the system to a crawl sure doesn’t help).
3. So I tried like 5 other similar utilities, all seemed to get stuck. Luckily, one of them (JDiskReport) had the courtesy to report which folder it was scanning, namely the ...Logs/Test folder mentioned above (funny side story - I also realized it was scanning an 8TB mounted network share I had mounted, so make sure you eject those before if you run into a similar situation).
4. I figured all those UUID type folders were the culprit and deleted them. Of course, I was wrong.
5. I noticed the Attachments folder but Finder showed it as empty. It was only after noticing Finder couldn’t calculate its size that I realized it was simply unable to enumerate its contents. A quick web search confirmed my suspicions, as a few people were complaining about this folder’s size.
6. Thankful for finally discovering the root cause of the issue, I happily fired the command line thinking I’m one rm -rf away from being home free. Emphasis on “thinking”. Even something as trivial as ls didn’t work, nor did any of the other commands suited for this situation I found on the web (ls -1 -f and find). They would all simply hang, seemingly forever. The only thing I was able to do was confirm my suspicion about the amount of files in the folder, by viewing the size of the directory entry (not the contents) using ls -lh (~220MB which apparently translates into millions of files).
7. After some more research it became clear to me that I was only left with two options: [1] run rm -rf and hope it finishes in some reasonable time (been waiting for 20 hours now, still working - people have reported running it for days before completing) [2] If that fails, re-image the machine (yes, it’s that bad).

To wrap things up, I apologize for my rant, but I wanted to demonstrate just how dangerous this folder is and how crucial it is for true to be the default for the preventWDAAttachments capability. Cleaning up the UUID type log folders as well (e.g. keep last N days) would be nice bonus, but the Attachments folder is by far the more serious issue. Thanks!

[imurchie]

The permissions logging ought to be fixed in the latest version of the driver.

I’m fine with the default being true.

[mykola-mokhnach]

The change has been merged to 1.6.4-beta