Enterprise Guide "Copy Files" task truncates macro variable - resolves correctly in log but shows on

[daviderondinel]

Hello SAS Community,

I'm experiencing a bizarre issue with Enterprise Guide 8.3.6.200 "Copy Files" task. The macro variable resolves perfectly in the SAS log, but the task's "Resolved Macro Values" window shows only the filename instead of the full UNC path.

**Environment:**
- SAS Enterprise Guide 8.3.6.200
- SAS Server: Linux
- Client: Windows 10

%global DATA_ANNO_MESE DT_VERSION_DIR DT_FILE DEST_PATH
        DIN_DIR_SRC ANNO4 ANNO2 MESE TRIM_NUM
        DIN_FILE_ESTERI DIN_SRC_FILE FILE_DIN;

/* Parameters */
%let DATA_ANNO_MESE=202512;
%let DT_VERSION_DIR=20251017;
%let DT_FILE=20102025;
%let DEST_PATH=/sas/prod/Projects/myproject/14298;

/* Derived values */
%let ANNO4=%substr(&DATA_ANNO_MESE,1,4);
%let ANNO2=%substr(&ANNO4,3,2);
%let MESE=%substr(&DATA_ANNO_MESE,5,2);
%let TRIM_NUM=%eval((&MESE-1)/3);

/* UNC source folder */
%let DIN_DIR_src=\\fileserver\share\Reports\&DATA_ANNO_MESE.\Received\&DT_VERSION_DIR.;

/* Filename with degree symbol */
%let DIN_FILE_ESTERI=Report &TRIM_NUM.° quarter &ANNO2. data_&DT_FILE..xlsx;

/* Complete paths */
%let DIN_SRC_FILE=&DIN_DIR_SRC.\&DIN_FILE_ESTERI;
%let FILE_DIN=&DEST_PATH./&DIN_FILE_ESTERI;

%put NOTE: DIN_SRC_FILE=&DIN_SRC_FILE;
%put NOTE: FILE_DIN=&FILE_DIN;

NOTE: DIN_SRC_FILE=\\fileserver\share\Reports\202512\Received\20251017\Report 3° quarter 25 data_20102025.xlsx
NOTE: FILE_DIN=/sas/prod/Projects/myproject/14298/Report 3° quarter 25 data_20102025.xlsx

Copy Files Task Settings:

• Source: &DIN_SRC_FILE
• Target: /sas/prod/Projects/myproject/14298
• ✓ "Resolve SAS macro variable references in file paths" is checked

"Test Macro Values" Window Shows:

• Source: "20102025.xlsx" ← TRUNCATED!
• Target: /sas/prod/Projects/myproject/14298 ERROR: file 20102025.xlsx does not exist on CLIENT_PC                                                 

  What I've Tried:

  1. Removing degree symbol (°) from filename - still truncated
  2. Using %nrstr(°) - no change
  3. Quoting with %sysfunc(quote()) - still truncated
  4. Hard-coding the full path directly in task field (not using macro) - works, but defeats automation
  5. Verified macro is %GLOBAL and program runs before Copy Files task in process flow
  6. Used %put _GLOBAL_; to confirm all macros are visible and resolve correctly

  Important Note:
  I have OTHER programs in the same EG project using the EXACT same pattern with UNC paths and macro variables, and they work perfectly. The only difference appears to be in the filename content or structure.

  Questions:

  1. Why does the "Copy Files" task truncate &DIN_SRC_FILE during resolution, even though the SAS log shows the complete correct path?
  2. Is there a character limit or special character issue in the task's macro resolution that differs from normal SAS macro processing?
  3. Is this a known bug in EG 8.3.6.200?

  This is blocking an automated monthly process. Any workarounds or solutions would be greatly appreciated!

  Thank you!

[Tom]

The macro variable probably has a different value when you run the task than it had when you ran the test.  This is mentioned in the documentation.

https://documentation.sas.com/doc/en/egamotasks/8.3/n08ksbwyrsc9mxn0zpgenjnp5ejb.htm 

CAUTION

The macro variables must exist within your SAS session (either as SAS built-in macro variables or defined in an earlier process). If the macro variables are not specified correctly or if you use incorrect syntax for a macro function, the Copy Files task can generate errors or unexpected results.

To verify that the macro expressions resolve correctly, click Test macro values. A short SAS program runs to resolve the macro expressions, and the results are displayed in a new window. Remember that when you test these values, the macro expressions resolve to values that reflect the current state of the macro variables or the results of any macro functions that you use. These values can be different when you actually run the task later.

