Windows Java Agent: Wildcard File Transfer Fails on Mounted or Linked Drives.
search cancel

Windows Java Agent: Wildcard File Transfer Fails on Mounted or Linked Drives.

book

Article ID: 429599

calendar_today

Updated On:

Products

CA Automic Workload Automation - Automation Engine Automic SaaS

Issue/Introduction

When performing a File Transfer using the Windows Java Agent, the transfer fails to identify or transfer files if all of the following conditions are met:

  • The source path involves a Mounted Folder, Symbolic Link, or Mapped Drive (e.g., D:\LinkedPath\).

  • The File Transfer object (JOBF) uses a wildcard in the source path (e.g., D:\LinkedPath\filename_*).

  • The files physically exist in the target directory.

Symptoms observed:

  • The File Transfer ends normally but reports 0 files selected or "Ended Empty."

  • The report indicates: Files selected: '0'.

  • Using the full UNC path (e.g., \\Server\Share\Path\filename_*) instead of the mounted drive letter works successfully.

  • Using a specific filename without wildcards (e.g., D:\LinkedPath\filename_123.txt) works (though potentially slower).

  • Using PREP_PROCESS_FILENAME on the same mounted path successfully lists the files.

Error Example (Report):

2025-10-14 08:50:31 - U00063087 FT '307139305': Selection started with filter 'D:\Link\Folder\file_*'
2025-10-14 08:50:31 - U00063089 FT '307139305': Files selected: '0'.
2025-10-14 08:50:31 - U00011408 FT '307139305': File Transfer has ended normally.

Environment

 

  • Product: Automic Automation Engine

  • Component: Windows Java Agent (System Agent Window)

  • Affected Versions: 24.4.1, 24.4.2

  • OS: Windows Server (e.g., 2019)

 

Cause

This issue is caused by a defect (DE177144) regarding how the Windows Agent handles user impersonation and mapped drives during file transfers.

When the Agent is started (e.g., via ServiceManager) as a specific user (e.g., BUILTIN\Administrators), it may create a symbolic link to a network path. However, File Transfers often run under a specific Login Object user (e.g., DOMAIN\User01).

Both C-based and Java-based Agents use the Windows API function ImpersonateLoggedOnUser for File Transfers. If the user defined in the Login Object differs from the user who started the Agent, the mapped drives or symbolic links created by the Agent's starting user may not be visible or accessible to the impersonated user context during the wildcard expansion phase. While the path itself might be located, the ability to list files within that folder (required for wildcard processing) fails, resulting in 0 files selected.

Resolution

This issue has been confirmed as a bug and is fixed in the following versions:

Component: Agent.Unix, Agent.Windows

  • Automic Automation Engine 24.4.4 - Available

Public Title:
Wildcard file transfers in Windows linked folders

Public Description:
A problem has been fixed where Windows file transfers using wildcard patterns failed to locate files within linked folders.

Additional Information

Workaround

If an upgrade is not immediately possible, use one of the following workarounds:

  1. Use UNC Paths: Modify the File Transfer object to use the absolute UNC network path (Network Share) instead of the local mapped drive letter or mounted path.

    • Failing Path: D:\folder1\folder2\filename_*

    • Working Path: \\<IP_Address>\folder1\folder2\filename_*

  2. Explicit Filenames: If the filenames are known in advance, specify the exact filename instead of using wildcards.

Powered by Wolken Software