Anchor, the author of the Google Drive handler recently got OS4 FE Classic up and running, and started porting the handler to OS4. He already made an account here, but he is still waiting for it to be activated, so I'm forwarding his question. Like those who tried the 68k version, he is stuck with the following error:
http://fourflash.com/misc/os4.png
He asks when is a lock considered invalid?
Unlock() invalid lock object
- broadblues
- AmigaOS Core Developer
- Posts: 600
- Joined: Sat Jun 18, 2011 2:40 am
- Location: Portsmouth, UK
- Contact:
Re: Unlock() invalid lock object
When you do something like:
ie a lock that been unlocked already.
It's agood idea to always set the BPTR to 0L after UnLock() and to test for )LO before Unlocking to avoid accidental double UnLocking etc.
Code: Select all
#include <proto/dos.h>
int main(int argc, char *argv[])
{
BPTR foo;
if(foo = IDOS->Lock("T:",SHARED_LOCK))
{
IDOS->Printf("%08lx\n",foo);
IDOS->UnLock(foo);
IDOS->UnLock(foo);
}
}
It's agood idea to always set the BPTR to 0L after UnLock() and to test for )LO before Unlocking to avoid accidental double UnLocking etc.
- colinw
- AmigaOS Core Developer
- Posts: 207
- Joined: Mon Aug 15, 2011 9:20 am
- Location: Brisbane, QLD. Australia.
Re: Unlock() invalid lock object
Just incase you were wondering about specifics...
The warning is triggered when the struct Lock supplied to IDOS->UnLock() has fl_Port==NULL.
The filesystems never access their own locks fl_Port member when they unlock them,
however DOS does, it needs it to identify the handler obviously, so IDOS->UnLock() sets
fl_Port to NULL to invalidate it, this protects from the UnLock() twice problem and also
provides a stack trace if you have the kernel debuglevel >0 when someone tries to do it again.
This has been in force since DOS 52.39 (26-05-2008)
The warning is triggered when the struct Lock supplied to IDOS->UnLock() has fl_Port==NULL.
The filesystems never access their own locks fl_Port member when they unlock them,
however DOS does, it needs it to identify the handler obviously, so IDOS->UnLock() sets
fl_Port to NULL to invalidate it, this protects from the UnLock() twice problem and also
provides a stack trace if you have the kernel debuglevel >0 when someone tries to do it again.
This has been in force since DOS 52.39 (26-05-2008)
Re: Unlock() invalid lock object
The warning in question is being posted during the execution of the list command. I doubt if the list command is unlocking anything twice or we would get the warning for other devices too. It would seem that the problem originates in the Google Drive handler code. That brings up a couple of other questions:colinw wrote:Just incase you were wondering about specifics...
The warning is triggered when the struct Lock supplied to IDOS->UnLock() has fl_Port==NULL.
The filesystems never access their own locks fl_Port member when they unlock them,
however DOS does, it needs it to identify the handler obviously, so IDOS->UnLock() sets
fl_Port to NULL to invalidate it, this protects from the UnLock() twice problem and also
provides a stack trace if you have the kernel debuglevel >0 when someone tries to do it again.
This has been in force since DOS 52.39 (26-05-2008)
1. Does a filesystem handler create, alter or manipulte locks or are locks read-only for handlers?
2. If handlers are allowed to create, alter or manipulate locks, how can they do so if the lock structure is not defined (declared) anywhere in the current SDK?
AmigaOne X1000 with 2GB memory - OS4.1 FE
Re: Unlock() invalid lock object
Yes.xenic wrote:The warning in question is being posted during the execution of the list command. I doubt if the list command is unlocking anything twice or we would get the warning for other devices too. It would seem that the problem originates in the Google Drive handler code. That brings up a couple of other questions:
1. Does a filesystem handler create, alter or manipulte locks or are locks read-only for handlers?
Look for "struct Lock".2. If handlers are allowed to create, alter or manipulate locks, how can they do so if the lock structure is not defined (declared) anywhere in the current SDK?
Handlers are wholly responsible for the creation and deletion of locks, dos.library only passes the pointers backwards and forwards from ACTION_LOCATE_OBJECT and ACTION_FREE_LOCK (ok, it probably does other stuff too, but the handler will allocate and free the memory, and fill in the contents)
- tonyw
- AmigaOS Core Developer
- Posts: 1479
- Joined: Wed Mar 09, 2011 1:36 pm
- Location: Sydney, Australia
Re: Unlock() invalid lock object
There is more to it for modern file systems. DOS creates the Lock (AllocDOSObject() call) and deletes it when the Lock is released (FreeDOSObject() call).Handlers are wholly responsible for the creation and deletion of locks
The file system appends its own internal data to the DOS Lock, so that you end up with something like this:
Code: Select all
struct FSLock
{
struct Lock;
// now our own stuff
struct FSObject FSObject;
uint64 DiskAddress;
uint64 CurrentFilePosition;
(etc)
};
As Colin said earlier, only DOS may null out the fl_Port when the Lock is released by the file system (as the result of the UnLock() call).
Within limits, the file system does not know or care what DOS keeps in its Lock structure. There are some fields that the handler must fill in, but most of it is DOS private stuff, just as the handler's private stuff is unknown to DOS.
cheers
tony
tony
- salass00
- AmigaOS Core Developer
- Posts: 530
- Joined: Sat Jun 18, 2011 3:12 pm
- Location: Finland
- Contact:
Re: Unlock() invalid lock object
So is it UnLock(lock) or FreeDosObject(DOS_LOCK, lock) that sets fl_Port to NULL?
If it's the former it will cause problems for file systems that use the same lock structure for more than one "lock" on the same file system object.
If it's the former it will cause problems for file systems that use the same lock structure for more than one "lock" on the same file system object.
- tonyw
- AmigaOS Core Developer
- Posts: 1479
- Joined: Wed Mar 09, 2011 1:36 pm
- Location: Sydney, Australia
Re: Unlock() invalid lock object
UnLock(lock) calls IDOS->FreeDOSObject(lock). In freeing the Lock structure, DOS nulls out the fl_Port field just in case.
Since the DOS Lock structure is allocated from the DOS internal pool, it can still be accessed (without crashing the machine) even after release, although it may be by then a completely different structure..
Reusing an existing Lock structure for another instance sounds rather dangerous to me. Why not call DupLock() and use the new Lock?
Since the DOS Lock structure is allocated from the DOS internal pool, it can still be accessed (without crashing the machine) even after release, although it may be by then a completely different structure..
Reusing an existing Lock structure for another instance sounds rather dangerous to me. Why not call DupLock() and use the new Lock?
cheers
tony
tony
- salass00
- AmigaOS Core Developer
- Posts: 530
- Joined: Sat Jun 18, 2011 3:12 pm
- Location: Finland
- Contact:
Re: Unlock() invalid lock object
It's the file system that calls FreeDosObject() to free locks.UnLock(lock) calls IDOS->FreeDOSObject(lock). In freeing the Lock structure, DOS nulls out the fl_Port field just in case.
Not really. For shared locks you just keep a reference count and free the lock only when this reaches zero and for file handles you use a separate structure to store the current file position in and other such state data (pointer to which you store in fh_Arg1).Reusing an existing Lock structure for another instance sounds rather dangerous to me. Why not call DupLock() and use the new Lock?
It probably won't work too well if the locks are relinquished to the dos.library lock handler but for legacy file systems which don't support the ACTION_SHUTDOWN packet this isn't a problem.
Re: Unlock() invalid lock object
Sorry, I was looking for "struct FileLock" which has apparently been replaced for OS4.chris wrote: Look for "struct Lock".
Handlers are wholly responsible for the creation and deletion of locks, dos.library only passes the pointers backwards and forwards from ACTION_LOCATE_OBJECT and ACTION_FREE_LOCK (ok, it probably does other stuff too, but the handler will allocate and free the memory, and fill in the contents)
If the fl_Port is being nulled out by DOS when the filesystem calls IDOS->FreeDOSObject(lock), then it sounds like "Google Drive handler" might be freeing the lock prematurely.
AmigaOne X1000 with 2GB memory - OS4.1 FE