Delete Files from UI


Author
Message
Brad Konia
Brad Konia
Junior Member (68 reputation)Junior Member (68 reputation)Junior Member (68 reputation)Junior Member (68 reputation)Junior Member (68 reputation)Junior Member (68 reputation)Junior Member (68 reputation)Junior Member (68 reputation)Junior Member (68 reputation)
Group: Forum Members
Posts: 48, Visits: 73
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...
LogViewPlus Support
LogViewPlus Support
Forum Expert (925 reputation)Forum Expert (925 reputation)Forum Expert (925 reputation)Forum Expert (925 reputation)Forum Expert (925 reputation)Forum Expert (925 reputation)Forum Expert (925 reputation)Forum Expert (925 reputation)Forum Expert (925 reputation)
Group: Moderators
Posts: 656, Visits: 2K
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
Edited 4 Months Ago by LogViewPlus Support
Brad Konia
Brad Konia
Junior Member (68 reputation)Junior Member (68 reputation)Junior Member (68 reputation)Junior Member (68 reputation)Junior Member (68 reputation)Junior Member (68 reputation)Junior Member (68 reputation)Junior Member (68 reputation)Junior Member (68 reputation)
Group: Forum Members
Posts: 48, Visits: 73
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.
Edited 4 Months Ago by Brad Konia
LogViewPlus Support
LogViewPlus Support
Forum Expert (925 reputation)Forum Expert (925 reputation)Forum Expert (925 reputation)Forum Expert (925 reputation)Forum Expert (925 reputation)Forum Expert (925 reputation)Forum Expert (925 reputation)Forum Expert (925 reputation)Forum Expert (925 reputation)
Group: Moderators
Posts: 656, Visits: 2K
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.

Edited 4 Months Ago by LogViewPlus Support
Brad Konia
Brad Konia
Junior Member (68 reputation)Junior Member (68 reputation)Junior Member (68 reputation)Junior Member (68 reputation)Junior Member (68 reputation)Junior Member (68 reputation)Junior Member (68 reputation)Junior Member (68 reputation)Junior Member (68 reputation)
Group: Forum Members
Posts: 48, Visits: 73
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.



Edited 4 Months Ago by Brad Konia
LogViewPlus Support
LogViewPlus Support
Forum Expert (925 reputation)Forum Expert (925 reputation)Forum Expert (925 reputation)Forum Expert (925 reputation)Forum Expert (925 reputation)Forum Expert (925 reputation)Forum Expert (925 reputation)Forum Expert (925 reputation)Forum Expert (925 reputation)
Group: Moderators
Posts: 656, Visits: 2K
I'm not sure what you mean about the Delete or Esc keys?

These are the shortcut keys for closing the current view.  'Delete' key is the default shortcut for closing the view.  This is problematic if we were to add a Delete command because the obvious shortcut would remain mapped to something else.  It is very common for users to close a view with the 'Delete' key.  This is to say that you are 'done' with the view.

The problem is that closing the SFTP client minimizes the main window.

This was definitely a problem with v2.5.22, but it should be resolved in the latest release.  I just tested 20-30 times locally by connecting to a remote server, and opening the Explorer a few times.  I closed with the close button (upper right) and Cancel command (lower right) and was unable to recreate. 

Are you sure you are running the latest version?  This release of LogViewPlus changed the installer.  It is possible you have two instances installed and might be running the wrong one.

I interpreted as a "Close Workspace" function. Close "View" is a confusing term. What is a view?

That is a good point. Thanks for bringing this to my attention. The button predates "Workspaces" in LogViewPlus and we also have plans to allow users to open multiple workspaces. I will remove this command from the next release.

I can also see why the 'View' term is confusing. I will get this changed as well.

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."

This is a tricky statement.  I agree with it as written, but it is very common for applications to delete the previous / old log file on startup.  Files can also be rolled which might temporarily appear as a deletion.  LogViewPlus should absolutely not detect this as an indication that it should be removed from the view.  Users are frequently interested in old log entries and a very common use case is, "I found an error and I want to see if this change fixes it."

We have an application setting which controls whether or not the log entries should be cleared when the log file is rolled.  I was trying to think if this setting could be reused or another setting added, but I think this issue is significantly different. 

It's frustrating to delete a file and then have to perform several additoinal step to remove it from the viewer.

I think this is really the core of the problem and I would like to make the process better.  The problem is a little more complicated then it may sound due to the issues discussed in this thread.

The best idea I can think of for the moment is to add a built-in external command type.  Something like "LVP_DELETE %{SELECTED_FILE}".  Once configured, commands are available in the context menu and I can see where "Built-in Commands" might make sense because we have a SSH session open already.  Also, the UI may need to react to the command rather than just the file system action. 

It would make this a 'niche' feature that you need to opt-in to and configure, but I think it would give you the convenience you are looking for.  It would also give us flexibility to add similar functionality going forward.

