#55 FVS 20200713 silently deletes user data

[Todd]

Example: turning off tripling removes a previously saved tree list

Repro:

1. Perform a run and save any output table as C:\FVS\Project_1{GUID for run}.csv
2. Click the Runs -> Save and Run button again.

Trivial workarounds:

1. Have users persist downloaded files in some other directory. Technically this is done by default since most browsers will place downloads in the user's Downloads directory. However, it's likely the user will then want to move them somewhere else.
2. Educate users not to modify downloaded files to include the run GUID in their name if moving them to C:\FVS\Project_1.

There appear to be three issues here. Addressing the first would mitigate the other two.

1. Greedy deletion which appears to delete any file whose name contains the run GUID and therefore removes files FVS does not own.
2. Hard deletion of user files instead moving them to the Recycle Bin. While this is a common implementation choice because it's easier for programmers it can be less than ideal from a user standpoint.
3. Failure to detect user files will be deleted and ask the user if they really want to delete. This would close the user education hole, particularly if the dialog is written to explain the issue rather than as a simple yes/no prompt.

[Mike Shettles]

Todd,

Our user support helpdesk email address is sm.fs.fvs-support@usda.gov. This is the preffered means of contact for encounters using the FVS system through the normal means of the user interface. This open-fvs ticketing process is typicall for issues encountered while using the code base directly, whenther that's for development, or using the rFVS API functionality, for example.

As you've noticed, FVS overwrites the output results of previous simulationis with the same run title. This has long been standard functionality, with exception of the database table outputs, where the new FVS system overwrites those as well. We recommend creating a new run, or duplicating a previous run if only a few things changed, if you want to compare differences in outputs accross different simulation content options.

You might also consider the training guides that come standard with the complete installation package. They cover, among many other things, basic functionality elements such as this.

Kind regards,
-Mike

[Todd]

Hi Mike, OK, sorry, I didn't know. Email sent.

I just did a few searches on C:\FVS\Training Guides\PacificNorthwestRegionFVSTrainingGuide.pdf and it doesn't document internal details of file handling that I can see. While not deleting "foo RunGUID baz.notAnFvsExtension" or just "RunGUID.notAnFvsExtension" is certainly basic behavior it doesn't seem to have been implemented. I would certainly hope a user who modified the .key or roundtripped on the .Rdata wouldn't be surprised if those files got stomped.

[Nick Crookston]

I concur with Mike's comments. If you want to have one run with a set of
options, and then another run that is based on the first with different
options, then duplicate the first run, give it a fresh name (or the system
will) and "run" them both.

The output database is maintained with the outputs from running each run.
If you rerun a run, the process is as follows.

1. The run is made with the outputs going to a fresh sqlite3 database.
2. After the simulation is correct, the output from the fresh database is
   inserted into "FVSOut.db". This is a two step process. The first step is to
   delete all rows in all tables that associated with the run's unique ID.
   Then, the data from the "fresh" database is inserted into FVSOut.db and
   then the "fresh" database is deleted.

The goal of programming this was to create a system where the outputs from
FVS always reflect the most recent "run" of a run and that nothing from
previously running a run is left on the file system. Under the old
"Suppose" interface, this kind of file management was a major source of
frustration and errors.

Nick Crookston

On Thu, Aug 6, 2020 at 9:28 AM Todd West twest820@users.sourceforge.net
wrote:

Hi Mike, OK, sorry, I didn't know. Email sent.

I just did a few searches on C:\FVS\Training
Guides\PacificNorthwestRegionFVSTrainingGuide.pdf and it doesn't document
internal details of file handling that I can see. While not deleting "foo
RunGUID baz.notAnFvsExtension" or just "RunGUID.notAnFvsExtension" is
certainly basic behavior it doesn't seem to have been implemented. I would
certainly hope a user who modified the .key or roundtripped on the .Rdata
wouldn't be surprised if those files got stomped.

---

** [tickets:#55] FVS 20200713 silently deletes user data**

Status: New
Created: Thu Aug 06, 2020 03:00 PM UTC by Todd West
Last Updated: Thu Aug 06, 2020 03:41 PM UTC
Owner: nobody

Example: turning off tripling removes a previously saved tree list

Repro:
1. Perform a run and save any output table as C:\FVS\Project_1{GUID for
run}.csv
2. Click the Runs -> Save and Run button again.

Trivial workarounds:
1. Have users persist downloaded files in some other directory.
Technically this is done by default since most browsers will place
downloads in the user's Downloads directory. However, it's likely the user
will then want to move them somewhere else.
2. Educate users not to modify downloaded files to include the run GUID in
their name if moving them to C:\FVS\Project_1.

There appear to be three issues here. Addressing the first would mitigate
the other two.
1. Greedy deletion which appears to delete any file whose name contains
the run GUID and therefore removes files FVS does not own.
2. Hard deletion of user files instead moving them to the Recycle Bin.
While this is a common implementation choice because it's easier for
programmers it can be less than ideal from a user standpoint.
3. Failure to detect user files will be deleted and ask the user if they
really want to delete. This would close the user education hole,
particularly if the dialog is written to explain the issue rather than as a
simple yes/no prompt.

---

Sent from sourceforge.net because you indicated interest in <
https://sourceforge.net/p/open-fvs/tickets/55/>

To unsubscribe from further messages, please visit <
https://sourceforge.net/auth/subscriptions/>

--
Nicholas L. Crookston
Forestry Research Consultant
Moscow Idaho USA

[Lance R. David]

This was a user interface issue not FVS base model and has been resolved.