Strange Workbench path

Hello,

I working on a dos handler. Everything is working fine.
... until i renaming a file with workbench, i got a strange
path: ' ^WB^:folder2'
It has a special meaning? folder2 is a valid directory, but the
first part is unusual. i searched for this string in the rom files,
and it is actually exist from the 2.0 os.
the action is when this path appearing: ACTION_RENAME_OBJECT

[ReadOnlyCat]

Originally Posted by anchor

Hello,

I working on a dos handler. Everything is working fine.
... until i renaming a file with workbench, i got a strange
path: ' ^WB^:folder2'
It has a special meaning? folder2 is a valid directory, but the
first part is unusual. i searched for this string in the rom files,
and it is actually exist from the 2.0 os.
the action is when this path appearing: ACTION_RENAME_OBJECT

The first thing which comes to mind is that the memory which holds the device name got overwritten by something else. If that is the case, some other data might have been overwritten too and you could expect instability issues.

Is it your handler which provides the device name?
If so, you could try to reserve some memory for it, pad it with markers left and right and see if these markers are trashed when you notice the weird string appearing for the first time.

[Toni Wilen]

Perhaps it is just a dummy place holder or to force it to be root-relative absolute path instead of relative? Perhaps relative to current directory which may not be same as source directory used in rename operation.

Does it only happen when renaming file in root directory?

It seems WB directly creates ACTION_RENAME packet because dos/Rename() should strip the ":" part out before creating the packet.

Anyway, it should not cause problems, handlers should skip possible <something>: path prefix anyway.

yes, i cutting down the part before : sign, it is fine. this prefix comes only with wb rename. im just simply dont know its purpose.
one more interesting thing: i have a worker thread which is doing file logging too. after this wb rename action, the logfile open() doesn't returns, and the thread become deadlocked.
if i renaming from cli, dopus, or filemaster, everything works fine. if i logging only to console or to serial port, also no problem experienced, i can use all function without any problem. strange

[Toni Wilen]

Originally Posted by anchor

yes, i cutting down the part before : sign, it is fine. this prefix comes only with wb rename. im just simply dont know its purpose.
one more interesting thing: i have a worker thread which is doing file logging too. after this wb rename action, the logfile open() doesn't returns, and the thread become deadlocked.
if i renaming from cli, dopus, or filemaster, everything works fine. if i logging only to console or to serial port, also no problem experienced, i can use all function without any problem. strange

Perhaps WB has DOS list locked?

hmm... something like this
if i turning off the file logging from workbench rename() to the end of the next unlock(), then no deadlock happened. i suspect this strange workbench path has some meaning.
maybe it means a dos list lock as Toni mentioned. and it is valid until the next unlock().
good to know

btw, i working on a google-drive (and later dropbox) handler for every amiga like os.