I searched for this topic here, and did not find anything, so I just want to bring it to people's attention.

Deep directory paths and or file names in windows exceeding 255 chars.  I was getting weird results when opening logs and using auto-detect, bad failures like files seeming to disappear, or logs that were there missing newline inside the right view pane... I just happed to install the beta version, but did not want to believe it was LVP so I resisted the urge to downgrade and looked closer.   Then I noticed weirdness in file explorer. Looking up at the path bar in file explorer, I saw something I hadn't seen in years- windows  EIGHTD~1.TXT (eight dot three) names.

Our application which runs on Linux has some tools to bundle logs.  This leads to very long file names with FQDN names and dates so one tar file may be 40 chars long.  It gets up to 255 quick when having several of those in the path.  Of course, a non issue in Linux and probably windows OS or the NTFS filesystem- but it is an issue with APIs to open files.  (Google some of the key words in italics up top).

My workaround is to take those 40 char file names and call them A or B, or dec19 if I need a marker, and get those silly path names shorter.  LVP beta then worked like a champ.

Just a heads up because, I actually was thinking it was parser problems because that's where it was showing up, and I didn't have a noticeable warning.  (Maybe there's something in the API the can tell when the threshold is reached and warn the user via pop-up)?

That's if you reproduce, and see what I encountered.  I took some screen shots, which I may still have if interested.  I was all prepared to scream bug here, and then when I saw the 8.3 doing my own recorded test, I got embarrassed but then figured the brotherly thing to do is  report it

Thanks.

Thanks for this Strat.

Long path name support is a new feature in LogViewPlus.  It is something we get 'for free' with the recent upgrade to .Net 4.7.2.  I am glad you got it working - but I would also like to improve on any deficiencies. 

Screenshots might help me better understand the problem.  If you do not feel comfortable making the screenshots public, please contact me and I will send you an email you can reply to.

Thanks!

Toby

Ok thanks!  The .net upgrade may have made this moot, but I am on v.2.4.41 at the moment.

I was able to reproduce some of it starting from scratch.  Just created some folders with crazy long names, about 5 deep, and then put some log files there.  I was not able to reproduce the 8.3 paths, but I don't think that had anything to do with LVP.  I'm thinking it was 7-zip. The only thing that went wrong is the "Open Log File" box was missing one of the files.

Here you can see  4 files in windows file explorer (which was behaving at the moment):

And here below, LVP does not show the file superelasticbubbleplastic.log* (saw more missing files in prior occurrence).


Thanks again!

Thanks for the update Strat.

It seems there are two aspects to this problem:

1.  Does the application functionality work?

From the screenshots above, it looks like everything is working correctly.  You are able to open files.  If you are having difficulty here, then please upgrade to LogViewPlus 2.5 or greater.  New versions of LogViewPlus use .Net 4.7.2 which should handle long path names more easily.

2.  Application Usability.

Here, it looks like LogViewPlus could be doing better.  Some of those paths are a bit unmanageable and I can see where applying a tilde would help.  Unfortunately, this would require a significant change in how we handle paths.  This is something we will need to think about.

The screenshots definitely help clarify. Thanks for putting this problem on our radar.  

...and Happy Holidays!  :-)

Toby