<?xml version="1.0"?>
<ArrayOfFBEvent xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2025-03-12T00:50:20Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Justin Richardson</User>
    <Comment>Using datapro version 4.0.1203.52145 and testing long  filename/filepaths 
 
Issue Summary:
 
 
Datapro Hangs On Export Data tab after modal popup " Export Failed , the export path is too long"  then clicking ok .
 
  Datapro remains on export data tab .. progress bar is shows 0% and pressing the done button  there is no response .. the only buttons that are responsive are the hamburger menu or the "x" to force close datapro..
 
 
Steps To Reproduce:
 
 
Edit the Datapro.exe.config file  and set the  DownloadFolder to a file path that has many characters  like "..\..\Data export to long file Path name And Dp should give some modal when it happens  Data"
 
Save Datapro.exe.config file  and Open datapro and navigate to the Test Setup Tab and import the attached test setup which has a long filename  
 
Open the Imported test and edit it to  Swap your sensors and Hw .
 
Run the Test , arm / Trigger and download the data from the das.
 
After Downloading the data  ..click to export all   and choose  Csv format..
 
A modal should appear since the path is too long ..
 
 
Expected :
 
 
User Would be able to click ok on the modal "Export Failed , the export path is too long" and then exit  to the main datapro window.
 
 
Actual:
 
 
After clicking ok  the modal appears a few more times ..then  User is not able  to exit the run test tab , the progress bar shows 0% and clicking done  is unresponsive. The hamburger menu is still functional but the only way to  continue is to force close datapro by clicing the "x" in upper right hand corner.
 
 
Environment:
 
 
Datapro version 4.0.1203.52145 
 
Reproduce rate 100% with datapro version 4.0.1203.52145
 
Hw Used S6A</Comment>
    <StatusString>Reactivated</StatusString>
    <TimeStamp>2025-03-11T22:18:29Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>Reactivated</Status>
  </FBEvent>
  <FBEvent>
    <User>Justin Richardson</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2024-09-18T20:34:37Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Justin Richardson</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2024-09-18T19:35:34Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Justin Richardson</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2024-09-18T18:46:45Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2024-08-24T00:14:30Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Justin Richardson</User>
    <Comment />
    <StatusString>Assigned</StatusString>
    <TimeStamp>2024-06-04T20:01:58Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>ReleaseNoted</StatusString>
    <TimeStamp>2024-06-04T18:18:49Z</TimeStamp>
    <ReleaseNote>Adds some additional protection against file path length issues when export or recording data</ReleaseNote>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2024-05-23T00:07:13Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>4.0/4.2/4.3@50819
 
