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; } } }

Deleting a from STAGING

brocktune

I have a directory that has been submitted to STAGING, but now needs to be deleted. I've deleted it from the WORKAREA, submitted the delete, said to overwrite exitsting, and the folder is still exists in STAGING. I checked the permissions on the folder and it is rwxr-xrwx. How can I remove it from STAGING?

Find more posts tagged with

Comments

Adam Stoller

Are you sure you submitted the deletion to staging?
Are you sure you're looking at the same file in staging as you deleted in your workarea?
Also - what version of TeamSite (including SPs and patches) on what platform?

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

brocktune

TeamSite version: 6.1
OS: Solaris 8

Migrateduser

Did you not receive errors when you tried to "override conflicts in staging" and presumbably failed? It's extremely unlikely that TS would be quiet about submitting files / directories to staging without it working.

Provide screenshots, if possible.

Dave

Current Environment(s):
(1) TS 6.1 SP1 on W2K3
(2) TS 6.1 SP1 on W2K
(3) TS 5.5.2 SP2 on Win2K

brocktune

No it didn't show any sort of error message.

I deleted the folder from the WORKAREA.

Selected the folder, which exists in STAGING.

Clicked submit, override conflicts.

It runs without any errors, but the folder remains in STAGING.

I'm logged in as Admin and am the owner of the folder.

Migrateduser

Sorry to ask something so obvious, but when you submitted the Deleted folder from the workarea, did it have the visual indication of a deleted asset (i.e. the "X" through the little icon)?

Dave

Current Environment(s):
(1) TS 6.1 SP1 on W2K3
(2) TS 6.1 SP1 on W2K
(3) TS 5.5.2 SP2 on Win2K

brocktune

Yeah, it's there.

Migrateduser

Nothing stands out to me -- it's particularly troubling that TS did not pop up with an error message when submitting to staging with the override option checked. This is a last resort for us Devnet old-timers, but you might just need to call support on this one, unless, of course, someone else can suggest something.

Dave

Current Environment(s):
(1) TS 6.1 SP1 on W2K3
(2) TS 6.1 SP1 on W2K
(3) TS 5.5.2 SP2 on Win2K

reddyl

I have noticed this if there are any files under the deleted folder then you need to submit the deleted files before deleting the folder.

Adam Stoller

deleted the folder from the WORKAREA.

Selected the folder, which exists in STAGING.

Clicked submit, override conflicts.

Uhm - that second step - were you IN staging when you selected it and did a submit??? You have to be in the Workarea - and select the deleted folder.
Also - what submit workflow are you using? An OOTB one or a custom one? In either case, it's possible that the workflow doesn't understand what to do with the no-longer-existing file that is associated with it and that's why the submission isn't really going through.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

brocktune

Yes, I was in the WORKAREA when I submitted the delete.

I'm using the default workflow.

NathansDIS

Have you checked for any pending jobs in the workflow tab of the UI? I found that often a submit task for a deleted folder would hang in TeamSite 6.1 asking you to 'resolve conflicts.' I thought I saw someone on devnet say that this will be fixed via changes to the submit logic in TS 6.5. Hope this helps.

-Nathan
Washington State DIS

brocktune

Yeah, there aren't any jobs pending at this point.

NathansDIS

I assume you have tried doing a get latest to bring the deleted folder back into the workarea and tried again?

brocktune

Sorry to keep bothering you with this issue, but I was looking at this further and found this error in the comments section of the task details:

---> Checked out files prevent submitting [iwadmin: 12/13/04 3:47:08 PM ]

There aren't any other users on the system, right now and there aren't any locked files. Any advice would be appreciated.

Thanks.

Adam Stoller

What happens if you run the CLT: iwlistmod /vpath/to/branch/WORKAREA/workareaname?
What happens if you run the CLT: iwlistlocks /vpath/to/branch

(feel free to stip away anything that does NOT include the directory you are trying to delete/submit within the output - we're looking for data that comes back that *does* contain the directory name you are trying to delete/submit)

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

cemman01

I kept getting the same issue a few months earlier but later realized that the files to be deleted were locked out in other workareas, which kept giving the error "Files Checked Out in other area".

I unlocked all the files and was then able to submit the deleted folder successfully. It is not a submit workflow issue but more a Teamsite issue where it thinks that if a folder with files is being deleted in one workarea but locked out in another workareas, this means that the files are still in use by others and prevents the deletion.

Ghoti's reply about determing locked files in for a branch level can help determine which files under the folder being deleted are locked.

DavidMusser

Was this issues ever corrected? I have the same issue in TS 6.5 on Windows 2000 SP4.

If I do a submit in the GUI it prompts me to keep/overwriet/or get latest. I have tried a mixture of them all and I am still not able to submit a deleted directory. This directory contained sub directories and I even tried to delete each of those directories one at a time with no success.

If I submit via a command line I get the following as well:

main/Test/WORKAREA/test: ERROR:02017: Checked out files prevent submitting

I also tried the the listmod and list locks...

iwlistmod main/Test/WORKAREA/test
x+ htdocs

iwlistlocks did not return anything.

Any ideas?

Johnny

You need to try this from the branch level

main/Test

as it may be locked in another workarea.

I have still had problems with these tools not indicating a lock with deleted files. This mean I had to explicitly recreate the directory/files and then issue an unlock.

John Cuiuli

DavidMusser

I did try it from a branch level as well, and it did not help.

I only have one workarea for this branch. This is a new installation so I had started with a new store, and had not created any other areas yet.

-D

DanBCBSM

"I have noticed this if there are any files under the deleted folder then you need to submit the deleted files before deleting the folder." [reddyl]

We noticed the same thing. We are deleting using a workflow with a submittask. There are some submittask attributes that look like they should take care of this situation -- i.e. override="t" skipconflict="t" skiplocked="t" -- but these only work when deleting specific files. When a deleting a directory, there is no way to tell the submittask to skip locks on files underneath that directory.

Dan & Jason
Blue Cross Michigan
TS 6.1, Solaris 8

NathansDIS

We have seen this with 6.1 on windows as well. What we have to do to correct this is end the job in conflict, do a get latest into the workarea, unlock the files in the directory and resubmit (with the submittask attributes as mentioned above.) Hope this helps.

-n

heredite

I have the same problem and i'm not able to correct this one too. I've try everything that is posted here.

Pascal

gzevin

I have written a lot about this..

The issue is that there could be some locked file in editions, and not in staging.

In one case the problem was so severe I had to re-create a branch to get the users on track.

Interwoven engineering has even sent me a script to fix some of the stuff, but it;s not documented or supported, I did not have time to try it, though....

Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU

Adam Stoller

This appears to be fixed in 6.5 SP1

54441 Can not submit a deleted folder that contains a locked file. --fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com