Lock() problem

I'm trying to determine what kind of object a path is by using either

Lock(path,SHARED_LOCK)+ExamineObjectTags(EX_fileLockInput...)

or

ExamineObjectTags(EX_StringNameInput,...)


However neither method is able to access file information for a file that was created as FOpen(.., MODE_NEWFILE) but was never FClosed().

Lock() doesn't even give me a lock.

(IoErr() gives me "object is in use")

Both diropus and workbench however is able to retrieve file information such as protection flags and file size.

I'm assuming that they don't use any of the methods I've tried.


Anyone got a tip for an airtight way to determine what type of object a path points to?

@orgin

A file which has just been created by Open or FOpen is exclusively locked and therfore cannot be accessed by anyone else. DirOpus and Workbench do not access the file but its parent directory. The directory entry has already been saved and can be accessed.

So if you Lock() the directory and read all entries with ExNext or ExAll or whatever OS 4 now offers, you'll see the file's properties.

Bye,
Thomas

@thomas

Hmm that's cumbersome. Seems ExamineObject() should be updated to allow you to get the same data as ExamineDir() can.

Ohh well, I guess I could do the following if I can't lock the file and the ioerr is not "object not found":

context=IDOS->ObtainDirContectTags(EX_StringNameInput, pathpart, EX_MatchString,filepart,...);

data=IDOS->ExamineDir(context);

@orgin

ExamineFH() can give details on open files. There should be a newer function call that does the same thing as well.

@orgin

Quote:Neither of both can work since they need an additional lock (internally) which isn't possible for files opened with an exclusive mode like MODE_NEWFILE, you have to use IDOS->ExamineObjectTags(EX_FileHandleInput, ...) instead.
Or open the file in shared mode (MODE_READWRITE). Or open it in exclusive mode but change it to shared with IDOS->ChangeMode(CHANGE_FH, file, SHARED_LOCK) after it was opened successfully.

@Chris

Nope, you can't get a handle (FOpen) of a file that is FOpened (NEWFILE)by another process that never FClosed() it.

@joerg

Nope, neither of those methods work on a file that was opened as NEWFILE by another process that never closed it.

FOpen() returns 0 regardless of mode used.

Lock() returns 0 regardless of mode used.

Neither method of ExamineObjectTags() works since they require that you either use FOpen()/Lock() first or that is can create its own lock internally.

The only way that seems to work is a ObtainDirContext()+ExamineDir() combo.

This is what I ended up doing if anyone else needs to do the same thing:

@orgin

You cannot second Lock() and exclusive lock.

If you read the docs for ExamineObject() you will
see that passing a string name implies a Lock().
That's why it fails.

If you already have the exclusive lock, just call
ExamineObject() with EX_FileLockInput, that will
work on exclusive locks as it is passed to the filesystem directly.

If you want to know the parent directory of the exclusive lock, then call ParentDir() of the exclusive lock,
and don't forget to unlock what ParentDir() returns.

@orgin
// @ToDo: Should probably parse EX_MatchString before using it, even without wildcards


I'll say, it will blow up in your face later if you don't.

@colinw

PS:
The EX_FileHandleInput also works the same way as locks
when using Examineobject().

@colinw

If you look carefully you'll notice that I was asking for an air tight way of solving the problem. I was not asking what creates a lock or not, that information is available in the autodocs.

Anyway, the ObtainDirContextTags()+ExamineDir() combo works, I just wanted to know if there was a better way to solve the problem since it's not very elegant. Way too many calls, buffers and parsing for what should be a simple task. But i guess there isn't one (yet, nudge nudge).

@orgin

The issue is that an exclusive lock implies that it is exclusive, and that means no-one else is allowed to futz-around with it.

The best you can do is get a listing of it with a directory scan of the parent directory if you do not have access to the original lock itself.

The filesystem is serious about exclusivity, and if it's not your lock, you're out of luck trying to force access from another client.

The fact that you have limited access to these is by design and not actually a fault.

BTW:
You really should first attempt a normal ExamineObject() with the string name before falling through to this fallback
method of scanning this entire directory, only if you hit a ERROR_OBJECT_IN_USE error, it will be a hell of a lot faster.

@colinw

True, here's what I use now in case someone else wants to do similar stuff.

@orgin

Just spotted something.....

The FreeDosObject() of the data block from ExamineDir()
is not appropriate in your PathTypeFallback() function.

The data blocks are allocated from a memory pool and
stored in the internal list and the whole lot is freed
when you call ReleaseDirContext().

However, as you are not looping here, you'd probably never
know anything was up.

Because ExamineDir() uses a memory pool and can reuse
the nodes on subsequent calls, if you were looping,
you'd likely be visited by the reaper for putting
it back into the pool but leaving it still in the list
without calling IExec->Remove() first.
However, seeing you only call ExamineDir() once, you got away with it.


Only ExamineObject() requires you free the data blocks individually when you're done with it.


I've just updated the autodocs to make this point much clearer.

@colinw

Example updated.

Btw on the topic of things in the autodoc, in dos.doc there is a code example that says:



(IExec?)

@orgin

Oops !! - Fixed now.

Hmmm, why it took all this time for someone to spot that one. (":/