Tag: files

Hidden Preference File

Check your ~/Libarary/Preferences directory, do you have this hidden file?

I’m not keen on applications that leave cruft or secret files on my system when there’s no need to do so.

I ran into a file on my laptop called ~/Library/Preferences/.bridge01.dat as well as .bridge3_01.dat — why a preference file is hidden, I don’t know.

Suspecting the file might be part of Adobe Bridge (it wasn’t), I copied it to the desktop, and looked at the file with less from the command console. It was clearly a binary preference file.

I renamed the file to bridge01.plist and started to open it with Xcode, although seeing BBEdit could open it, thought I’d give that a shot and was nightly impressed it detected the file type and presented it as a regular XML file.

Inside was slightly cryptic, but I recognized a sequence of text starting with ESC- and it looked like a serial number. Using Spotlight I was able to find another file that had a matching string, my purchase notes for Flux 3, by The Escapers.

Again, I’m not thrilled about hidden .dat files that ought to be public .plist files in my user’s preferences directory. But at least it was a mystery solved.

Files Gone on Drobo FS with OS X Lion? Get ’em back!

Using DroboFS and OSX Lion only to discover that your Drobo shares have no content!? Yikes! But fret not, you merely have a small corruption problem brought on by the firmware, and in moments you can force a rebuild of that database and all your files will be back safe, happy, and sound with no data loss. Here’s how.

I recently updated my DroboFS to firmware 1.2.0 and dashboard 2.0.3 when I switched to Lion, and while my volume mounted there was no data in it although the Drobo lights showed there was capacity, as did the Drobo Dashboard, and the health reports indicated everything was just fine.

I spoke with Drobo Tech Support that indicated this was a known problem they are actively addressing as high priority; the problem is with Lion and their firmware, and we can expect an updated firmware release.

What’s curious about this is that if one uses the Finder and mounts the Drobo drive with SMB, using smb://Drobo-FS/, the files are there. However afp://Drobo-FS.local/ and cifs://Drobo-FS.local/ mount but reveal nothing.

A detailed description of the problem is at the article entitled: “Missing” Data (AFP) and/or CNID DB Errors. This article then leads to a second one, but is only for the brave.

Using Dropbear (SSH) with Drobo FS to regenerate the AppleDB (CNID DB) has detailed steps for regenerating the apple database.

Walt’s More Verbose Directions

  1. Using the Drobo Dashboard login to your Drobo as Administrator.
  2. Unmount all shares.
  3. Under All Devices / Settings / Admin you’ll want to check the Enable DroboApps setting, which will mount a volume entitled DroboApps on your system.
  4. Download a copy of DropBear from the Drobo Apps page.
  5. Unzip this .zip file, resulting in instructions and a compressed dropbear.tgz file . Move the dropbear.tgz file to the root of the DroboApps directory.
  6. Restart the DroboFS by going to Capacity and Tools in the Dashboard, and selecting the Tools drop down on the right side, and selecting Restart. Or, just power off the unit physically for 20 seconds and then turn it back on.
  7. When Drobo restarts, go to the Dashboard and select All Devices / Settings… / Network. Note the IP address given to the device somewhere.
  8. From OS X’s Terminal enter the command ssh root@theIPaddressAbove
  9. The default password is root, unless you’ve used Dropbear before and followed the instructions within it.
  10. Enter the command ls /mnt/DroboFS/Shares to view a list of shares on the drive.
  11. Tech Support promises the following will not cause any data loss, but anytime you’re doing reconstruction you should always have a backup (if you don’t, question your backup policy), and double check before hitting return. For each share of yours listed above, enter the command: rm -r /mnt/DroboFS/Shares/yourShareNameHere/.AppleDB and press return. Note the period indicating it’s a hidden directory.
  12. Exit Terminal by entering exit.
  13. Using the Drobo Dashboard unmount all your shares, which should be just the DroboApps share at this point; this is under the All Devices / Shares and you just uncheck all the boxes.
  14. Restart the Drobo again (see above if you’ve already forgot how).
  15. And just as important restart any Macs connected to the Drobo.
  16. When the Drobo comes up, start the Dashboard, and test the mounts. They should be working.

OS X: Incomplete and partial files

Grey folders inaccessible from Finder? OSStatus error -43? Incomplete or partial folders? Here’s what I think is causing them and quite possibly what you can do about them.

I recently bought a Drobo FS with a lot of storage to keep a lot of my photography and other files backed up, redundant, and available.

Even with a “small” source drive, pumping the data to the Drobo at high speed can take a while. This isn’t the fault of the Drobo, nor the network, it’s that there’s just a lot of stuff to push through the pipe.

About 25 Hours to Go

But I ran into an odd problem, and I haven’t been able to get a good answer as to what’s happening. This is a call to geeks.

The problem is when a copy operation fails.

This could be because one rebooted the Drobo during a long copy operation, one rebooted the machine during a long copy operation, or, more likely, OS X Finder just aborted for no good reason and rather than allowing one to try the operation again, resume, or skip the problem area, the whole batch stops.

TIP: It can sometimes be better to have multiple (concurrent but blocked) copy requests that were individually initiated, than one mega-copy operation. Finder seems to like smaller sized chunks, plus if something goes wrong, there’s less to deal with.

What you end up with is a situation that’s hard to describe without seeing it. It’s a destination directory that look like this:

Incomplete Files and Folders
  1. The folders appear as grey.
  2. The folders can not be selected or opened from Finder.
  3. The folders do not have the little triangle icon by them.
  4. The folders can not be renamed from Finder, but can from Terminal.
  5. The folders can be copied, but they copy as grey.
  6. The contents of the folders can be seen using Terminal.
  7. If you use Finder to copy over them, it sees the name in use and makes a similarly named folder with a number after it.
  8. The source files are not in use.

