How to retrieve the owner of a Lock ?

Hello,
Just by curiosity, I would like to know if it's possible to retrieve the owner of a Lock on AOS4.

By Locking each Volumes in the DosList, I retrieve each Lock (struct FileLock).

But is it possible to retrieve the FileHandle of a Locked file to show the fh_OpenerPID ?

struct FileHandle
{
...
uint32 fh_OpenerPID; /* The process ID of the opener. V52.16 */
...
}

Or another way to retrieve the owner of a Lock ?


Thank by advance for your reply.

Quote:

If you lock the volume, then you are the owner of the lock.

Each call to Lock() creates a new lock and each call to Open() or OpenFromLock() creates a new file handle. The respecive caller is the owner of each.

You have to retrieve the pointer of an existing file handle or lock in order to examine it and perhaps find out its owner (if this is possible at all).

Thank you Thomas,
Yes it's my problem,
is it possible to retrieve a fileHandle ?

AFAIR locks are BPTRs to a private structure allocated by the filesystem. If it is possible to find out the owner, that would depend on the filesystem.

You don't get a FileHandle until a file has actually been opened. If you trick it and do an OpenFromLock() on another process' lock, chances are your own process ID will end up in fh_OpenerPID.

Having just checked, I was wrong.

The lock is a BPTR to a FileLock structure (defined in dos/dosextens.h). However, there's nothing in that structure which will help you. Note that fl_Key, despite what the header says, is actually a filesystem private field. It is possible (but unlikely) that the filesystem (or dos.library) holds the locking process ID in one of the private fields, but even if it does that would be dangerous to rely on and/or filesystem specific.

Thank you Chris,
I have to forget this idea.

Thank a lot for your clarifications :)

The filesystem does not need to know the owner of a Lock, only DOS does. As Chris says, I don't think it's possible without "inside" information.

The best you can do to find out which process called Open(), the filehandle will indicate this in the filehandle->fh_OpenerPID, use this in conjunction with the IDOS->ProcessScan() function.

However, as Chris has mentioned above, the fh_OpenerPID is the openers pid, nothing more, and if that filehandle is passed into (for example) CreateNewProcess() or System() and a new process is using it, you won't know.

So, what exactly are you trying to do, and why do you need this information, there may be a better way to do it.

It's probably for his monitor Sysmon on OS4depot.
For debugging purposes it would be great to display all locked files and which program is locking them.

Yes, Elwood, it was for my SysMon.

I have the list of FileLocks but I wanted just to add the owners of these locking resources to hope to know which process to stop to free a lock.

Nothing important, it was just for information purposes.

I see in the today dos.library update that a new function
FileHandleScan() is implemented.

Is it something that could help me to find the owner of a Lock ?

If yes, I will have to wait a new SDK, true ?

Thank you, by advance, for your reply

@zzd10h

Quote:

I very much doubt that there is as it's possible for filesystems (and some do) to return the same lock for every access to the same filesystem object. An advantage of this is that it makes implementing ACTION_SAME_LOCK very easy since you just have to check if the pointers are the same.

Some filesystems may have a file handle pointer stored in the lock but in that case how and where in the structure it's stored is filesystem dependant and can't be relied upon.

@salass00
Thank you for reply,
But what is this new function FileHandleScan() ?

@zzd10h

You'll find out soon, very soon....

@colinw

great !

Even Greater:

http://blog.hyperion-entertainment.biz/?p=1001

At last! Thanks Steve et al.

Ooooh, proper dospacket documentation at last, thanks!

@colinw
So what does FileHandleScan do? (For us not near an Amiga, or at least not with time to download & install the SDK right away.)

@ChrisH
Well, the name is pretty-well self-explanatory.

But it's probably not of much use for the casual programmer,
it's mainly for diagnostic/monitor tools and for the USB stack to
determine how many open files are still open on a given volume,
so it doesn't try to pull the rug out from underneath the filesystem
when someone wants to "safely" remove a USB stick or such like.

Previously there was no system-friendly way to determine how
many files were still open on any given volume, now it's easy.