.DocumentRevisions-V100

Wait for V200?

Get It Try It

Ever seen this? You should take a look.



We've mentioned this before but it's worth mentioning again.

Do you know how to get there? Probably not.

BTW the bold print in the image's list above indicates that extended attributes have been placed on a file or more often a directory.

So how do you get there? You use Xfile to navigate to Xfile's own bundle, drill down to Contents/MacOS, then invoke the Terminal command - and in Terminal you type 'sudo ./Xfile' and follow the instructions onscreen. And viola. And then you navigate up to root and there it is. .DocumentRevisions-V100.

Copying out all those files to your own home area and inspecting them with a strings tool or utility is not a waste of time, as we pointed out earlier.

Oh they keep beating Auntie Tim's drum about how much they care for you, how much they want to protect you, but on what other 'Unix' platform will you find so many things about you being hidden away from you and without your knowledge?



That's 82+ megabytes according to the first image. You'll find a directory tree like '0/0/0' there as well. They're not trying to hide anything, not trying to hide the fact that they're hiding things. Oh no.

Not like they haven't reset the mode on it to 111 for some reason. As if when you got that far a wee mode thing is going to get you to stumble.

You start by copying it out to your Downloads directory for example, then dropping to a Terminal, clear the flags with 'sudo chflags 0 ".DocumentRevisions-V100"', then follow that with 'sudo chown -R 501 ".DocumentRevisions-V100"'. Now you're ready to go.

Our recommendation is to use our Xstrings but to each his own.

.DocumentRevisions-V100/.cs/ChunkStorage/0/0/0

What's the '.cs' stand for? Is that 'dot' to try to further obfuscate? And the 'cs' stands for 'ChunkStorage'? What's a 'chunk'? And two empty intermediate directories named '0'? Is this a Kindergarten? Did someone's five year old nephew sneak into the design lab?

The files in there are numbered sequentially for some reason. Total bulk for just this part is 72+ MB. So this must be the most of it. Gosh what an ingenious design. Let's try to dig in a bit.

This, for example, looks like bits and pieces of a NIB. What's it doing there?

<connections>
    <outlet property="delegate" destination="-2" id="21"/>
    <outlet property="initialFirstResponder" destination="98" id="134"/>
</connections>

And in fact you'll find a lot of IB stuff in there (if you're a developer).

<?xml version="1.0" encoding="UTF-8"?>
<document type="com.apple.InterfaceBuilder4.Cocoa.XIB" version="3.0"

And in fact you'll find a lot of stuff from the web too.

https://www.gettyimages.com/...utm_medium=...

So these files act as a kind of log of where you've been and what you've done. Nice to know they've been hiding all along on your computer and they never told you, isn't it?

Adobe especially seems keen on putting things in there. Most but not all URLs are in the first file.

.DocumentRevisions-V100/db-V1/db.sqlite-wal

A 'WAL' file is a SQLite Write-Ahead Log, and they really love SQLite at Apple.

The WAL file here, a mere 7 MB, is mostly local file paths - lots of screenshots. Some date back quite some time. Other file names indicate this WAL file has data going back further still.

The file 'db.sqlite' has the same.

What To Do

Obviously - for your own safety and integrity - you need to clean out that mess in a routine fashion. The question is how, for Apple won't exactly be helping you. So let's play lab rats here and you can possibly benefit.

So what we did was exit all processes save the ones we needed, including this blasted Safari browser, escalate to get back in .DocumentRevisions-V100, then remove the files at '0/0/0' and 'db.sql', then reboot into SUM, perform the perfunctory 'fsck' - just to be sure - then boot back up to here. And no damage done.

YMMV but that seems to work here, and it's definitely a good idea to do this on a regular basis. Apple might not be interested in your welfare, but you have to be.

(And yes this is easily scriptable for use in CLIX - that's your homework.)

<key>databaseStateIsTrustable</key>
<true/>
<key>tookThinningOver</key>
<true/>

See Also
Developers Workshop: .DocumentRevisions-V100