nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Slow File Deletion

DanBCBSM

Deleting a file from STAGING is very slow. First we delete the file from the workarea, then List Modified, then select the file and Submit Direct. It takes about 5 minutes to delete the single file from staging! We just upgraded to Teamsite 5.5. Any suggestions?

Find more posts tagged with

Comments

gwen1

System particulars?

Is this consistant? Behavior occurs in all workareas/directories, etc.? Do you have a large amount of files in the directory that were modified? Does submit of a modified file, following the same process take a similar amount of time? Is the request to delete making it to teamsite or is there delay sending from the browser? I would also recommend looking at iwstat -c results while this behavior is ongoing. If there is an issue with the iwserver process, would see the Submit taking many seconds.

Gwen

DanBCBSM

Yes, this problem is consistent. I'm thing that there is a delay sending information from the browser. We've tried from both Windows 98 and NT.

What could cause a delay in sending info from browser for this one particular request?

Thanks!

gwen1

We had a similar type issue when publishers were submitting, delay we determined was due to the sheer number of files in the directory. The publishers had as their view to show all files in that directory before checking the one wanted and there were over 1000 files in the directory. Our solution was for the publishers to keep the default limits (100 per page) in their view and they are splitting the directories up.

Do you have a lot of modified files on the list? If so, does the problem improve in a directory where there is only one modified file? Is this in webdesk or webdesk pro?

Gwen

GV_SORT.zip

GV_SORT.pdf

DanBCBSM

Thanks.

We have 4000 modified files in one workarea, because we just upgraded to Teamsite 5.5.2 and a lot of the owners and permissions have changed. So that's probably part of the problem. Funny thing is that we can delete the files from STAGING using the iwsubmit command and it works instantaneously. This is in webdeskpro by the way.

I see another discussion here about "list modified" being very slow, and ways to reduce the number of modified files by synchronizing those where only the owner and permissions are different. We'll check into that.

Thanks!

gwen1

That would be consistent with our findings. It is an IE behavior we believe, as the request in our case was slow being sent to TeamSite. Took a minute or two to even send the submit command.

Migrateduser

We've had the same problems - a large number files causes a big slow-down.

Migrateduser

I asked around in engineering and was given the same answer that David gave. The number of files is the key factor in this time delay.

lissa

mgal

One main issue is list modified does not show the files in multiple pages while the normal workarea view does. So the the Submit GUI takes some time to show up. A bug is filed for this issue

DanBCBSM

We solved this problem solved with the help of a perl script posted here on DevNet. Thanks to all who contributed here.

Basically the script works as follows:
1. List Modified. We had about 3000 files.
2. For each list modified, run iwdiff. If the resulting line contains the word "identical", then assume that the files in workarea and staging are identical except for ownership and/or permission.
3. For each "identical" file, submit to staging.

Using this technique, our list modified went from over 3000 to less than 400 files. The time to submit direct for a modified file is down from 5 minutes plus to under 10 seconds.

If anybody is interested, we will post our customized version of the perl script here...

mika

Even if you have a huge list modified (e.g. 9,000 files like I experienced today), you can delete files quickly by doing the following:

1. Start a new workflow job.
2. Add the file you want to delete to the job.
3. Rename the file within the job -- for example, "default.asp" to "default_delete.asp"
4. This leaves both the deletion (because of the renaming) and the newly named file in the job.
5. Leave the deletion in the job.
6. Remove the newly named file from the job
7. Submit the job.
8. Go back into your workarea and delete the renamed file.

SLAN.FT.SLAN01.X151405.G0032V00_RevBJORN_DevSample.zip

Adam Stoller

Why are you going through the extra step of a rename and a subsequent deletion of the renamed file?

--fish
(Interwoven Senior Technical Consultant)

Bar_chart_sample.bmp

mika

I devised this long workaround because it took me close to 20 minutes to submit a deletion from the list modified view if there were 9,000 modified files.

Basically, I'm skipping the list modified view entirely in the workaround, and instead, starting the job first -- and the only way I've figured out to get a deletion into a job is to put the file into the job and rename it.

Maybe I'm missing something -- is there some way I can add deleted files to a job after the job has already been started?

Adam Stoller

You could probably just use an externaltask that runs through the list of files and unlink()'s them in the workarea prior to submission.

--fish
(Interwoven Senior Technical Consultant)

SLAN_XML_OnlineBatchTest_173832_20121101.pdf

emily

Hi Dan,
I know it's been a year since you posted this but I am interested in your perl script if you still have it. We are experiencing the same slow times that you were.
Thanks.

Graph.zip

GraphGraph.pdf

DanBCBSM

Attached is the Perl script....

emily

Dan - Thanks much!