Digital Workshop

Hi

Previously in the Forum, in response to an inquiry about deleting all .txt files in a folder (created by the viewer in runtime as storage files in the owner's Document directory to hold pub-generated data), the delete file action with a wildcard (either the generic-all files *.* or specific to all .txt files-*.txt) was mentioned, with cautions.

I appreciate that were the wrong pathname used, it would potentially wipe out alot of data, which would be quite problematic. Definitely wouldn't want to set up a situation in a pub where this could even remotely occur.

However, given the amount of repetitive work needed to set up deletion of a couple of hundred files in a single folder, plus repeating this for 4 more folders (5 folders in total), it would be quite useful to employ a single delete file action, placing the specific folder\*.txt as the pathname, X5.

As a novice, never having used a wildcard for this delete action, I wonder if anyone with more experience can comment on the likelihood of unintended deletion, if care is taken to assure the correct pathname to a specific folder. Plainly stated, can the pathname alter accidentally in runtime and produce unintended consequences, or can another uncontrollable glitch occur that, in spite of an accurate original pathname plus wildcard specifying only .txt files, will do damage?

I'd appreciate any thoughts, comments or prior experiences with this to help weigh using this action or not.

At this point, I'm afraid to use this wildcard action (maybe rightly so?).

Kind Regards,

Stephen

Hi

An update to the above posting:

I experimented with a delete file action using the SYSTEM_DOCUMENTS_DIR\foldername\*.txt to check if it worked.

Unlike a similar copy file action using the exact same pathname and folder and wildcard config, which does work: this delete action failed.

Not sure why. Need to use the variable, if I set this up at all, since owner documents can have different pathnames like the actual user name instead of "owner" in them. So, SYSTEM_DOCUMENTS_DIR is needed rather than a specific pathname.

I would appreciate any help with the original issue (in the above posting) re: safe use of a wildcard for folder delete of multiple .txt files, plus, if safe to use, how then to set the correct pathname so that it works.

Thanks.

Kind Regards,
Stephen

Hi Stephen

Are the files you want to delete created by the pub ?

Chris

Hi Chris

Yes, all of the files save data related to positions of dragged and dropped objects, etc. created in the pub.

I also tired a close file action using the wildcard, to preface the delete file wildcard action, with no better success.

This was tried on a set of files created in an earlier preview of the pub and didn't involve ones created in the same preview as when the close and delete actions were tried, so I'm unsure if they were open or not.

By the way, is the wildcard, in and of itself, safe to use in the pub, as long as the pathname is accurate?

Any solutions will be appreciated.

Thanks.

Stephen

By the way, is the wildcard, in and of itself, safe to use in the pub, as long as the pathname is accurate?

Well, yes considering that it doesn't work with delete file
(BTW I tested this extensively, and your right it doesn't work)

It's good that all the files are created by the pub because
that gives you a couple of options.

The first (recommended) is that the pub makes a list of the files
it creates, and then use it with a simple loop to delete the files.

The following code assumes the path\file your writing to is stored
in the variable <file_path>

insert this code before your write action

//====================
if(!FileExists(file_path))
{
var list = OpenFile("list.txt")
list.WriteLine(file_path)
list.Close()
}
//====================

When it's time to delete the files, this code

//====================
var list = OpenFile("list.txt")
while(!list.EndOfFile())
{
var delfile = list.ReadLine()
DeleteFile(delfile)
}
list.Close()
//====================

Your second option is to have DOS do your file deletes
for you. (Here's where it gets dangerous )

I'll go into that with you via email if necessary

Cheers
Chris

Hi Chris

Thanks for your assistance.

I guess it wasn't my limited skills failing to get the delete file wildcard action to work.

The scripting you suggested promises to solve the issue.

There is one pub created .txt file, containing the viewer-created password, which goes to a separate SYSTEM_DOCUMENTS_DIR folder, that shouldn't be deleted. Is there anyway to change the script so that this one file is not deleted when all the others are?

Again, thanks for your help.

Kind Regards,
Stephen

Hi Chris,

I posted a sample DOS batch file (using 'deltree') hoping to help Stephen in another thread that he mentioned. Indeed it does get dangerous!! I advised of caution -- I was wondering if this alternative solution method was used, that maybe to get Opus to rename the extension .BAT, to something meaningless, to stop a user inadvertantly browsing windows explorer and clicking on the BAT file....ooops!! (just before the actually batch file is called, Opus renames it to 'BAT', then changes it again after use.)

I never knew the Opus Delete File wildcard did not work. Maybe DW could fix it to only work for script, to safeguard inexperienced users perhaps?

Chris, your script example looking cleverly interesting.


STEPHEN:
I'm s sure Chris will come up with something, as the file you suggest is in a different folder.

Thanks Steve for weighing in. Hopefully DW will take a look at the wildcard issue for the delete file action, make a repair, following your suggestions.

Chris:

In the meanwhile, I did try the script provided, unfortunately without success. This may be due to the way the pub is structured to save the folders/files I'd like to set up a delete for:

The diagram maker creates the initial folder (efolderaaa) in SYSTEM_DOCUMENTS_DIR and places a large number of .txt files in it, representing positions, object states, etc for drag and dropped objects in the diagram. This, so they can be reset upon returning to the diagram page.

I've already set up a delete file action for every .txt file in this folder SYSTEM_DOCUMENTS_DIR\efolderaaa\ (alot of work, but now completed).

What I also did, to give viewers extra folder storage, was set up 5 actions on a separate "file manager" page to copy whatever .txt files are currently loaded (efolderaaa) into one of 5 storage folders in SYSTEM_DOCUMENTS_DIR called efoldervvv, efolderwww, efolderxxx, efolderyyy and efolderzzz. Each has an action to reverse the process, allowing the viewer to re-copy .txt. files back to efolderaaa for current reset/viewing. (Unfortunately, this means that all .txt files are first written into efolderaaa, then copied, re-copied back and forth.)

So, the viewer can create a diagram, save in efolderaaa, transfer efolderaaa .txt files to efoldervvv, etc., re-use efolderaaa (either delete all files or overwrite them), store the next file contents in efolderwww, etc. Awkward as it is, this was the only way I could think of to add storage capacity.

Since efolderaaa is already set up for delete, I need now to set up delete actions for the .txt file contents of each of the 5 additional folders vvv through zzz. This, hopefully without needing to set up a separate delete file action for each folder with perhaps 200 .txt files in it.

So, you can imagine that the wildcard for delete, if it could be safely added and only affect the correct pathnamed folder, would be a simple solution (I used the same wildcard for the copy, re-copy back and forth actions for vvv through zzz, and they work OK.)

I remain hopeful that a simple, safe solution can be found.

Again, thanks for your help.

Kind Regards,
Stephen