Opened 3 months ago

Closed 3 months ago

#440 closed bug (fixed)

Dangling directory locks when MUI first started

Reported by: Mike Steed Owned by: Thore Böckelmann
Priority: normal Milestone: 5.0-2020R1
Component: muimaster.library Version: 5.0-2019R4
Severity: minor Keywords:
Cc: OS Platform: AmigaOS4
Blocked By: Blocking:
Release Notes:

Description

Summary

When the first MUI application is started following bootup, it leaves
dangling locks on its home directory when the application is later quit,
which prevent the directory from being deleted. I don't know if this is
a bug or just an aspect of MUI operation. If the latter, it's easily
mistaken for a bug.

The scenario is that someone downloads an archive and unpacks it onto
the RAM disk in order to evaluate the program. Whether they decide to
keep it or not, they eventually will want to delete the drawer on the
RAM disk. When they are unable to, it leaves a poor impression as to
the quality of the program.

Steps to reproduce

  1. Start with a freshly-booted system, with no MUI applications running.
  1. Open the MUI drawer and drag the Demos drawer to the RAM Disk. Open

the Demos drawer on the RAM Disk.

  1. Run one of the demo programs. It doesn't seem to matter which one-

try Aboutbox. Immediately quit the program.

  1. Close the Demos drawer and try to delete it.

Expected results

The drawer should be deleted.

Actual results

DOS throws an "Object in use" error, and the drawer is not deleted
(though all of its contents are).

Running Scout shows two locks remaining on the Demos drawer, which
is what prevents it from being deleted.

Notes

The dangling locks only appear the first time a MUI application is run
after booting. Running that demo or another afterwards does not add
any additional locks.

If Scout — itself a MUI application — is run prior to running a demo
program, then everything works fine- there are no dangling locks, and
the Demos drawer can be deleted. Of course, Scout's home directory may
then get the dangling locks, but there's no easy way to tell.

Some MUI applications seem to get dangling locks the first time they
are run, even if other MUI applications have been run previously. My
current project is one. YAM (the latest nightly build) seems to be
another. Both programs use TextEditor.mcc, which makes me suspicious.

Indeed, running the TextEditor demo program, even after running one
of the MUI demos, leaves two dangling locks on its home directory.
So using TextEditor.mcc (perhaps any disk-based custom class?) the
first time after booting seems to generate the dangling locks, too.

This issue has some similarities to ticket 200, and running FlushMUI
does clear the locks and allow the drawer to be deleted. But why
would MUI need to keep locks on the program's directory, and not
any of its contents?

Change History (4)

comment:1 Changed 3 months ago by Thore Böckelmann

As far as I can see by a first rough scan through the source code muimaster.library is not calling Lock() without the accomanying call of UnLock(). Neither does TextEditor.mcc do anything similar or fails to do so.

However, running SnoopDOS in parallel to starting the first MUI application from a Shell reveals that the Shell itself makes a Lock() call to the application's directory. The same happens via a start from Workbench/DOpus.

Only flushing muimaster.library from memory makes the pending lock to be UnLock()'ed.

To make it short: right now I have no clue what might be causing this pending lock. Everything points to MUI, but the source code does not exhibit an explicit call of Lock() which might cause this.

comment:2 Changed 3 months ago by Thore Böckelmann

Milestone: future release5.0-2020R1
Owner: set to Thore Böckelmann
Priority: undecidednormal
Status: newassigned

Oh, wait! MUI starts several processes, like the Imagespace and Screenspace process. These processes inherit the current directory of the parent process and will UnLock() that one upon exit. But these processes are 'MUI global' and will be terminated only when muimaster.library is flushed from memory.

When the first started MUI application resides in 'MUI:Demos' then the lock will be done for that directory and will prevent it from being deleted. If the first MUI application is MUI prefs then "MUI:" will be locked and running any further application will NOT lock the corresponding directory.

So the culprit is the call of CreateNewProc() and not any explicit call of Lock().

I will see what I can do about that.

comment:3 Changed 3 months ago by Thore Böckelmann

The same of course applies for NList and TextEditor as well, which spawn a global clipboard server process.

comment:4 Changed 3 months ago by Thore Böckelmann

Resolution: fixed
Status: assignedclosed

In 6561:

  • Process.c: CreateNewProc() sets the parent process' current directoy as default "CURRDIR:" and "PROGDIR:" for the new process and hence locks these directories. Is essence this means that the directory of the first started MUI application is locked permanently until muimaster.library is eventually flushed from memory and terminates its Imagespace process. The workaround is to let CURRDIR: and PROGDIR: of such processes default to MUI: instead. This closes #440.
Note: See TracTickets for help on using tickets.