Where does ArcMap actually store my feature classes?

Question

ArcGIS 10.4.1 for Desktop Basic License - Windows 7

I have always assumed Arc stores the files associated with my feature classes in the directory of the GDB I made those classes in.  When I navigate to that GDB directory with Windows Explorer there are no files with the names of my feature classes except for lock files (and those disappear as expected after I close ArcMap).  Shapefiles I have created or imported into the GDB do appear in its directory.  Are the feature classes I have created in there somewhere as well (inside one or more of those "a0000000X" files)?  Am I confusing myself by assuming feature classes are made up of a similar looking cluster of files the way a shapefile is?

I'm trying to get all my bases covered for data back up purposes.

RebeccaStrauch__GISP · Answer

Just to second Vince's warning not to copy the shapefile files to a fgdb folder.  I have had users do this, thinking it was a good idea to keep them all in one place.

This can cause strange behavior when trying to access the feature classes and/or shapefiles in an mxd or catalog.  You don't necessarily get an error message that makes sense or that points this out.  But I have had users do this and typically once we move all the shapefile files out of the folder things will work as expected once again.

VinceAngelo · Answer

Be careful! A "shapefile" is a specific set of files with a published set of formats.  It is not possible to create a shapefile "in" a file geodatabase.  Creating a feature class in a file geodatabase creates a new table within the FGDB, which is allocated the next available "slot" in the file geodatabase naming scheme. When you import a shapefile into a file geodatabase, you are creating a new table with a similar schema, but the data is no longer in shapefile format.

If you physically place the shapefile set member files in the ".gdb" parent folder, you will render these files invisible to Desktop or Server, because a ".gdb"-suffixed folder has a special meaning to the data discovery subroutines.

The "system catalog" approach used in file geodatabases (to store the file names and column properties in tables of the geodatabase schema itself) is an old, old trick, that predates the "INFO" days of Arc/Info.  It is also used by PostgreSQL; you can see this if you ever wander into a tablespace directory owned by the 'postgres' user.  Oracle and SQL Server do the same, but the virtual tables are hidden in the black-box implementation of "tablespaces" and "filegroups".

In order to archive a file geodatabase you must capture ALL of the files under the ".gdb" directory (including the directory itself, but with the possible exception of the ".lock" files).  Creating a new table will create new files and modify others.  Adding rows to a table will modify the data file and any index files.  You can guess which "slot" is issued to which table by the growth pattern, but it is not in any way "safe" to archive only the data files in the slot without the framework that supports the content.

I should probably also mention that file geodatabase is recommended for local, not network-shared, use.  Something about the perfectly reasonable file access pattern used in the ArcObjects and FIle Geodatabase API makes for a significant (~2x) I/O performance penalty over a network.

- V

mvolz47 · Answer

It's confusing at first, but after you get used to ArcCatalog it's no big deal.

Now an ArcCatalog type application needs to be added to Pro (desktop eventual replacement)!!!