pentaho/pentaho-kettle · error · FileSystemException

vfs.provider/delete.error

vfs.provider/delete.error

Error message

vfs.provider/delete.error

What it means

JCRSolutionFileObject.delete() calls doDelete() to remove the file in the repository, then handleDelete() to update the VFS cache. If handleDelete() (or doDelete()) throws any exception, it is wrapped in a FileSystemException with code 'vfs.provider/delete.error' and the file's name. It means the deletion succeeded/failed in the repository but the local VFS state could not be reconciled, or the underlying delete itself failed.

Solutions

  1. Check the cause of the FileSystemException to see if the file was actually deleted in the repository (then just refresh the file system cache)
  2. Call refresh() on the file object / parent and retry
  3. Reconnect the repository if the session expired, then retry deletion
  4. Verify delete permissions for the repository user

Example fix

// before
fileObject.delete(); // may throw vfs.provider/delete.error
// after
try {
  fileObject.delete();
} catch ( FileSystemException e ) {
  fileObject.refresh();
  if ( fileObject.exists() ) {
    throw e; // real failure, propagate
  } // else: file is gone; treat as deleted
}
Defensive patterns

Strategy: try-catch

Validate before calling

// pre-flight before delete
if ( !fileObject.exists() ) { return true; } // nothing to delete
if ( !fileObject.isWriteable() ) { throw new SecurityException( "No delete permission" ); }

Try / catch

try {
  fileObject.delete();
} catch ( FileSystemException e ) {
  fileObject.refresh();
  if ( fileObject.exists() ) {
    throw e; // genuinely still present: real failure
  }
  // deleted on server, only cache update failed: treat as success
}

Prevention

When it happens

Trigger: Deleting a file whose repository session is stale; permission denied on delete; handleDelete() failing because the file object is no longer resolvable after doDelete(); concurrent modification by another client.

Common situations: Stale cache after another client deleted the file (delete already happened, handleDelete now fails); insufficient JCR permissions; network hiccup mid-delete sequence.

Understand the failure class

Background: "File not found" and ENOENT errors: why libraries can't find a file that should exist — this error's family across 50 libraries.

Related errors

AI-assisted analysis of pentaho/pentaho-kettle@f3058517a1 (2026-09-13). Data as JSON: /api/errors/c10cf7f1b362c93d. Report an issue: GitHub.

Appendix: source

Thrown at plugins/repo-vfs/repo-vfs-ws/src/main/java/org/pentaho/di/plugins/repovfs/ws/vfs/JCRSolutionFileObject.java:396

  }

  @Override
  public int delete( final FileSelector selector ) throws FileSystemException {
    if ( selector == null || selector == Selectors.SELECT_SELF || selector == Selectors.SELECT_ALL ) {
      delete();
      return 1;
    } else {
      return super.delete( selector );
    }
  }

  @Override
  public boolean delete() throws FileSystemException {
    doDelete();
    try {
      handleDelete();
    } catch ( Exception e ) {
      throw new FileSystemException("vfs.provider/delete.error", e, getName() );
    }
    return true;
  }

  @Override
  protected void doDelete() throws FileSystemException {
    log.debug( "deleting {}", getName() );
    try {
      repoClient.delete( getFileDto() );
    } catch ( RepositoryClientException e ) {
      throw new FileSystemException( e );
    }
  }

  @Override
  protected void onChildrenChanged( FileName child, FileType newType ) throws Exception {
    super.onChildrenChanged( child, newType );
    refresh();

View on GitHub (pinned to f3058517a1)