You may discover other export issues during testing of this issue - check to see if those issues already existed first before re-activating this issue, if they did already exist then open up a new issue for the defect found (or just make a note on an existing issue if it's in manuscript already).  If the patch itself breaks something then re-activate the patch.
 
I noticed a couple things during testing and code - RDF export the code is different in 4.2 vs 4.0, I suspect there was an issue fixed in 4.2 that was never backported to 4.0 - that's probably ok, just a note.
 
Behavior when putting in an existing test id and that test id folder already exists in your data directory has some unexpected behavior - I used a long test id by itself for a lot of testing (so I did 012345789012345789012345789, found that was too long to record so I backed down to 01234567890123456789).</Comment>
    <StatusString>Resolved</StatusString>
    <TimeStamp>2024-05-22T16:53:02Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>Resolved</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2024-05-21T18:17:48Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2024-05-21T16:05:52Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2024-05-21T16:05:45Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2024-05-20T15:53:23Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>Jerry, Farshid,
 
 
 
This is an issue reported by Chad on a specific customer issue, I found an already existing issue for a very similar problem – when the path length is too long it can fail or even say it succeeded, but not actually export any files.
 
 
 
30621
 
Report Path/File length errors in Export to user
 
 
 
In this particular case the customer was exporting CSV and ISO, so I only looked at those two exports.  The same problem could exist for all exports.  Chad requested the change in 4.0 (LTS), and I wrote the patch for 4.0, but the same fix would need to be added to 4.2 and 4.3.  I may need to produce a whole new patch for 4.2/4.3 as 4.3 is a bit different than 4.0 now.
 
 
 
In my testing for this case the first issue I found is that it could fail to download if you had a test id that was too long.  I tracked this down to the code in SliceRaw.File.PersistentChannel.cs.  The code in question was creating a named mutex using the entire path to the file to be written.  In this case it was replacing some characters in the path with other characters, which then apparently made string too long for the mutex to handle.  This isn’t actually needed, we don’t need the path to the files since the files themselves are named, When downloading each file being written to the file name itself is unique without having a need for the path.
 
 
 
With this change I ran into a few additional errors – there was file path validation in basic info but it wasn’t considering multiple events or multiple ROI, which adds additional length to the filepath.  I added consideration for this as well as some additional buffer too.  The user can rename the periods and they could make this worse – I didn’t test the behavior if the user does this.
 
 
 
I noticed a lot of duplicated code in BasicInfo.Validate, so I abstracted the common parts out to reduce the filepath.
 
 
 
Now that you can get all the way to downloading data you can finally look at where the path fails from too long path.  There are a lot of variables that need to be tested here
 
 
 
 
Run test with export specified
 
Export tab with already downloaded data
 
The effect of multiple events and multiple roi
 
The affect of “Use flat folders” on the issue
 
The affect of the user changing the name of roi periods
 
CSV export
 
ISO export
 
CSV and ISO export
 
All the rest of the exports
 
MS case 18791
 
also needs to be tested with multiple ISO export options selected and multiple CSV options selected (filtered/unfiltered, ADC/EU, etc)
 
 
 
 
The issue calls out ISO and CSV, so I made sure to use those.  If there are other exports that also need to be updated we should identify them, but open up new issues to address those exports with a similar fix.  Unfortunately the exports have different routes and code so fixing each export is a bit custom currently.
 
 
 
In testing I found that the CSV export alone I found two issues.
 
 
 
In SetStatus this line here:
 
if ((_totalExports &gt; 0) &amp;&amp; (_numExportsFinished == _totalExports) &amp;&amp; (status != StatusTypes.Finished))
 
was causing the error status not to be processed … total exports was 1, the num exports finished was == to the total exports, however the error status was failed, not “finished” so it would drop into the return; and not set the status.  I changed this constraint a little bit to check that the overall status was not set to overallfinished so that the error status would be processed.  This means that MS case 18791 also needs to be retested now as I’m adjusting the solution to that case.
 
 
 
In the CSV export I now check the path length, and report the error to the user.
 
 
 
The ISO export already reported the error to the user, but then would set status to success at the conclusion rather than failure.  At the conclusion of iso export it calls OnEndExport.  I cleaned up old commented out code in this method, then had it check to see if it’s failed or not before blindly setting overall status to success.
 
 
 
Because there’s different routes through the codes there are slightly different prompts the user sees on file path errors.
 
 
Vs
 
 
 
 
I’m not sure which of these messages are better.  I think maybe the first one is as it’s simpler, so it might be better to have both user the simpler message.
 
 
 
And unfortunately there’s a ton to test with the patch.</Comment>
    <StatusString>Assigned</StatusString>
    <TimeStamp>2024-05-14T18:46:25Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2024-05-14T17:58:18Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>I'm not considering emergency or repeated download roi for the path length, this could be relevant.
 
18791 should also be retested</Comment>
    <StatusString>Edited</StatusString>
    <TimeStamp>2024-05-14T17:56:21Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>a single CSV export now looks like this;
 
 
a single ISO export looks like this:
 
 
ISO export and CSV export have different ways of concluding the end of the test, ISO export uses OnEndExport
 
 
 
 
being called directly from ExportISOData
 
currently only TSV export and ISO export are calling OnEndExport
 
I chose to have onendexport not set overall status to finished if the status was currently error, this will cause a pass to hide a failure.</Comment>
    <StatusString>Edited</StatusString>
    <TimeStamp>2024-05-14T17:50:15Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>it looks like this code from case 18791 is preventing the error status from getting set.
 
It appears to be assuming that OverallStatus will get set to Finished soon, it will not in this case ...</Comment>
    <StatusString>Edited</StatusString>
    <TimeStamp>2024-05-10T23:17:25Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2024-05-10T21:59:17Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2024-05-10T21:58:49Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>export to CSV throws an error here:
 
                    var subPath = Path.GetDirectoryName(destPath);
 
export to ISO throws an error here:
 
                    using (var fileWriter = new StreamWriter(mmeDirectory + id + TestFileExtension, false, encoder))
 
and here:
 
                    using (var channelsFileWriter = new StreamWriter(filename, true, encoder))</Comment>
    <StatusString>Assigned</StatusString>
    <TimeStamp>2024-05-10T21:58:09Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>added this warning;</Comment>
    <StatusString>Edited</StatusString>
    <TimeStamp>2024-05-10T20:48:15Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>right now there's already a validation in Basic info for path length ... but it seems to not consider the DTS and CHN files at this part, just the report files;
 
 
 
            if (bValid)
             {
                 bValid = DiskUtility.ValidateFileAndPathNameLength(DiagnosticsReport.GetReportFilenamePath(false, ReportBase.GetTemplateReportPath(), TestId));
             }</Comment>
    <StatusString>Edited</StatusString>
    <TimeStamp>2024-05-10T17:31:11Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>here's how it determined the file name it was going to use;
 
 
 
                            var filename = new File().GetChannelFileNameFromTestNameAndChannelNumber(CurrentTest.TestIdNode, channel.AbsoluteNumber, channel.AbsoluteDisplayOrder);
                             var fullChannelFilename = Path.Combine(targetDirectory, filename);
 
...
 
                var targetDirectory = DownloadDirectory;
 
...
 
download directory is D:\Storage\Projects\DTS.Suite\BRANCH_MAINT_4_00\DataPRO\DataPRO\bin\x64\Debug\..\..\Data\MS30621_reallly_long_TEST_NAME\REALLY_LONG_ID_MS30621_reallly_long_TEST_NAME\Binary\ROI\_Event Number 01\_ROI Period 1
 
                                    DownloadDirectory = Path.Combine(DownloadFolder, testId, CurrentTest.TestIdNode, "Binary", ROI ? "ROI" : "ALL");</Comment>
    <StatusString>Edited</StatusString>
    <TimeStamp>2024-05-10T17:06:06Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2024-05-10T17:00:07Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>The first issue I ran into trying to duplicate this is that if the path is too long you can't get to the export step because you fail in the download step
 
here's how it looks like int he log, note the PathTooLong exception in creating persistent channel 0;
 
 
 
2024-05-10 09:25:58.011 !!  An exception of type: System.Exception occurred Module: DataPRO.exe, Name: AppendNewDataChunksToChannelsMessage: encountered problem appending new data to channels - Creating persistent channel 0 StackTrace:    at DataPROWin7.SubControls.Download.AppendNewDataChunksToChannels(CallbackData dataChunks, List`1 channels, DownloadInfo dlInfo, String inDir) in D:\Storage\Projects\DTS.Suite\BRANCH_MAINT_4_00\DataPRO\DataPRO\CollectDataSubControls\Download.xaml.cs:line 3816 StackTrace:    at DataPROWin7.SubControls.Download.&lt;&gt;c__DisplayClass137_0.&lt;DoDownload&gt;b__2(CallbackData data) in D:\Storage\Projects\DTS.Suite\BRANCH_MAINT_4_00\DataPRO\DataPRO\CollectDataSubControls\Download.xaml.cs:line 4167!!   An inner exception of type: System.Exception occurred  Module: DataPRO.exe, Name: CreatePersistentInformationObjectFromChannel Message: encountered problem creating persistent channel information object for DAS module SPS00397, channel 0  StackTrace:    at DataPROWin7.SubControls.Download.CreatePersistentInformationObjectFromChannel(Channel channel, String channelFilename, DownloadInfo dlInfo) in D:\Storage\Projects\DTS.Suite\BRANCH_MAINT_4_00\DataPRO\DataPRO\CollectDataSubControls\Download.xaml.cs:line 3547  StackTrace:    at DataPROWin7.SubControls.Download.AppendNewDataChunksToChannels(CallbackData dataChunks, List`1 channels, DownloadInfo dlInfo, String inDir) in D:\Storage\Projects\DTS.Suite\BRANCH_MAINT_4_00\DataPRO\DataPRO\CollectDataSubControls\Download.xaml.cs:line 3762!!    An inner exception of type: DTS.Common.Utilities.ExceptionalList`1+Exception[System.Int16] occurred   Module: DTS.Serialization.dll, Name: .ctor  Message: encountered problem constructing DTS.Serialization.SliceRaw.File+PersistentChannel   StackTrace:    at DTS.Serialization.SliceRaw.File.PersistentChannel..ctor(String filename, BinaryChannelHeader channelHeader, Boolean overwriteIfExists) in D:\Storage\Projects\DTS.Suite\BRANCH_MAINT_4_00\Common\DTS.Common.Serialization\SliceRaw\SliceRaw.File.PersistentChannel.cs:line 278   StackTrace:    at DataPROWin7.SubControls.Download.CreatePersistentInformationObjectFromChannel(Channel channel, String channelFilename, DownloadInfo dlInfo) in D:\Storage\Projects\DTS.Suite\BRANCH_MAINT_4_00\DataPRO\DataPRO\CollectDataSubControls\Download.xaml.cs:line 3542!!     An inner exception of type: System.IO.PathTooLongException occurred    Module: mscorlib.dll, Name: GetFullPathName   Message: 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.    StackTrace:    at System.IO.PathHelper.GetFullPathName()    StackTrace:    at System.IO.Path.LegacyNormalizePath(String path, Boolean fullCheck, Int32 maxPathLength, Boolean expandShortPaths)    at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)    at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options, String msgPath, Boolean bFromProxy)    at System.IO.FileStream..ctor(String path, FileMode mode)    at DTS.Serialization.SliceRaw.File.PersistentChannel..ctor(String filename, BinaryChannelHeader channelHeader, Boolean overwriteIfExists) in D:\Storage\Projects\DTS.Suite\BRANCH_MAINT_4_00\Common\DTS.Common.Serialization\SliceRaw\SliceRaw.File.PersistentChannel.cs:line 157
 
here's how it looks in the UI:
 
 
note that you get this popup a lot...
 
here's the path it tried to write:
 
D:\Storage\Projects\DTS.Suite\BRANCH_MAINT_4_00\DataPRO\DataPRO\bin\x64\Debug\..\..\Data\MS30621_reallly_long_TEST_NAME\REALLY_LONG_ID_MS30621_reallly_long_TEST_NAME\Binary\ROI\_Event Number 01\_ROI Period 1\REALLY_LONG_ID_MS30621_reallly_long_TEST_NAME_Event Number 01_ROI Period 1Ch001.018.chn
 
and here's the code where it tried to write it:
 
                            using (var fileWriter = new BinaryWriter(new FileStream(Filename, FileMode.OpenOrCreate)))
 
in persistentchannel constructor in SliceRaw.File.PersistentChannel</Comment>
    <StatusString>Edited</StatusString>
    <TimeStamp>2024-05-10T16:26:36Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2024-05-09T18:22:11Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Dan McFadden</User>
    <Comment>see also this ZD  #13532
 
specifically with CSV export in 4.0.  We should have a user friendly notification for path length in 4.0 LTS.</Comment>
    <StatusString>Edited</StatusString>
    <TimeStamp>2024-05-09T18:22:05Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Randy Chu</User>
    <Comment />
    <StatusString>Edited</StatusString>
    <TimeStamp>2024-02-27T18:42:43Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Chris Balogh</User>
    <Comment />
    <StatusString>Assigned</StatusString>
    <TimeStamp>2023-05-01T17:00:57Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>UNKNOWN</Status>
  </FBEvent>
  <FBEvent>
    <User>Chris Balogh</User>
    <Comment>https://dtsweb.zendesk.com/agent/tickets/11800
 
 
 
John Moors  (assign)
 
 
 
 
 
 
 
 
 
 
 Today 07:58
 
 
 
 
 
 
 
Hi Chris Balogh - Do we know if there's a roadmap item for warning the client about the path? Can't imagine it'd be super easy, particularly as it would possibly only come up if they choose a particular export option?
  
 10069: Crash in basic info of run test when you exceed 248 char for your paths, and 260char for filenames if your test ID is too long. - Manuscript (dts.local)
 
 
 
 
 
 
 
 
 
 
 
 
 
   
 
   
 
 
 
John Moors  (assign)
 
 
 
 
 
 
 
 
 
 
 
 
 
 Today 06:56
 
 
 
To Todd Skinner, Bert Mcmahon, Arnold Turner... Show all
 
 
 
 
 
Hi Todd,
  
 If it was the file path, since the path to download the binary file is shorter, would that work but not for the exported .CSV file because the path is longer?
   
 
Yes from what we saw it looks like when you exported that pushed you past the limit, partly as it now has a sub-folder path, and partly as the full name of the Test ID combined with the path pushed the character limit.
 
 And in both cases it looks like you were right on the margin, so even a very slight change (shortening) could suddenly work.
  
 I believe there's still an in-the-works flag in the UI to warn users of it, but I can double-check.
  
 John
 
 
 
 
 
 
 
 
 
 
 
 
 
   
 
 
 
Todd Skinner 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Friday 09:23
 
 
 
To DTS, Bert Mcmahon, Arnold Turner, Kathryn Wittek Show all
 
 
 
 
 
 
John,
 
 
 
Thanks for feedback. Bert and Arnold can check the file path used to see if it was longer than before. If it was the file path, since the path to download the binary file is shorter, would that work but not for the exported .CSV file because the path is longer?
 
 
 
The path on the second computer might have been a little shorter, Bert and Arnold can also confirm.
 
 
 
Todd
 
 
 
 
 
 
 
 
 
 
 
 
 
 
   
 
   
 
 
 
John Moors  (assign)
 
 
 
 
 
 
 
 
 
 
 
 
 
 Friday 09:09
 
 
 
To Todd Skinner, Bert Mcmahon, Arnold Turner... Show all
 
 
 
 
 
Hi Todd, Arnold and Bert,
  
 We took a deeper dive into the specific characters and possible extensions to file paths given how you export. 
  
 The short answer is: We've confirmed the initial diagnosis - the file path is indeed too long.
  
 You mentioned this worked without issue for months and the deeper dive seems to have confirmed that as well. Your full path was very close to the 260 char file path limit for some time, then likely just stepped over recently with new additions to the path. Essentially, Windows has limits on how long a file name and file path can be, and since this is a Windows limitation, DataPRO cannot break past that. We've been adding flags to newer/upcoming DataPRO versions to help warn users who are starting to generate longer and longer paths.
  
 When you copied this to a new laptop, some part of the path was likely cleaved away, and even missing just a few characters would put you back into what Windows can support.
  
 Our recommendation:
 Shortening your Test Setup name and Test ID to hopefully not be too long/repetitive can help.
 We noticed there's also a repeat of the date, 04262023 followed by 202304_26 10_19, so even removing the double date could get you back into what Windows allows.
 
  
 Does that make sense? Anything else we can help with on this matter?
  
 John
 
 
 
 
 
 
 
 
 
 
 
 
 
   
 
   
 
 
 
Chris Balogh  (assign)
 
 
 
 
 
 
 
 
 
 
 
 
 
 Friday 08:35
 
 
 
 
 
 
 
"it worked on the other laptop" doesn't neccasarily mean they built up all the DP directory structures to do it.
 
 
 
 
 
 
 
 
 
 
 
 
 
   
 
   
 
 
 
Chris Balogh  (assign)
 
 
 
 
 
 
 
 
 
 
 
 
 
 Friday 08:34
 
 
 
 
 
 
 
Dan indicated this below too... this is very long...
  
 the files for the export STILL need to be added to this path...
  
 C:\DTS\DTS.Suite\Data\BTF_Test\BTF_Test_Unit17 Trigger Test_2023_04_26 09_42\Exports\CSV\ROI\UNFILTERED\BTF_Test_Unit17 Trigger Test_2023_04_26 09_42
 
 
 
 
 
 
 
 
 
 
 
 
 
   
 
   
 
 
 
Chris Balogh  (assign)
 
 
 
 
 
 
 
 
 
 
 
 
 
 Friday 08:30
 
 
 
 
 
 
 
 

2023-04-26 14:23:13.092 DTS File Name: BTF_Test_Unit 17 Breakthrough Test 04262023_2023_04_26 10_19 does not match Test Id: BTF_Test .  Using file name as test Id
 
 
 
 
 
 
 
 
 
 
 
 
 
 
   
 
   
 
 
 
Chris Balogh  (assign)
 
 
 
 
 
 
 
 
 
 
 
 
 
 Friday 08:29
 
 
 
 
 
 
 
So... here's a smoking gun...
  
 This is the 60 char test id being used:
 BTF_Test_Unit 17 Breakthrough Test 04262023_2023_04_26 10_19
 
 
 
 
 
 
 
 
 
 
 
 
 
   
 
   
 
 
 
John Moors  (assign)
 
 
 
 
 
 
 
 
 
 
 
 
 
 Friday 08:29
 
 
 
 
 
 
 
Ah good to know!
   
 
Have we checked what the test setup name and test id's were in this instance for Todd?
 
  
 Yes, we mentioned the file length and comparing the two computers (failed on one, LT2, worked on the second LT3), and from what Arnold said here they're the same. They're not telling us the test name itself, for some reason, but if I follow then they would have had to be identical?
  
 Arnold Turner
  
 Yesterday 11:10
 To DTS, Todd Skinner, Bert Mcmahon, Kathryn Wittek Show all
 The file path on the original computer (LT2) and the new computer (LT3) is C:\DTS\DTS.Suite\Data\BTF_Test\file name
 
 
 
 
 
 
 
 
 
 
 
 
 
   
 
   
 
 
 
Chris Balogh  (assign)
 
 
 
 
 
 
 
 
 
 
 
 
 
 Friday 08:26
 
 
 
 
 
 
 
\\dts\files\HelpCenter\Private\Zendesk\11800
 
 
 
 
 
 
 
 
 
 
 
 
 
   
 
   
 
 
 
Chris Balogh  (assign)
 
 
 
 
 
 
 
 
 
 
 
 
 
 Friday 08:23
 
 
 
 
 
 
 
This ticket in MS was created when we used to crash because of this issue in basic info when creating all the metadata files:
 http://manuscript.dts.local/f/cases/10069/Crash-in-basic-info-of-run-test-when-you-exceed-248-char-for-your-paths-and-260char-for-filenames-if-your-test-ID-is-too-long
  
 This is a windows limitiation.
  
 There are safe gaurds needed in DP to prevent the user stepping in it, but they should certainly know about the limit so they can keep their test setup and test id lengths within reason.
  
 Have we checked what the test setup name and test id's were in this instance for Todd?
 
 
 
 
 
 
 
 
 
 
 
 
 
   
 
   
 
 
 
Chris Balogh  (assign)
 
 
 
 
 
 
 
 
 
 
 
 
 
 Friday 08:20
 
 
 
 
 
 
 
#8841
  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
   
 
   
 
 
 
John Moors  (assign)
 
 
 
 
 
 
 
 
 
 
 
 
 
 Friday 08:09
 
 
 
 
 
 
 
Thanks Chris! Since they were able to copy things over to another laptop and theoretically replicate, wasn't sure what I was missing. If the file path was not replicated despite what they said, makes sense to me!
 I'll search that "System.IO.PathTooLongException" in other tickets and see what I find.
 
 
 
 
 
 
 
 
 
 
 
 
 
   
 
   
 
 
 
Chris Balogh  (assign)
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Friday 07:39
 
 
 
 
 
 
 
I'll be in the office soon and can discuss more then.
 
 
 
 
 
 
 
 
 
 
 
 
 
   
 
   
 
 
 
Chris Balogh  (assign)
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Friday 07:38
 
 
 
 
 
 
 
Dan indicated that there are workarounds in zd and maybe HC for this. Searching the log error may bring up those other tickets.
 
 "System.IO.PathTooLongException"
 
 
 
 
 
 
 
 
 
 
 
 
 
   
 
   
 
 
 
Chris Balogh  (assign)
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Friday 07:37
 
 
 
 
 
 
 
The combination of test setup name, test id, and any files created (usually exports and multiple event use cases or a combination of the two)
 
 
 
 
 
 
 
 
 
 
 
 
 
   
 
   
 
 
 
Chris Balogh  (assign)
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Friday 07:35
 
 
 
 
 
 
 
Hi John,
 
 Dan is out today.
 
 The logs indicate that the total path, including the file names that DataPRO was creating at the time walere too long.
 
 "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. "
 
 
 
 
 
 
 
 
 
 
 
 
 
   
 
   
 
 
 
John Moors  (assign)
 
 
 
 
 
 
 
 
 
 
 
 
 
 Friday 07:29
 
 
 
 
 
 
 
Hi Dan McFadden - Is there any other info we could ask for to help narrow down what happened?
 
 
 
 
 
 
 
 
 
 
 
 
 
   
 
   
 
 
 
John Moors  (assign)
 
 
 
 
 
 
 
 
 
 
 
 
 
 Friday 07:28
 
 
 
To Todd Skinner, Bert Mcmahon, Arnold Turner... Show all
 
 
 
 
 
Thank you Arnold and Todd!
  
 I'm glad you were able to get your data exported, that's the most important item. I still would like to figure out what could have happened with the previous laptop, so I'll check with our Software team to see if there's something else we could investigate.
  
 John
 
 
 
 
 
 
 
 
 
 
 
 
 
   
 
 
 
Arnold Turner 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Friday 05:31
 
 
 
To DTS, Todd Skinner, Bert Mcmahon, Kathryn Wittek Show all
 
 
 
 
 
 
Yes, v 3.3.609 was on both. LT3 was updated to that version.
 
 
 
Thanks,
 
Arnold
 
 
 
 
 
 
 
 
 
 
 
 
 
 
   
 
 
 
Todd Skinner 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Thursday 20:07
 
 
 
To DTS, Bert Mcmahon, Arnold Turner, Kathryn Wittek Show all
 
 
 
 
 
 
John,
 
 
 
Correct. The first laptop uses 3.3.609 for the past couple months and has been working well except for yesterday. It appears it successfully downloaded data yesterday but couldn’t export it.
 
 
 
Today we installed 3.3.609 on a second laptop and then copied the previously exported files over to the second laptop and it exported the data to .CSV file.
 
 
 
Todd
 
 
 
 
 
 
 
 
 
 
 
 
 
 
   
 
   
 
 
 
John Moors  (assign)
 
 
 
 
 
 
 
 
 
 
 
 
 
 Thursday 18:27
 
 
 
To Todd Skinner, Bert Mcmahon, Arnold Turner... Show all
 
 
 
 
 
Hi Arnold,
  
 Thank you for confirming! For both computers, was the same version of DataPRO (3.3.609 from previous logs) being used?
  
 John
 
 
 
 
 
 
 
 
 
 
 
 
 
   
 
 
 
Arnold Turner 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Thursday 11:10
 
 
 
To DTS, Todd Skinner, Bert Mcmahon, Kathryn Wittek Show all
 
 
 
 
 
 
The file path on the original computer (LT2) and the new computer (LT3) is C:\DTS\DTS.Suite\Data\BTF_Test\file name
 
Bert can confirm the file path. On the original computer they have been using the same path for the last couple months without issues.
 
 
 
Todd
 
 
 
From: John Moors (DTS) &lt;support@dtsweb.zendesk.com&gt;
 Sent: Thursday, April 27, 2023 11:01 AM
 To: Skinner, Todd A &lt;todd.skinner@ngc.com&gt;
 Cc: McMahon, Bert [US] (MS) &lt;bert.mcmahon@ngc.com&gt;; Turner, Arnold [US] (MS) &lt;arnold.turner@ngc.com&gt;; Wittek, Kathryn J [US] (MS) &lt;kathryn.wittek@ngc.com&gt;
 Subject: EXT :[DTS] Re: DataPro Export Issue
 
 
 
 
 
 
 
 
 
 
 
 
 
 
   
 
   
 
 
 
John Moors  (assign)
 
 
 
 
 
 
 
 
 
 
 
 
 
 Thursday 11:06
 
 
 
To Todd Skinner, Bert Mcmahon, Arnold Turner... Show all
 
 
 
 
 
Hi Todd,
  
 Ah good to know, thank you!
  
 John
 
 
 
 
 
 
 
 
 
 
 
 
 
   
 
 
 
Todd Skinner 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Thursday 11:04
 
 
 
To DTS, Bert Mcmahon, Arnold Turner, Kathryn Wittek Show all
 
 
 
 
 
 
Bert can confirm the file path. On the original computer they have been using the same path for the last couple months without issues.
 
 
 
Todd
 
 
 
 
 
 
 
 
 
 
 
 
 
 
   
 
   
 
 
 
John Moors  (assign)
 
 
 
 
 
 
 
 
 
 
 
 
 
 Thursday 11:01
 
 
 
To Todd Skinner, Bert Mcmahon, Arnold Turner... Show all
 
 
 
 
 
Hi Todd,
  
 Understood, thank you for the update! One of the could-use methods was regarding the file path for the data perhaps being too long, did you use a shorter file path for the second laptop?
  
 John
 
 
 
 
 
 
 
 
 
 
 
 
 
   
 
 
 
Todd Skinner 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Thursday 10:28
 
 
 
To DTS, Bert Mcmahon, Arnold Turner, Kathryn Wittek Show all
 
 
 
 
 
 
John,
 
 
 
This morning Bert and Arnold were able to copy the data over to a second laptop with the identical DataPro version as well the configuration settings. It exported as expected.
 
 
 
I will let Bert or Arnold determine if we are able to share the binary data files.
 
 
 
Todd
 
 
 
 
 
 
 
 
 
 
 
 
 
 
   
 
   
 
 
 
John Moors  (assign)
 
 
 
 
 
 
 
 
 
 
 
 
 
 Thursday 10:02
 
 
 
To Todd Skinner, Bert Mcmahon, Arnold Turner... Show all
 
 
 
 
 
Hi Todd,
  
 Thank you for confirming! From the initial logs you sent, there could be a couple things for us to try.
  
 Is the dataset available so that we can run an export from our end? If you're not able to share that, we have a couple of other options.
  
 John
 
 
 
 
 
 
 
 
 
 
 
 
 
   
 
 
 
Todd Skinner 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Wednesday 20:42
 
 
 
To DTS, Bert Mcmahon, Arnold Turner, Kathryn Wittek Show all
 
 
 
 
 
 
John,
 
 
 
So far we have only tried one laptop but we are going to try downloading data from a second laptop tomorrow.
 
 
 
Bert can confirm but I believe it successfully downloaded the ROI but then freezes when attempting to export.
 
 
 
I just took a quick look at the data and I think there might have been a download issue because all the binary files are 8 KB. Data was recorded for 10 seconds at 4kHz so I would think these files should be bigger.
 
 
 
 
 
Todd
 
 
 
 
 
 
 
 
 
 
 
 
image002
 
JPG
 
 
 
 
 
 
 
 
 
 
 
 
   
 
   
 
 
 
Dan McFadden  (assign)
 
 
 
 
 
 
 
 
 
 
 
 
 
 Wednesday 16:59
 
 
 
 
 
 
 
these lines suggest path is too long:
  
 2023-04-26 14:24:02.834 DTS File Name: BTF_Test_Unit 17 Breakthrough Test 04262023_2023_04_26 10_19 does not match Test Id: BTF_Test .  Using file name as test Id
 2023-04-26 14:24:02.882 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. !!  An exception of type: System.IO.PathTooLongException occurred Module: mscorlib.dll, Name: LegacyNormalizePathMessage: 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. StackTrace:    at System.IO.Path.LegacyNormalizePath(String path, Boolean fullCheck, Int32 maxPathLength, Boolean expandShortPaths) StackTrace:    at System.IO.Path.InternalGetDirectoryName(String path)    at DataPROWin7.SubControls.Export.ExportCSV(Boolean filtered, String dest, Boolean csvMV, Boolean csvADC, Boolean enforceLinearCalibration, String extensionPrefix, ObservableCollection`1 exportHeaders, Boolean bExportBoth)    at DataPROWin7.SubControls.Export.DoOneExport(Object o)
  
 there may be a workaround where we rename one or more of the folders or files to export in their existing software, but it's probably easiest and most complete if we can get access to their dataset and run the export here, if not we can explore work arounds to export the data.
 
 
 
 
 
 
 
 
 
 
 
 
 
   
 
   
 
 
 
