Dev folder

[DavidCB]

I notice that when I clone my hard drive, an empty "dev" folder shows on my backup FireWire drive, on the same level as Applications, Documents, Library, System and Users. The folder is not on my original drive, though.

Any idea what this is and why it is being put there?

Thank you,

David

MacBook Pro Core 2 Duo 2.33 GHz, 3 GB RAM
OS X 10.4.10
SuperDuper 2.1.4 (v82)

[dnanian]

OSX 10.4.x started returning invalid information for the /dev folder when we ask for its metadata, so on some systems it's visible on the backup. It'll usually be hidden again once that's the startup volume, but do not remove it -- it's important, and is on the original volume -- you just can't see it.

[DavidCB]

Originally Posted by dnanian

OSX 10.4.x started returning invalid information for the /dev folder when we ask for its metadata, so on some systems it's visible on the backup. It'll usually be hidden again once that's the startup volume, but do not remove it -- it's important, and is on the original volume -- you just can't see it.

Thanks--I thought it might be something like this.

David

[dnanian]

Glad I could clarify/confirm, David.

[Leonardo]

Originally Posted by dnanian

OSX 10.4.x started returning invalid information for the /dev folder when we ask for its metadata, so on some systems it's visible on the backup. It'll usually be hidden again once that's the startup volume, but do not remove it -- it's important, and is on the original volume -- you just can't see it.

This is still happening under 10.5.4 (PPC and Intel) and not only with /dev but also with /home, /net and possibly other folders.
It is a nuisance.

Question:
if the Finder is getting the metadata for objects on the top level of the startup volume correctly, wouldn't it be possible to query for this metadata using a different method and restoring it after cloning instead of relying on the method used by the unix tool currently employed?

[dnanian]

No, it's not really possible. Finder is likely hiding these folders dynamically on the startup volume in much the same way that it applies 'special icons' to /Applications.

We're asking the file system directly for the attributes, using the documented interfaces... that's the right way to do it.