Hallo,
I have three feature requests:
1. Could you please  allow to use compression when connecting to an SFTP server?
2. Proper handling of symlinks to folders on SFTP-Servers as folders, not as files (current behavior).
3. Loading the configured size of the last bytes for tail files at reload(currently no last bytes are loaded by reload).

Thank you.

Hi Marauder,

Thanks for the feedback.  I think these are all good ideas. 

They are going to require a bit of investigation on my part.  I will take a look and try to get these changes in for the next release.

Thank again,

Toby

Hi Marauder,

Just wanted to let you know that we have now released LogViewPlus v2.5.42 as a beta release.  This release addresses all of the issues highlighted above.

Hope that helps.  Thanks again for bringing these issues to our attention.

Toby

Hi LogViewPlus Support,

thanks for the update. I have tested version 2.5.42 and 2.5.51
But i still have a problem with symlink resolution:

in a case if the symlink as destination has absolute path -> the resolution and handling works without problem.
...../current -> /data/folder

in a case if the symlink as destination have a relative path to parent of symlink  -> the resolution  don't work
...../current -> folder 

Thanks for reporting this issue.  Unfortunately, I am not able to recreate the problem locally.

It could be an issue with the communication between the client and server.  Have you tried checking the transfer logs?  Are any issues reported?



Is the symlink working correctly in other applications?  If so, this would rule out the server side of the problem.

Thanks again,

Toby

Hi,

this are steps to reproduce:

1. cd /tmp
2. mkdir logViewPlus
3. cd logViewPlus
4 . mkdir 1
5. ln -s /tmp/logViewPlus/1 ./absLink
6 .ln -s ./1 ./relLink
7. ls -l
      drwxr-xr-x 1 xxx users 0 Jan 9 19:55 1
      lrwxrwxrwx 1 xxx users 18 Jan 9 19:56 absLink -> /tmp/logViewPlus/1
      lrwxrwxrwx 1 xxx users 3 Jan 9 19:56 relLink -> ./1

By opening folder '/tmp/logViewPlus' in logViewPlus i see this picture:


Corresponding TransferLog :
19:57:05.305 sftp:/xxx@xxxride.test:22 | Logging in user qqcmsp0....
19:57:05.356 sftp://xxx@xxxride.test:22 | Requesting interactive authentication.
19:57:05.499 sftp://xxx@xxxride.test:22 | Using SFTP v3 on a Unix-like platform.
19:57:05.507 sftp://xxx@xxxridee.test:22 | Home directory is '/home/xxx'.
19:57:05.508 sftp://xxx@xxxrideride.test:22 | Connected
19:57:10.638 sftp://xxx@xxxride.test:22 | Unable to resolve symlink /tmp/logViewPlus/relLink -> ./1

The sym link with absolute path can be resolved and the sym link with related path not.

Thanks for the detailed bug report.

I am still not able to recreate the issue, but the last log line you provided gives a good indication of the problem.  I have spent some time investigating and it appears our test SFTP servers are always providing fully resolved paths when we request symlink resolution.  Your SFTP server appears to be resolving to a relative path only.

I can test this scenario by simulating a server response.  I will put in a fix for this issue into the next BETA release - currently scheduled for next week.

Thanks again,

Toby

Hi Marauder,

We have now released LogViewPlus version 2.5.52 as a BETA release.  This release includes an updated symlink implementation which should resolve the issue discussed above.

Thanks for bringing this issue to our attention.

Toby

Thanks for fix.
It works almost perfectly. It seems like you check if the link-destination starts with '.' to see if it is a relative path or not.
I think you have to check if the link-destination doesn't start with "/" to detect relative-path.

Thanks.

RMarauder

Thanks for the update.

Yes - this is what we are doing.  The suggested approach makes sense.  I will take a look for the next BETA release.

Toby