I agree it should be read-only in terms of not creating or editing files, as that would be outside the scope of a log viewer. However, the ability to delete unwanted files would be within scope. The purpose of a log viewer is to make it convenient to consume log files. Part of being convenient includes organizing the files, which in turn, should include the ability to delete unwanted or obsolete files. Indeed, it already includes this capability in the built-in SFTP client. It's just not convenient to access it, and even after you delete a file, you still have to perform additional steps to remove it from the panes in the main window.

I don't consider steps 1 - 3 as too demanding. For "Step 4", you could have just closed the view with either the Delete key or Esc

Steps 1 - 3 are not extremely demanding, though certainly not as convenient as having a delete option in the context menu. The problem, as I mentioned above, is that after physically deleting the file, you still have to perfrom additonal steps to remove it from the UI.Regarding Step 4, I'm not sure what you mean about the Delete or Esc keys? The problem is that closing the SFTP client minimizes the main window. And yes, I should have said "minimized", not closed. It was still running in the system tray.

Step 6 is by design. Closing from the transfer pane terminates the connection. The file will no longer be monitored (tail will be disabled), but the view will remain.

Yes, I understand it's by design and I don't disagree with the design. There are times when you may want to stop monitoring a file, but leave it in the top pane, so that's fine. My problem is, when you DELETE a file, you're in effect saying, "I'm done with this file. I don't want to see it anymore anywhere. I want it gone.". It's frustrating to delete a file and then have to perform several additoinal step to remove it from the viewer. As I mentioned, it makes the process feel convoluted and messy, like I deleted this file, why is it still here? Therefore, I envision the context-menu Delete function as being a shortcut to performing all these steps in a single operation.

Step 7 - the option you are looking for is 'Close' or 'Close View'. Closing the view will automatically remove the transfer (step 6)

Yes, I see that now. That close option also appears in the upper-right corner of the screen, which due to its location in the UI, I interpreted as a "Close Workspace" function. Close "View" is a confusing term. What is a view? I assume it could be either a file or a filter, so instead of using the broad term "View", I'd suggest that it change based on what's currently selected. If you have a file selected, it should say Close File. If you have a filter selected, it should say Close Filter.

So, there are a couple of things to pick up on here.

I don't think software should be in the business of being a nanny

I think this is a strong argument and I will consider it.  However, in general, I think that LogViewPlus should aim to be a 'read-only' application.  I don't consider steps 1 - 3 as too demanding.  For "Step 4", you could have just closed the view with either the Delete key or Esc (if enabled).

Closed the SFTP client. This caused the entire application to close.

The application closed or was minimized?  I have seen the minimize behavior before and I thought this was corrected in the latest version.  Closed is another problem and may indicate an application crash.  If so, there is likely information in your Windows Event Logs.

Step 6 is by design.  Closing from the transfer pane terminates the connection.  The file will no longer be monitored (tail will be disabled), but the view will remain.

Step 7 - the option you are looking for is 'Close' or 'Close View'.  Closing the view will automatically remove the transfer (step 6).

We have discussed in another thread the need to better convey the state of the remote file system.  I think this is a good idea and if this feature were in place it might help with some of the issues you highlighted above.

Toby

Update: Edited formatting.

OK, I'm sorry to keep harping on this, but it doesn't seem like a clean process. For example, I wanted to remove two obsolete files from a directory, so I did this:

1. Right clicked on one of the files and selected "Open Directory". The directory opened.

2. Deleted both files from the directory.

3. Closed the SFTP client. This caused the entire application to close. It seems to be the same bug that you recently fixed with closing the wizard.

4. Re-opened the application.

5. Now the bottom pane showed a blank filename for one of the deleted files. The other deleted file was not there. Why the inconsistency? The top pane also showed only one of the deleted files. Again, not consistent behavior.

6. Right-clicked on the blank file name in the bottom pane and selected "Cancel". This removed the file from the bottom pane, but it remained in the top pane.

7. Right-clicked on the file in the top pane and looked for an option in the context menu to remove the file from the pane. No remove option exists! So now I'm stuck with having my top pane cluttered up with an obsolete file that no longer even exists in the directory.

It's just way too many steps, inconsistent behavior, too much work to do something as simple as deleting a file, and in the end, you can't really get rid of it anyway. It shouldn't be this hard. It seems like you're trying to protect the user, or make it difficult / inconvenient for the user to do something that he may have a very good reason to do.What's wrong with displaying a simple confirmation dialog. "This will permanently delete the file from the disk. Are you sure want to proceed?" People accidentally delete files all the time. It happens, that's life. Beyond displaying a confirmation dialog, I don't think software should be in the business of being a nanny and second-guessing what the user wants to do.

Having a delete option would eliminate all these convolulted steps. It would be a single action that would delete the file from the disk, stop monitoring it in LVP and remove it from the file list in the top pane.

Hi Brad,

Thanks for the feedback.

I understand sometimes log files are disposable, but the idea of deleting a log file makes me a bit nervous.  It is important to remember that in production deleting a log file could be very a serious issue.  Information is lost and there could be compliance and legal issues as well.  The importance of a log file can range from junk to critical.

Right now, deleting a file takes two actions.  First, right-click on the file and select 'Open Directory'.  Second, press the 'Delete' key and confirm the deletion.  You could also cleanup files with a custom command. 

So, deleting a log file in LogViewPlus takes a little bit of work and I think this is probably about right.  In both cases, the user's intent is very clear.

What I would suggest instead is either removing the file from the view (possibly with the ESC key) or clearing the contents of the log file (F4).  These options help manage data while leaving the file system unchanged.

Hope that helps,

Toby

I understand the principle that LVP is a log file viewer, not an editor, and generally it should not be writing to files.

HOWEVER, there are many times when you simply need to delete a log file, due to it being out-of-date, or you changed the format, or a million other reasons. It's inconvenient to have to manually go to the file system to perform the deletion. It would be much nicer and cleaner if you could simply right-click on the file in the LVP UI and select Delete from the context menu.Doing it this way would provide the additional benefit of having the file immediately removed from LVP, instead of deleting from the file system, then having to wait for LVP to recognize the deletion, etc...