Try adding a Code step in your process to display the value of the macro variable just before it tries to run the Copy Files step.

[ChrisHemedinger]

Quick thoughts:

- The "special character" might be causing a weird interaction. 

- Sometimes a long file path/name combo can result in problems. 

You might want to track this with SAS technical support. If you enable Application Logging (in Tools->Options), that will generate an application log that will contain more info for diagnosing. This task does generate a lot of diagnostic info behind the scenes.

[Kurt_Bremser]

By all means avoid special characters in file or path names. You'll never know when they come back to bite you in your behind.

Personally, I never had anything but letters, digits and underlines there (which also means NO blanks).

[daviderondinel]

Hello everyone,

I'm sharing a workaround for a frustrating issue with the SAS Enterprise Guide "Copy Files" task and also asking the community if a better, automated solution exists.

The Problem

I was using the "Copy Files" task to move a file from a Windows network share (UNC path) to a SAS Linux server. The task consistently failed with a "file not found" error, even though the SAS log showed that the macro variable containing the full source path was 100% correct.

The Root Cause

After days of troubleshooting, I discovered that the problem was not the path, not special characters, but a bug in the task itself related to the length of the source filename. The "Copy Files" task seems to have a hidden character limit and fails to read a source file from a UNC path if the filename is too long.

My Manual Workaround (The only thing that worked)

The only way I could get the process to work was to:

Go into the original Windows folder on the network share.
Manually rename the source file to have a shorter name.
Run the "Copy Files" task again, pointing to the file with its new, short name.
It worked instantly.

My Question for the Community

Obviously, this manual workaround is not a viable solution for an automated, recurring process.

So, my question to the forum is: Has anyone found a way to automate a solution for this bug from within SAS?

I'm thinking of things like:

Is there a hidden option or a different SAS command that can force the "Copy Files" task to correctly read long filenames from a UNC path?
Is there a reliable way to use SAS code (e.g., X command, FILENAME PIPE) to remotely rename the source file on the Windows share before the "Copy Files" task runs? I'm skeptical this is possible due to security permissions, but I'm open to ideas.
Essentially, how can we handle this file transfer in an automated way when the source filename is too long for the "Copy Files" task to handle?

Thanks in advance for any suggestions.

[Tom]

So others know when they are at risk can you clarify what is the length that causes trouble?  For example is it names longer than 200 bytes?  Or some other limit? Is it the length of the fully qualified filename?  Or just the name of file itself?  That is could you not rename the file but just move it to a higher directory so that the total name is shorter.

[ChrisHemedinger · Accepted solution]

I'm glad that you found a workaround.

Historically, Windows file paths (and the APIs/functions that reference them) have a limit of 260 characters. I can't remember what APIs/functions the Copy Files task uses, but it's possible that these limits are causing the behavior.

Windows 10 and later do have ways to increase this MAX_PATH setting but I don't know if it would help here. Another workaround might be to Map a drive to the UNC network share/folder at a root location that makes sense for you, then reference the files by that mapped drive rather than the full UNC (\\node\folder) path.

[daviderondinel]

Thank you for the excellent suggestions. Those are classic causes for path-related issues, and I appreciate you bringing them up.

I want to provide an update based on my testing, as it seems we're dealing with a more specific (and strange) bug here.

Regarding the MAX_PATH (260-character) limit:

This was one of my initial thoughts as well. However, the evidence from my case suggests this is not the root cause. The total length of my fully qualified UNC path was well under the 260-character limit.

The crucial discovery was that I could make the process work simply by shortening the filename itself, while leaving it in the exact same, long directory path. Since the only variable that changed was the filename's length (not the total path's length), this points to a bug specifically related to the filename component.

This was also a great suggestion and one of the first workarounds I attempted.

Unfortunately, in my specific corporate environment, that approach also failed. The process that SAS Enterprise Guide uses to perform the copy did not seem to recognize the mapped drive letter, resulting in a "file not found" error for the mapped path (e.g., Z:\...). The process would only recognize the full UNC path (\\server\share\...).

Based on this, I am sticking with my original conclusion: the "Copy Files" task has a specific, undocumented bug where it fails to read a source file from a UNC path if the filename component alone exceeds a certain, surprisingly low, character limit. The only effective workaround for me was to manually shorten the source filename before running the task.

Thanks again for your input; it's helpful to rule out these possibilities.