Copy/Move Files not using URI but getting drive letter from somewhere

I am using the output the List Files node to do a bunch of stuff. Once done, I want to move the files from the “Input Directory” to a “Complete Directory”. Both are defined as global Workflow Variables. My output tables for String to URI and Extract URI Info contain the correct file names before executing the Copy/Move node. File names start with the fully qualified "//us.teo.earth/shares… " but the Copy/Move node substitutes that with a “D:” drive letter and can’t find the files.

I tried to cram the relevant stuff into a single streenshot.

Please let me know how to remedy this. I am usin Knime Analytics Platform 4.2 on a standalone machine.

Hey @mschutterop,

Welcome to the KNIME community. How did you configure the Copy/Move Files node, did you use the generated URI or an other output field of the Extract URI Info node? Or was the latter node only added for testing purposes? Just wondering because the Copy/Move Files uses the URI for the access of files.

Edit: I deleted your screenshot to hide the shown network path from the public.

Best,
Michael

1 Like

I did a LIST FILES --> STRING TO URL --> EXTRACT URI INFO --> COPY/MOVE FILES.

It seemed necessery to do this sequence as I wasn’t able to do the COPY/MOVE FILES based on URLs only.

image

I forgot to add. D: is where Knime is installed. The workflow seems to assume that is the starting point and substitutes the drive letter in rather than using the starting point \us.teo.earth in the variable.

From my perspective, your URI string is not correct:

image

If you would not provide a scheme like “file:” it would assume it is a relative path:

A URI reference is either a URI, or a relative reference when it does not begin with a scheme component followed by a colon ( : ).
(Uniform Resource Identifier - Wikipedia)

So this is where the d: emerges from. You would have to give a correct URI. Maybe you can take some inspirations from this workflow

And regarding copying files maybe this example might be helpful as well:

2 Likes

I don’t think that gets me where I need to go.

Note that when I eliminate the Flow Variable for “ouputdirectory” and hardcode the directory path to “Q:\directory” in the “use source name and output directory” option in the Copy/Move Files node then it works fine.

My real question is this. How can I a.) use a Flow Variable for my ouput directory and b.) not use a drive letter to reference the file location ?

Drive letters can change from machine to machine, so I want to reference the file location using “\\name\shares\directory” rather than “Q:\directory”.

Thank you for your assitance
Mike

I think you would have to add the scheme “file:” to your URI and figure out how to put the slashes (or back slashes)

1 Like

I wasn’t able to figure this out with machine reference and used the mapped drive letter to make it work. In this instance this will be OK as I am using a drive letter used consistently by all corporate wide, but in other instances I can’t do that. It seems to me the node should be able to handle this and not substitute in a drive letter that wasn’t configured and is not applicable. Seems to me this is a node deficiency unless I am not getting somethng.

Thanks for the help and ideas.
Mike

As I have quoted two times. The URI standard is if you do not provide an indication of a type of link like “file” it will give you a relative reference which means if you are (or your workflow is) on drive “d:” it will look there. That is the standard and I do not think KNIME would change that. You would have to provide a conforming string in order to get a different result in my opinion.

Maybe I am misunderstanding how to use the URI node then. My desire is to pass as a flow variable with the input directory to the List Files node using the //machinename/directory format (no drive letter referece) and gives me file names the same way. Is there a way to accomplish that without a lot of string manipulations?

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.