AE 5.4 M150 ties up directory of last file edited

[ptc-953926]

Adepters:

Another problem in our move to AE 5.4 M150. If an author makes some edits and closes the document - but leaves the editor open, the folder containing the edited document cannot be deleted unless AE is closed entirely. This causes problems for our CMS when the document is checked in as it automatically removes the checkout folder. There have also been reports that the document is tied up, even though it was closed and a checkin fails completely (I haven't reproduced that problem, however).

Are there any tricks we can use to get AE to release the directory when a document is closed? Restarting AE is not a good option as the author may have several windows open.

Dave

[AndyEsslinger]

I've seen that with other programs. Is killing the editor process an option
for you?



-Andy

\ / Andy Esslinger LM Aero Tech Order Data

_____-/\-_____ (817) 279-0442 1 Lockheed Blvd MZ 4285

\_\/_/ (817) 777-3047 Fort Worth, TX 76108

[ptc-953926]

No, not really as the author may be editing several documents and just wants to check in one. This is a regression from AE 5.2 M130, as we never had the problem before. Beginning to sound like a PTC call.

[bibach]

Hi, Dave...

Just a shot in the dark, but maybe the directory is locked because it
is still Editor's "current directory". After closing the document,
try bringing up the "open file" dialog, navigate out of the directory,
but cancel the dialog without selecting a file. This might be enough
to get Editor to release the directory.

-Brandon 🙂

[ptc-953926]

Nope. Nice idea, though. When I bring up the "open file" dialog, it's pointing to "My Documents" (another beef I have -- even TextPad opens in the current directory). I even tried what you said, but it still clings to the directory.

[bibach]

Ok, same procedure, with a twist. After switching to another
directory (even just typing ".." and hitting enter to jump up one
level), but while the dialog is still open, remove the directory, then
cancel the dialog (hitting Esc should do it).

-Brandon 🙂

[ptc-953926]

Well, that actually worked! Not that I'd want my 100 authors to remember to do that each time they were done with a document. I can pass it along as a workaround. I've opened a call for the overall problem with PTC.

[bibach]

Indeed, this is only the most basic workaround and not one you'd want
to incorporate as a regular practice.

However, if a more comprehensive solution is not immediately
forthcoming, you might try something like the following in your
instance.acl or similar location. This checks to see if Editor's
current working directory has the string "test" within the last 6
characters and, if so, moves up one level. You'll want to replace
that check with something suitable to determine if the directory is
one that you don't want Editor to "linger" in.

function leaveDir(doc)
{
local d = pwd();
if (rindex(d, "test") > length(d) - 6) { cd .. }
}
doc_add_callback(current_doc(), 'destroy', 'leaveDir')

-Brandon 🙂

[BobSpangenburg]

Dave,

Although this behavior may not be desireable in your scenario, it is a standard behavior within Windows. Any program that opens up a folder will have a tie to that folder behind the scenes within Windows. Windows will not let go of the folder unless you break that tie by either closing the program or telling the program to change its "current folder." The most basic programs (like NotePad or TextPad) behave the same way. I can't count how many times I've been working around my system and think I'm ready to move a folder or file and Windows yells at me saying that it can't do it, only to find out I forgot to close TextPad, even though I've save and closed the file I had open.

I don't believe you'll get a "fix" from PTC as I don't believe this is broken. As our collegues have mentioned, you need to go to another folder and open a document in that folder, or simly close AE. If you look at Help => About Arbortext Editor => Session, you can seen in "Working Directory" the current folder you're locking.

Hope this helps,

Bob

[ptc-953926]

Well, I'd have to disagree. The author closes the document and that should sever any tie to the associated directory. The fact that this wasn't/isn't a problem in AE 5.2 suggests that it is a regression. It also throws a huge wrench into our CMS tools that need to remove the checkout directory as part of checking in a document.

Dave

[steve.thompson4]

Got intrigued by this, since we use 5.2, so did a quick test. Found something interesting, that may or may not bear on the situation.

When it first opens, AE 5.2 shows the working directory (on my machine, at least) as the Desktop. Drag and drop an XML file into the window from some other folder, and that "working" directory does not change. Use File+something to "Open" a file, and it does change to the location of the file.

Until that "working" directory setting changes, the file's parent directory is subject to deletion. Is it possible there is something in the way the files are loaded into your AE sessions that allowed the "working" directory to remain unchanged in 5.2? And, that what has changed in 5.3 is not the locking, but the accuracy of what the current "working" directory is? The locking being a byproduct of that more-accurate directory setting.

Mostly thinking out loud...
Steve Thompson
+1(316)977-0515

[mfiero]

In Reply to Dave Hintz:

We encountered the same problem about a year ago when testing AE 5.4 in our CMS environment. PTC provided me with a diagnostic ACL file called doc_close2. We ended up being able to solve the problem by replacing the code we used to use to close the file in the editor's checkout directory. The old file closing code was:

if(doc_window(doc) > 0) { file_close( doc_window(doc) ); }

Now instead of file_close, we call a new ACL file:

if(doc_window(doc) > 0) {doc_close_unlock(doc); }

Here is doc_close_unlock.acl:

#### Routine adapted from PTC's diagnostic routine; need to close and unlock the XML file upon check-in or ###
#### cancel check-in, in order for java to be able to remove the file from the checkout folder ###############

function doc_close_unlock(doc = current_doc()) {

local path = doc_path(doc);
if (!path)
{
message = "Document id $doc has no associated path. Document not closed!\n\n";

}
else
{
local count = 0;

while (doc_valid(doc))
{
#doc_close(doc);
file_close( doc_window(doc));
}

local dobj = dobj_construct(path);
if (dobj_valid(dobj))
{
if (dobj_is_my_lock(dobj))
{
#message .= "\n\nDocument is still locked by some document object; even after closing";
# Forcibly close this reference.
dobj_unlock(dobj);
}

# Release the dobj we created above.
dobj_close(dobj);
}

}

}

Not sure if this will work for you, but hopefully it is helpful.

Meghan Fiero