Would this approach work for you?

Sorry for the long reply - we are covering a lot of ground in this thread.  :-)

Toby
Edited 4 Months Ago by LogViewPlus Support
Brad Konia
Brad Konia
Junior Member (68 reputation)Junior Member (68 reputation)Junior Member (68 reputation)Junior Member (68 reputation)Junior Member (68 reputation)Junior Member (68 reputation)Junior Member (68 reputation)Junior Member (68 reputation)Junior Member (68 reputation)
Group: Forum Members
Posts: 48, Visits: 73
These are the shortcut keys for closing the current view. 'Delete' key is the default shortcut for closing the view. This is problematic if we were to add a Delete command because the obvious shortcut would remain mapped to something else. It is very common for users to close a view with the 'Delete' key. This is to say that you are 'done' with the view.

You could make it Shift-Delete. This would make sense, since physically deleting a file would then require more "effort" than just removing it from the view. Holding down the Shift key would be like an extra confirmation that you really want to delete the file and remove it from the workspace.

Are you sure you are running the latest version? This release of LogViewPlus changed the installer. It is possible you have two instances installed and might be running the wrong one.

I was using the latest beta that you posted. I'll let you know if it happens again.

This is a tricky statement. I agree with it as written, but it is very common for applications to delete the previous / old log file on startup. Files can also be rolled which might temporarily appear as a deletion. LogViewPlus should absolutely not detect this as an indication that it should be removed from the view. Users are frequently interested in old log entries and a very common use case is, "I found an error and I want to see if this change fixes it."

OK, but there's a big difference between LVP detecting a deleted file on its own vs the user explicitly deleting a file in the UI.

It would make this a 'niche' feature that you need to opt-in to and configure, but I think it would give you the convenience you are looking for. It would also give us flexibility to add similar functionality going forward.

I don't know. It sounds like a lot of work on your end to develop and maintain what's essentially a hack. External commands can be useful for users who need certain functionality that's unique to them, but I feel like the ability to delete a file would be used by many people and should be a native feature. If you're concerned that people might accidentally delete stuff, you could add a preference setting to enable the feature and leave it disabled by default. I think this would be a lot cleaner than an external command.




LogViewPlus Support
LogViewPlus Support
Forum Expert (925 reputation)Forum Expert (925 reputation)Forum Expert (925 reputation)Forum Expert (925 reputation)Forum Expert (925 reputation)Forum Expert (925 reputation)Forum Expert (925 reputation)Forum Expert (925 reputation)Forum Expert (925 reputation)
Group: Moderators
Posts: 656, Visits: 2K
Thanks Brad.  I think you are probably right on all counts.  I will have a think about it and see what I can come up with.  I will post back here when I have something ready in beta.

Thanks again for the feedback,

Toby
Brad Konia
Brad Konia
Junior Member (68 reputation)Junior Member (68 reputation)Junior Member (68 reputation)Junior Member (68 reputation)Junior Member (68 reputation)Junior Member (68 reputation)Junior Member (68 reputation)Junior Member (68 reputation)Junior Member (68 reputation)
Group: Forum Members
Posts: 48, Visits: 73
On a related issue, if you delete a file from the file system, then remove it from the File Transfers pane, what happens if the file is later recreated in the monitored directory? Does LVP maintain a memory of removed files, or should the file automatically reappear? Hopefully, the latter.

I'm asking because yesterday, I deleted a file and removed it from the File Transfers pane. Today, that file was recreated, but it hasn't reappeared in LVP. Since LVP is monitoring the directory and since I haven't knowingly created any rule to exclude that file, why isn't it showing up?

The file DOES come back after reloading the workspace, but it should show up automatically as part of the directory monitoring process.
Edited 4 Months Ago by Brad Konia
LogViewPlus Support
LogViewPlus Support
Forum Expert (925 reputation)Forum Expert (925 reputation)Forum Expert (925 reputation)Forum Expert (925 reputation)Forum Expert (925 reputation)Forum Expert (925 reputation)Forum Expert (925 reputation)Forum Expert (925 reputation)Forum Expert (925 reputation)
Group: Moderators
Posts: 656, Visits: 2K
The transfers pane is used to monitor a particular file on a remote file system.  It has no concept of a deleted file as it is also monitoring for creation.  If you remove the monitor you have explicitly disabled it, so the current behavior is correct.  It should not automatically reappear.

When the directory monitor discovers a new file, an event is raised and LogViewPlus can see that you already have the file open in your main view.  No further work is necessary. 

The transfer pane is not part of the directory monitoring logic.  It is part of the file monitoring logic.

If you would like to re-establish the transfer connection, try refreshing the file or closing files which are not syncing from the main view and refreshing the directory monitor.

Hope that helps,

Toby
GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...




Similar Topics

Login

Explore
Messages
Mentions
Search