Can copying files in using EG, but not out?

[AndrewHowell]

Enterprise Guide v 6.1 (64-bit), SAS 9.4 Linux servers

• Files within a SASApp context's "Files" folder structure
• Logged in as the SasAdmin (so presumably have all roles, etc enabled)
• I can use EG to copy/paste or drag'n'drop files in to the server's file-system from the local O/S.
• But I cannot then copy the same files out from EG back to the local file-system.

Is this common, or something in our site's specific configuration?

(There's Chris' plug-in, but I'm curious why the Files allow copying in but not out?)

Thanks,

Andrew.

[jakarman]

Andrew, Look at the dlls's being part of Eguide and you will notice xceed http://xceed.com/pages/TopMenu/Products/ProductSearch.aspx?Lang=EN-CA&Category=b16f8849-bbb7-4451-bd...

It are libraries that have been used by SAS to build functionality around it as a Windows .NET application.  An upload make perfectly sense as a download.

Within Windows you can drag/drop objects to a Window UI Automation Support for Drag-and-Drop (Windows) it is perfect UI interface. Selecting it at Windows drop it to an location.

You can use it with any type of file and any type (note the association) of application Excel Word 7zip SAS-base Eguide. With all of them it is quite common you can drag objects into. There is no object going as it is no windows object anymore. The win explorer offer files as objects and I do not know where Excel / Word 7zip SAS-base (source) could have objects to drag to another location.

Dragging to a location is fine and starting a sFTP as subroutine by Eguide is tempting easy. As it drops into the files area it start a sFTP covered by SAS (Nicely done SAS programmers). 

It is that easy operating that many people do not believe there is a sFTP behind the curtains running.
Look at the Eguide options there is a switch binary for transfers. Let it be configured in the options section as binary. All advanced settings of a sFTP like winscp are missing.

Going the other way there is a problem the file-list of the server are not Windows objects. They are presented in a similar icons way. So how to get that information to the filestransfer routines?      

One or more special cases: We know Eguide is knowing the PDF format (it is one of the results-type). Place a PDF file (binary) on your server an click on it. It will show in Eguide (having done a download).
   

[ChrisHemedinger]

Andrew,

The feature you've discovered was added WAY back as a convenience.  In a Windows app you can define what happens with content on the clipboard and when an item is dragged into your app.

But the reverse was never added, as you found.  That would require an extension to the Windows OS (since that's the app that would need to react to the paste or drop action.) You can, if you have Local SAS, use Copy/Paste to copy from a remote SAS session to a Local SAS session (under the Files tree).

Behind the scenes, it's not sFTP at work (sorry Jaap).  It's all SAS IOM FileServices -- the Integration Technologies APIs -- utilizing your already-established connection to SAS.

And SAS Enterprise Guide doesn't "know" the internals of all file types (like PDF), but it does know how to "sniff" out the file signature to know which type of viewer to launch.

Chris

[jakarman]

Yep chris I know it is not passing the data by Ssh/Sftp 22 and it not using that part. It is also not SAS/connect as SAS/base is not there. 
The best technical protocol descriptions for SAS is that IOM approach as it is embedded there.  But the IOM protocol is badly known and not very well accepted.

The functionality is a FTP FileTransferProgram, file drag-drop. I prefer to use common used words instead of sas propierty ones for better understanding, tyring to avoid confusions File transfer - Wikipedia, the free encyclopedia. In this approach MFT is concept Managed file transfer - Wikipedia, the free encyclopedia using RLS proc up/down load with SAS/connect can be seen when made in an operational batch approach as an implementation of MFT.

you must have experiences that some tools and approaches have got silo-d. That is often a cause for bad acceptance of SAS at enterprise level.
- data exchange, SAS not allowed we have tool X

- having data/tables being accessed, SAS not allowed we have tool Y

- using metadata for data, SAS not allowed we have tool Z for that.
- BI / report tooling, do not use SAS we have tool U
- ETL do not use SAS we have tool V
- ..... (compliancy security as continuing story)
That pushes SAS in a direction and position of only for shadow-it (isolated department level), and nice approaches.