Dan McFadden  (assign)
 
 
 
 
 
 
 
 
 
 
 
 
 
 Wednesday 16:47
 
 
 
 
 
 
 
[I see that in the DataPRO_TestLogs (1).zip]
 
 
 
 
 
 
 
 
 
 
 
 
 
   
 
   
 
 
 
Dan McFadden  (assign)
 
 
 
 
 
 
 
 
 
 
 
 
 
 Wednesday 16:46
 
 
 
 
 
 
 
I do see this in the log:
  
 2023-04-26 14:24:02.834 DTS File Name: BTF_Test_Unit 17 Breakthrough Test 04262023_2023_04_26 10_19 does not match Test Id: BTF_Test .  Using file name as test Id
 2023-04-26 14:24:02.882 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. !!  An exception of type: System.IO.PathTooLongException occurred Module: mscorlib.dll, Name: LegacyNormalizePathMessage: 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. StackTrace:    at System.IO.Path.LegacyNormalizePath(String path, Boolean fullCheck, Int32 maxPathLength, Boolean expandShortPaths) StackTrace:    at System.IO.Path.InternalGetDirectoryName(String path)    at DataPROWin7.SubControls.Export.ExportCSV(Boolean filtered, String dest, Boolean csvMV, Boolean csvADC, Boolean enforceLinearCalibration, String extensionPrefix, ObservableCollection`1 exportHeaders, Boolean bExportBoth)    at DataPROWin7.SubControls.Export.DoOneExport(Object o)
  
 it coudl be that the path is too long, I think we have work arounds to test this, let me check zendesk.
 
 
 
 
 
 
 
 
 
 
 
 
 
   
 
   
 
 
 
Dan McFadden  (assign)
 
 
 
 
 
 
 
 
 
 
 
 
 
 Wednesday 16:44
 
 
 
 
 
 
 
4-26-logs does not contain DataPRO.log, it appears to contain logs from earlier (the most recent: 2023-04-26 10:19:32.998 Building test plan)
 I'm not sure if this contains the export failing run?
 I do see in one of the logs from that zip this export:
 2023-04-26 10:08:17.893 ModalWindow: Warning: files with export data already exist in  C:\DTS\DTS.Suite\Data\BTF_Test\BTF_Test_Unit17 Trigger Test_2023_04_26 09_42\Exports\CSV\ROI\UNFILTERED\BTF_Test_Unit17 Trigger Test_2023_04_26 09_42  Select 'Yes' to overwrite the old files, or 'No' to discontinue the export.  Alternatively, you can preserve the existing test files by moving the files in this folder to another location before selecting 'Yes'.
  
 I do not see an indication of a failure here and I do see an indication that the user when back to the edit test setup page, suggesting they had finished?
 2023-04-26 10:08:19.606 User Admin navigated forward to page: Prepare_TestSetups_EditTestSetup_Page
  
 is the dataset available so that we can run an export here?
  
 3.3.609 is a bit old and for sure there have been export fixes since that version.  If the dataset is not available, would suggest seeing if they can try the export on a more recent version of datapro to see if it's fixed by one of the resolved issues after 609.
  
 If not suggest to see if we can get them to clear the logs folder, do an export, then send the logs folder as a zip in the hope that we get the datapro.log that way?  There's also an exception.log file that can be written to the binary directory on unhandled exceptions.
  
  
  
  
 
 
 
 
 
 
 
 
 
 
 
 
 
   
 
   
 
 
 
John Moors  (assign)
 
 
 
 
 
 
 
 
 
 
 
 
 
 Wednesday 16:32
 
 
 
To Todd Skinner, Bert Mcmahon, Arnold Turner... Show all
 
 
 
 
 
Hi Todd,
  
 Sorry you're running into these export issues. Thank you for supplying the logs! I've assigned this ticket to our Software group and we'll see if they need any other information to investigate.
  
 Just to confirm, was the test executed, data downloaded, and data export attempted all with the same laptop or multiple laptops?
  
 John
 
 
 
 
 
 
 
 
 
 
 
 
 
   
 
   
 
 
 
John Moors  (assign)
 
 
 
 
 
 
 
 
 
 
 
 
 
 Wednesday 16:31
 
 
 
 
 
 
 
Hi Todd,
  
 Sorry you're running into these export issues. Thank you for supplying the logs! I've assigned this ticket to our Software group and we'll see if they need any other information to investigate.
  
 John
 
 
 
 
 
 
 
 
 
 
 
 
 
   
 
 
 
Todd Skinner 
 
 
 
 
 
 
 
 
 
 
 
 Wednesday 14:55
 
 
 
To Todd Skinner, Bert Mcmahon, Arnold Turner... Show all
 
 
 
 
 
 
Hi,
 
Attached are two sets of logs.  The "4-26-logs.zip" is the logs created to from DataPro.  The "DataPRO_TestLogs.zip" logs are the one created when data was downloaded from the DAS to the laptop.
 
Let us know if you need any additional information.
 
Best Regards,
 
Todd Skinner
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
4-26-logs
 
ZIP
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
DataPRO_TestLogs
 
ZIP
 
 
 
 
 
 
 
 
 
 
 
 
   
 
 
 
Todd Skinner 
 
 
 
 
 
 
 
 
 
 
 
 Wednesday 13:07
 
 
 
To Todd Skinner, Bert Mcmahon, Arnold Turner... Show all
 
 
 
 
 
 
Hi,
 
Bert and Arnold are running into an issue where DataPro v3.3.609 can't export downloaded data to a CSV file.  The data appears to have successfully downloaded but when exporting it just freezes the software and DataPro has to be restarted.  Bert is working on getting the log files downloaded and attached to this ticket.  They have tired restarting DataPro and the laptop as well as power cycling the DAS. Let me know if you have any recommendations.   
 
I would like assistance for the following:
 
1.) How to fix the data export issue on the current laptop.
 
2.) What files are needed if the data file is copied to another computer with DataPro v3.3.609 to successfully export the datafile to a CSV file?  Is just the test configuration file needed and the data folder or is more files needed.
 
Best Regards,
 
Todd Skinner</Comment>
    <StatusString>Opened</StatusString>
    <TimeStamp>2023-05-01T17:00:57Z</TimeStamp>
    <ZendeskNumber>0</ZendeskNumber>
    <Status>Opened</Status>
  </FBEvent>
</ArrayOfFBEvent>