Where does ArcMap actually store my feature classes?

1641
5
02-03-2017 07:21 AM
JasonBaugh
New Contributor

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.

0 Kudos
5 Replies
MichaelVolz
Esteemed Contributor

Use ArcCatalog to look at the feature classes you have created in the file gdb and you will see the feature class names that you are looking for.  Windows Explorer just shows a collection of files and the names of the files do not correspond to the feature class names in the file gdb.

JasonBaugh
New Contributor

Thanks for the info!  I had no idea Explorer wouldn't display the file names.

0 Kudos
MichaelVolz
Esteemed Contributor

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)!!!

0 Kudos
VinceAngelo
Esri Esteemed Contributor

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

RebeccaStrauch__GISP
MVP Emeritus

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.