Skip to main content

DeleteOrphanFiles

The DeleteOrphanFiles action identifies and deletes orphan files in a table that are not reachable by any valid snapshot. This is essential for reclaiming storage space from failed writes and other operations.

Interface

Overview

Orphan files can accumulate in a table for several reasons:
  • Failed write operations that didn’t commit
  • Interrupted jobs that wrote data but didn’t create snapshots
  • Files from unsuccessful transactions
  • Leftover files from testing or development
The DeleteOrphanFiles action:
  • Lists all files in table storage
  • Identifies files not referenced by any snapshot
  • Safely deletes files older than a safety threshold
  • Can process both data files and metadata files
This operation lists all files in the table location and is expensive for large tables. Use with caution.

Methods

location

Specify a location to scan for orphan files.
Parameters:
  • location - The path to scan for orphan files
Returns: this for method chaining Example:
If not set, the root table location will be scanned, potentially removing both orphan data and metadata files.

olderThan

Only delete files older than the specified timestamp.
Parameters:
  • olderThanTimestamp - Timestamp in milliseconds (from System.currentTimeMillis())
Returns: this for method chaining Example:
Defaults to 3 days ago if not specified. This safety measure prevents deleting files from concurrent operations.
Never use a very recent timestamp. Always allow sufficient time for concurrent operations to complete.

deleteWith

Provide a custom delete function.
Parameters:
  • deleteFunc - A function that accepts file paths to delete
Returns: this for method chaining Example:
Use a custom delete function to preview orphan files before actually deleting them.

executeDeleteWith

Provide an executor service for parallel deletion.
Parameters:
  • executorService - The executor service for parallel deletes
Returns: this for method chaining
Only used if a custom delete function is provided or the FileIO doesn’t support bulk deletes.

prefixMismatchMode

Control how to handle files with mismatched authority/scheme.
Parameters:
  • newPrefixMismatchMode - Mode for handling prefix mismatches
Returns: this for method chaining Modes:
  • ERROR (default) - Throw an exception on mismatch
  • IGNORE - Skip files with mismatches
  • DELETE - Consider mismatched files as orphans
Example:
Use DELETE mode only after manually verifying all mismatches. Deleted files cannot be recovered.

equalSchemes

Define schemes that should be considered equivalent.
Parameters:
  • newEqualSchemes - Map of equivalent scheme groups
Returns: this for method chaining Example:

equalAuthorities

Define authorities that should be considered equivalent.
Parameters:
  • newEqualAuthorities - Map of equivalent authority groups
Returns: this for method chaining Example:

Result

The Result interface provides information about deleted files.

Methods

orphanFileLocations() Returns the paths of all deleted orphan files. orphanFilesCount() Returns the total number of orphan files deleted.

Usage Examples

Basic Orphan File Deletion

Custom Time Threshold

Preview Mode

Specific Location

Handle Scheme Mismatches

With Progress Tracking

Safety Considerations

Always follow these safety practices:
  1. Use appropriate time thresholds: Never delete recently written files
  2. Test in preview mode first: Use a custom delete function to review files
  3. Understand concurrent operations: Ensure no writes are in progress
  4. Handle scheme mismatches carefully: Use equalSchemes and equalAuthorities appropriately
  5. Monitor execution: Track deleted files for verification

Best Practices

  1. Run during maintenance windows: Minimize concurrent activity
  2. Use conservative time thresholds: 7+ days for production tables
  3. Preview before deleting: Always run in preview mode first
  4. Schedule regular cleanup: Run periodically to prevent accumulation
  5. Monitor storage savings: Track the result to measure impact
  6. Document scheme equivalences: Maintain a record of equal schemes/authorities

Performance Considerations

Costs

  • Lists all files in the specified location (expensive for large tables)
  • Requires reading table metadata
  • May require multiple API calls to cloud storage

Optimization Tips

  • Use location() to limit scope to specific directories
  • Run during off-peak hours
  • Consider parallel execution for very large tables
  • Use bulk delete APIs when available

When to Run

Run DeleteOrphanFiles when:
  1. After failed operations: Jobs that crashed or were cancelled
  2. Storage costs are high: Significant orphan file accumulation
  3. After major migrations: Moving or restructuring tables
  4. During maintenance: Regular cleanup schedules
  5. Before decommissioning: Final cleanup before table removal