Skip to main content
1-Visitor
June 30, 2010
Question

AE 5.4 M150 ties up directory of last file edited

  • June 30, 2010
  • 11 replies
  • 1537 views
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

    11 replies

    1-Visitor
    June 30, 2010
    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


    1-Visitor
    June 30, 2010
    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.
    1-Visitor
    June 30, 2010
    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 🙂


    1-Visitor
    June 30, 2010
    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.
    1-Visitor
    June 30, 2010
    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 🙂


    1-Visitor
    June 30, 2010
    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.
    1-Visitor
    June 30, 2010
    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 🙂


    1-Visitor
    July 1, 2010

    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

    1-Visitor
    July 1, 2010
    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
    1-Visitor
    July 1, 2010
    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