• Please review our updated Terms and Rules here

Moving a file from one user to another

hjalfi

Experienced Member
Joined
Feb 11, 2017
Messages
265
Location
Zürich, Switzerland
What's the recommended way for changing the user code of a file? There isn't a BDOS API for it (which I can find), and as the user code isn't exposed in the user-visible FCB, the alternative approach of walking through the file extent by extent and updating the FCB won't work. I know it's possible to physically copy the file and delete the original but that's pretty wretched. (Not that CP/M user codes aren't already...) Is there anything better which doesn't involve wading in raw disk dirents?
 
I think that is the only way...

The user ID is stored as the first byte of each directory entry. $E5 for a deleted file, otherwise the user number.

Once the file has been opened, the first byte of the file (as stored in the FCB) changes to represent the drive letter the file is on.

To my knowledge, there is no BDOS utility function to do what you want.

Dave
 
PIP allows you to specify a different user number for the source or destination file, but you are still making a duplicate of the file. It's possible that looking through the BDOS source might reveal some other way, but I don't believe that DRI intended for any way to do that, like as part of the RENAME BDOS function call (that's where I'd start). You need to track down and change all matching directory entries, which is what the RENAME function does.
 
Dave Rand's NSWEEP can change the user area of a file; perhaps it's worth looking at the source code to that to see how he does it.
 
Hm, sounds interesting, although I'd never heard of this before.

Go the files, tried to have a play.

The Help file is in German, ach so, which is not an immediate help, but I assume I can use Google or something to do a translate.

The system seems to allow for activating password one by one to every Cmd, which seems somethat OTT, but they seem to be all OFF to start with? I assume?

So far, I've not got it to do anything other than run the PWTL tool re the passwords, I suspect that I know why.

I'm trying this on my Amstrad PCW, which has a uIDE enhancement. The light indicating disk access seems to be fixed on. I suspect that POWER is building a screen interface with all the commands for selection, and/or all the files (and this PCW has multiple 8Mb virtual drives and MANY files) so it may take a LONG time to create/display the screen it's creating. This system would have the same problem if I tried to use LocoScript on it, so I got a 'special' uIDE driver that recognised drives C: to F: ONLY rather than C: to P: which was at least useable.

If someone has used POWER, can they verify this?

I've used NSWP happily for a LONG time, I understand that using this to 'move' a file from one user to another is somewhat clunky, but it works OK for me and I guess I'll stick with it?

Geoff
 
The tool I used under CP/M 3 was called U3.COM, and was invoked by
Code:
U3 FILENAME user
to move files between user numbers, or
Code:
U3 FILENAME
to unerase a file. It used the BIOS to access the disk directory, and rewrote the first byte of matching directory entries as the new user number.

You can find it on the Walnut Creek CDROM: http://cpmarchives.classiccmp.org/cpm/Software/WalnutCD/cpm/cpm3/u3-102.lbr
 
I'm trying this on my Amstrad PCW, which has a uIDE enhancement. The light indicating disk access seems to be fixed on. I suspect that POWER is building a screen interface with all the commands for selection, and/or all the files (and this PCW has multiple 8Mb virtual drives and MANY files) so it may take a LONG time to create/display the screen it's creating. This system would have the same problem if I tried to use LocoScript on it, so I got a 'special' uIDE driver that recognised drives C: to F: ONLY rather than C: to P: which was at least useable.
Interesting, Geoff. I wonder why it should take so much longer to log the drives than the BDOS does?
 
Back
Top