USQL Job failing due to exceeding the path length limit - azure-data-lake

I am running my jobs locally using the Local SDK. However, I get the following error message:
Error : 'System.IO.PathTooLongException: The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.
One of my colleagues was able to track down the error to the .ss file in the catalog folder inside DataRoot by running the project in a new directory in C:\. The path for the .ss file is
C:\HelloWorld\Main\Source\Data\Insights\NewProject\NewProject\USQLJobsForTesting.Tests\bin\Debug\DataRoot\_catalog_\database\d92bfaa5-dc7f-4131-abdc-22c50eb0d8c0\schema\f6cf4417-e2d8-4769-b633-4fb5dddcb066\table\aa136daf-9e86-4650-9cc3-119d607fb3b0\31a18033-099e-4c2a-aae3-75cf099b0fb1.ss
which exceeds the allowed limit of 260 characters. I cannot reduce the length of my project path because my organization follows a certain working directory format.
Is there any possible solution for this problem?

Try using subst in CMD to workaround this problem by mapping a drive letter to the data root you want to use.
subst X: C:\PathToYourDataRoot
And then in ADL Tools for Visual Studio set the DataRoot to X:

Related

AzureSynapse Lookup UserErrorFileNotFound with Wildcard path

I am facing an odd issue where my lookup is returning a filenotfound error when I use a wildcard path. If I specify and exact file path, the lookup runs without error. However, if I replace the filename with a *, I get a filenotfound error.
The file is Data_643.json, located in my Azure Data Lake Storage Gen2, under the labournavigatorfile system. The exact file path is:
labournavigatorfile/raw_data/Scraped/HeadHunter/Saudi_Arabia/Data_643.json.
If I put this exact path into the Integration dataset configuration, the pipeline runs without issue. However, as soon as I replace the 'Data_643.json' with a '*', the pipeline crashes with a filenotfound error.
What am I doing wrong? Many Thanks for any support. This must be something very simple that I am missing.
Exact path works:
Wildcrad path throws error:
I have 3 files in my container as file1.json, file2.json, file3.json as shown below:
The following is how I configured my dataset to read using wildcard with configuration same as in the image provided in the question.
When I used this in lookup I got the same error:
To overcome this, go to your lookup activity. When you want to use wildcards to read a file/files, check the wildcard file path option. Then specify the folder structure and use wildcard where required. The following is an image for reference.
The following is the debug output when I run the pipeline (Each of my files had 10 rows):

In VBA Getattr function with long file path file name greater than 259

I try to list specific file name from directory. but I got error code 53 with Getattr function.
In my case,
error occurred when file path & file name length is greater than 259 in same directory.
Question is
how much length does Getattr function support?
how can i solve this error?
I have not found this on official website. But i have tested it and it is working fine till length is 260.
You can use relative path of directory.
Or
You can Prefix a path with \\?\, like \\?\C:\TEST\test.txt. This will convert DOS path names to native OS path names. Refer this.
Dim file_path = "\\?\C:\TEST\test.txt"

Network path not working for xlswritefig in Matlab

I am trying to open a workbook that is located on a network path using the function xlswritefig. I.e. the path does not start with the traditional letter such as C:\. Instead it looks as follows:
\\networkmain\folder\to
When I try to open the excel file on this folder in Matlab, I noticed that Excel adds the current path in front of the the path. I.e. if I am currently in folder
C:\Matlab\ then Excel tries to open:
C:\Matlab\networkmain\folder\to
How can I prevent this from happening and redirect to the network path?
The problem was with the function xlswritefig. To solve for this issue, step into the function and change the following line of code (line 86):
%**op = invoke(Excel.Workbooks, 'open', [pwd filesep filename]);
op = invoke(Excel.Workbooks, 'open', filename);
Thus remove the [pwd filesep] part.
I don't think UNC paths are supported in Matlab (at least the didn't use to). The simple way forward is to map your folder to a letter drive. It is possible to do this in Windows Explorer, but I tend to use net use in the command prompt. net help use will show you the syntax
UNC (network) paths are not supported by MATLAB. However, here is a workaround which sets (and unsets) a network drive letter using the system command.
% Execute system command to assign drive letter
system('net use Z: \\networkmain\folder\to');
% Perform actions under this drive
cd(Z:\);
% ...
% Unmount the drive
system('net use Z: /delete');
You could use some simple looping to find the next available drive letter, as the system call shoudn't override an existing drive letter.

BigQuery loading batch folders error

I'm trying to load group of folders files in one time with when
i set
sourceURI = 'gs://ybbi/bi_landing_zone/files_to_load/app/reports/app_network_analytics_report/201409011*'
all the folders that i'm want to load start with 20140911
but i get the error:
ERROR: Invalid path: gs://ybbi/bi_landing_zone/files_to_load/apn/reports/appnexus_network_analytics_report/20140901191111_3bab8ec0_092a_43de_a157_db35d1555ea0/
20140901191111_3bab8ec0_092a_43de_a157_db35d1555ea0 is one of these folders(don't know why it's print the all folder name of this specific folder)
in some other folder tree cases it's works, but in this specific folder tree it's return the same error .
i know that cloud storage don't have real folders and it's part of the name of the object, but you understand what i mean.
is it bug?
Without more information, what it looks like is that you have a object file called gs://ybbi/bi_landing_zone/files_to_load/apn/reports/appnexus_network_analytics_report/20140901191111_3bab8ec0_092a_43de_a157_db35d1555ea0/ that is not a csv/json file. Some tools may create these dummy files in order to simulate directories. BigQuery requires all objects that match the input glob path to be importable files.
One solution would be to change the glob path to include a narrower set of files. You can pass multiple paths if that makes things easier. For example, you could pass
gs://ybbi/bi_landing_zone/files_to_load/apn/reports/appnexus_network_analytics_report/20140901191111_3bab8ec0_092a_43de_a157_db35d1555ea0/*
and
gs://ybbi/bi_landing_zone/files_to_load/apn/reports/appnexus_network_analytics_report/20140901191111_some_other_path/*

How to copy file to a new location having path length more than 260 characters in vista?

in my previous question as follows:
"How to create a copy of a file having length more than 260 characters."
I have asked almost same qustion and I got a solution to rename the directory name and then copy to a new location. But as per the client's requirement we can't rename the directory in any case.
So now my problem is when we try to copy a file having path length (including file name) more than 260 characters, (say 267 characters), it allows us to copy manually but throws an exception programmetically in vista OS.
Please let me know if any one has a solution.
Prepend \\?\ to your path to enable path lengths up to 32767 characters long. E.g:
copy \\?\C:\big\dir\hierarchy\myfile.txt \\?\C:\tohere.txt
This page has more details.
I've only tested this with DIR in WinXP, but that seems to work.
If the problem is just with the length of the file (not the preceding path), then you can use the short name version of the file (probabaly Outloo~1.xls ).
However, the only real viable solution is to use network redirection or SUBST command to shorten the path. I can imagine that you'd have to be keeping track of the path length in your program, and spawn a SUBST drive letter when the length is exceeded... dropping the drive letter when it's no longer needed. Ugly programming, but no hope.
Or
I know some unicode version of windows api functions (copyfileex..? http://msdn.microsoft.com/en-us/library/aa363852(VS.85).aspx) can handle to 32,767 chars.
Try to name it with a \\?\ prefix, for example, \\?\D:\. I'm not sure if CLR uses this kind of naming style, but you can give it a try.
You could check if compression tools like 7zip are limited by the length of the path in Vista.
If not, that means a "copy by program" would by:
compressed the tree of directories/file you want to copy
copy the .zip/.rar to the destination
uncompress