The question is, then, how to ungrey the folders and finish the copy?

So far, I haven’t found a way.

At the moment, I’m speculating if this is related to kFirstMagicBusyFiletype, kLastMagicBusyFiletype, or kMagicBusyCreationDate as shown in the Finder.h header.

Remember, if I have to delete the directory (which can take a while — if it can be done), and then re-copy everything again (which will take a long while), and still not be certain that copy will complete, it’s a huge investment that may not pay off.

Geeks, I know what you’re thinking — I thought it too:

Was the source drive clean?
Yes. I do a Disk Utility check on my source volumes before copying from them.
Was the destination drive clean?
Yes. I do a Disk Utility check on my destination volumes before copying to them. In the case of the Drobo, I had just formatted it, using the latest firmware, and its dashboard gave the all clear. I even peeked with their sshd application.
Did you check the file permissions?
They’re clean with the regular 700 permissions. Finder’s Info concurs.
# ls -ableO@dFGinpqT *
863913 drwx------ 3 501 501 - 264 Feb 13 19:09:02 2011 NormalDirectory/
863912 drwx------ 3 501 501 - 264 Feb 13 19:09:13 2011 WhyIsThisGrey/
What happens if you delete them with # rf -vrf badDir?
Sometimes that works, actually. Other times the delete command just hangs indefinitely, like the file is busy.That said, using the Path Finder shell, this is what you get if you attempt to delete a directory that’s acting up.

OSStatus Error -43

Any idea what an OSStatus error -43 is? Or why they’d be an invalid path inside the destination directory?

What about extended attributes? Type? Creator?
They’re clean, too. Verfied by Path Finder, stat, xattr, and /usr/bin/GetFileInfo.
# stat -x *
File: "NormalDirectory"
Size: 264 FileType: Directory
Mode: (0700/drwx------) Uid: ( 501/ wls) Gid: ( 501/ wls)
Device: 45,12 Inode: 863913 Links: 3
Access: Sun Feb 13 19:09:02 2011
Modify: Sun Feb 13 19:09:02 2011
Change: Sun Feb 13 19:09:02 2011
File: "WhyIsThisGrey"
Size: 264 FileType: Directory
Mode: (0700/drwx------) Uid: ( 501/ wls) Gid: ( 501/ wls)
Device: 45,12 Inode: 863912 Links: 3
Access: Sun Feb 13 19:09:13 2011
Modify: Sun Feb 13 19:09:13 2011
Change: Sun Feb 13 19:09:13 2011
# xattr -l -v -x NormalDirectory WhyIsThisGrey
(nothing returned)
# /usr/bin/GetFileInfo -a -tcdm *
# /usr/bin/GetFileInfo -a NormalDirectory
avbstclinmedz
# /usr/bin/GetFileInfo -a WhyIsThisGrey
avbstclinmedz

No Extended Attributes, according to Path Finder
What happens if you rsync?
Doing an rsync appears to work, but doing it to the “broken directory” does not fix it after it completes.
# rsync --progress -aPE source destination

Further Thoughts

I found an article that suggests there’s a lot more going on with the file system than most of us give credit for. It talks a lot about the importance of meta data.

More Metadata That I First Thought

Two blog posts, The State of Backup and Cloning Tools under Mac OS X and Extended Attributes led me to playing with the xattr and mdls commands.

xattr didn’t have much interesting.

$ xattr -l SomeGreyDir
com.apple.FinderInfo:
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 |................|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000020

The mdls command presented a better clue. Check out the kMDItemFSCreationDate attribute.

$ mdls SomeGreyDir
kMDItemFSContentChangeDate = 2011-02-20 14:02:19 -0500
kMDItemFSCreationDate = 1946-02-14 03:34:56 -0500
kMDItemFSCreatorCode = ""
kMDItemFSFinderFlags = 0
kMDItemFSHasCustomIcon = 0
kMDItemFSInvisible = 0
kMDItemFSIsExtensionHidden = 0
kMDItemFSIsStationery = 0
kMDItemFSLabel = 0
kMDItemFSName = "SomeGreyDir"
kMDItemFSNodeCount = 0
kMDItemFSOwnerGroupID = 501
kMDItemFSOwnerUserID = 501
kMDItemFSSize = 0
kMDItemFSTypeCode = ""

A quick romp through my incomplete folders revealed they all had a magical creation date of 1946-02-14 03:34:56 -0500.

The solution I think I need

I’m looking for a way to locate files with the kMDItemFSCreationDate
attribute set to that magic value, and then change it to whatever is in the
kMDItemFSContentChangeDate.

My suspicion is that this will let Finder, and the Apple command line utilities,
consider the file isn’t busy anymore.

Hiding Image Files in TextMate

Here’s how to hide JPG, PNG, and GIF files in your TextMate projects so bulk file operations go faster.

TextMateTextMate, perhaps the best generic programming editor that I’ve ever encountered (though I’d be willing to entertain reader suggestions), has the ability to open an entire directory at once, which is great for making bulk changes to automatically generated website files.

However, there’s one trick that I keep having to look up each time I do it, and that’s how to get that side-bar directory listing of the project files not to display image files. The reason you might want to do this is for efficient global replace options across all text-based site files.

The solution is to click the top-level directory in the project, and press the I button in the bottom right corner of the drawer.

This opens a Folder Information dialog box. In the area labeled Recursively Include Contents Matching there are two fields, one for files and one for folders. In the File Pattern field, enter this regular expression: !\.(jpg|png|gif)$

When you close the Folder Information dialog box, all files with the extensions listed will no longer be displayed.