Greetings,

We have been having some confusion with the functionality of "delete" in the MRE licensed product. Over the years, it seems the functionality has flip-flopped between a "true" delete (where it deletes from the domain tree and deletes the fex from the filesystem) and a "lazy" delete (where it just deletes from the domain tree but leaves the fex out in the filesystem). This flip-flop seems based on the version and based on platform. Here is our experience:

4.3.x Windows - lazy delete
5.3.x Windows - true delete
7.6.x Windows - lazy delete
7.6.x Linux - true delete

We opened up a case on this inconsistency, and have recently been told that "lazy" delete is the intended functionality of the product, and that our Linux version is "broken". This absolutely astounds us, as "lazy" delete leaves scores of fexes in a domain out cluttering up the filesystem, and no utility exists to clean up the junk, instead administrators have to manually examine user.htm and {domain}.htm to trace down the "lazy" deletes. It creates real headaches for us.

For those that have licensed MRE -- what is your experience? Does a delete result in a true delete or a lazy delete in your version/platform? Do you prefer it this way?

Thanks in advance for your time.

-- Dan
University of Nebraska at Omaha

My "delete" really deletes, as I would expect it to.

I have noticed this as well. In previous versions, it did not delete, but simple put "disabled" as one of the MRFLAGS in the domain's HTM file. Currently (7.1.6 on Linux), when we delete, it's gone.

So if a true delete means that it's broken, it's apparently broken for a lot of customers. And personally, I would like it to stay "broken." Problem will be when they "fix" it without telling anybody.

quote:

Problem will be when they "fix" it without telling anybody

... and then "unfix" it in the next release

T

rigel7,
i've only seen true deletes.
Are you in Domain Builder?
If you look at the .htm at the root level of the domain you're in (you'll have to go to the server itself to look in the basedir for your domain's directory ), and do a test delete,
what happens to the fexname in that .htm?
Is it just commented out so that it doesn't show? Mine vanish.
If you look within the /apps directory of that domain, does the fex vanish?

I vaguely (and i mean vaguely) remember some such behaviour in the distant past, but it may have been a dev stu thing. Since 52, i've not seen this 'lazy' delete, and i'm in 764 now. all windows.
good heavens this must be making you crazy.

Susannah,

This is what is making me crazy:

After reading your entry about true deletes on a Windows 2003 7.6.4 environment, I went back to our W2K3 7.6.x server and tested it by creating a new fex in MRE, then deleting the fex through MRE. Sure enough, it deleted the fex from the app/ directory.

Gazooks. Are our developers who reported the problem insane? Is IBI tech support who told us that "lazy delete" was the MRE design standard insane?

I decided to do extensive testing, and discovered a pattern. New fexes that were created on our W2K3 server have true deletes. Old fexes that were migrated on the domain tree from 5.3.6 result in lazy deletes -- the entry was removed from {domainname}.htm, but left out in the app/ directory. So our developers are NOT insane. -whew-

I tested it for permission issue by shooting a -DOS del command through and received this fun error:

d:\ibi\webfocus76\basedir\unotechs\app\mark436.fex
The process cannot access the file because it is being used by another process.

Great, something's got a hold of it. I can't tell if it is a cascade from a bug on the previous delete through MRE (crashed agent or pid), if it's the servlet container (Tomcat) who has it, or some other gremlin in the Windows world. This is why I prefer Unix, less "mysteries" and better diagnostic tools ('lsof' is my friend).

But it appears that IBI tech support is insane, as they are telling us that the design of the MRE product in the 7.6.x branch is to leave the file out in the filesystem.

Argh -> Dan at UNO

I followed a private suggestion to escalate this issue to one of the IBI supervisors in e-mail, which I did, and gave the two case references and a pointer to this Focal point thread.

The response (included) still has me awestruck. The product as designed is intended to be "lazy" deletion (leaves the fex out in the filesystem), in spite of your experience and preference. If I pursue the case, and it is reproduced in-house, then it will be fixed in the direction of "lazy" delete.

Needless to say, I will NOT pursue this and instead request that the case be close -- we'll live with the bug. But be advised, all fans of "true" delete -- your voices have been drowned out by the customers who have complained that their MRE users didn't really mean to delete a fex. "Lazy" delete is the standard, and unless an alternate view lobby is put forth, any "bugs" encountered will be to correct it for "lazy" deletes.

Dan at UNO

-------------- case #40592560
Daniel,
I've spoken with one of my supervisors, and we found your thread on Focal
Point.

There are two things here.

1-
On your new discovery regarding your windows environment, and new/old files.
We would like to try and reproduce this in house. To do this we will need you
to zip up your entire basedir and upload it to our FTP.

2-
However, if we are able to reproduce this in house, any fix related to it would
be a fix that enforces a lazy deletion policy across the board.

Please let me know how you would like to proceed.

omg i'm staggered. completely dumbstruck.

As of WebFOCUS 5.2 the expected behavior is that the focexec is "deleted" from both MR and Disk. We did have a bug in 5.2.1 and 5.2.2 whereby the deletion occurred partially, that issue was resolved as of WebFOCUS 5.2.3

On Unix/Linux based environments, occasionally we do see files that remain on disk primarily due to permissions.

Now that exactly contradicts what was given in response to Dan's case. Apparently IB Support and the IBI supervisor Dan corresponded with are not communicating. Which is the correct answer (now and moving forward)?

Customer Support Services will be contacting Dan to resolve the confusion.

The expected result is that with any release of WebFOCUS 5.2.3 and higher when a DELETE occurs it's removed from both MR and DISK.

well, holy cow, guess what! we're in 765 on unix
as of today, and the domain deletes are indeedSOFT.
here's the proof, the line from the mrrepos.htm

[li]<A HREF='dschoolm/dschoolm.htm' NAME='School of Medicine' MRFLAG='disabled' School of Medicine</A>
[li]<A HREF='untitled/untitled.htm'>Default Domain</A>

"what a revoltn development this is"
(ok who's old enuf to know what tv show that came from?)

The Honeymooners.

Boy, I am REALLY old!!!!

way to go GJ!

7.6.5: hard delete!

in windows, but not in unix
and we've got all the permissions set properly
and we've had ibi look at it.
we're screwed.

Susannah --

WF 7.6.5 Linux x86 platform gives hard delete with both migrated and fresh MRE entries. The interface tested was through BID under both Standard reports and Custom reports. The 7.6.5 was an upgrade install from 7.6.4, so I don't know if a fresh install makes a difference. I did, however, perform a fresh MRE migration from our production environment, so it wasn't just an inline upgrade of the MRE tested.

I relate to your frustration. Our windows WF administrator submitted traces on the previous case and IBI concluded it was sucessfully deleting only 80% of the time.

I really think IBI needs to get a handle on their code base instead of focusing on trotting out new feature after new feature. We have 16 bug reports dating back to 2004 that are in the nebulous "In Product Division" state, with no hope of ever seeing them fixed. Some bugs seem quite trivial like the SAME_DB feature that breaks because of hardcoded page numbers (1 PAGE 1 - see My 400th Post (finally) and SAME_DB ).

Between the unfixed bug reports and the outrageous licensing policy for deployment under virtual machine usage (licensed based on the total number of processor capacity of the VM instead of the logical processor capacity dedicated for the instance), IBI is going to push its customer base away. It's happening to us, and I don't say that to try to whine or give bad attitude, it's just a fact that needs to be shared with the community and understood by the vendor.

Dan at UNO

University of Nebraska at Omaha
Prod- WF 7.6.4 Linux MRE/BID/DataMigrator Test-WF 7.6.5 Linux MRE/BID/DataMigrator

Dan, agreed.