maxtherabbit wrote on 2023-12-17, 03:09:

changing media, yes. changing media *type* no. AFAIK you cannot change the DPB you pass to DOS at the time the block device is loaded after the fact

Media type changes all of the time ... The perfect example is using a 1.2MB floppy and then a 360K floppy. Same device, two different media types, descriptor bytes, BPBs and DPBs.

mbbrutman wrote on 2023-12-17, 04:18:

maxtherabbit wrote on 2023-12-17, 03:09:

changing media, yes. changing media *type* no. AFAIK you cannot change the DPB you pass to DOS at the time the block device is loaded after the fact

Media type changes all of the time ... The perfect example is using a 1.2MB floppy and then a 360K floppy. Same device, two different media types, descriptor bytes, BPBs and DPBs.

Yes of course, but that's using the built in floppy driver. I am a bit rusty since it's been several years since I worked with the installable device driver "API" but I clearly remember giving DOS a pointer to a DPB when my driver was initialized, but I don't recall an opportunity/method to alter it. Am I remembering wrong or is there a different means of changing it after the fact?

maxtherabbit wrote on 2023-12-17, 18:18:

mbbrutman wrote on 2023-12-17, 04:18:

maxtherabbit wrote on 2023-12-17, 03:09:

changing media, yes. changing media *type* no. AFAIK you cannot change the DPB you pass to DOS at the time the block device is loaded after the fact

Media type changes all of the time ... The perfect example is using a 1.2MB floppy and then a 360K floppy. Same device, two different media types, descriptor bytes, BPBs and DPBs.

Yes of course, but that's using the built in floppy driver. I am a bit rusty since it's been several years since I worked with the installable device driver "API" but I clearly remember giving DOS a pointer to a DPB when my driver was initialized, but I don't recall an opportunity/method to alter it. Am I remembering wrong or is there a different means of changing it after the fact?

DOS rebuilds the DPB based on the BPB you give it after telling it the media changed. Function 1 is Media Check. If Media Check indicates a change then Function 2 (Build BPB) is called. That results in the DPB getting rebuilt.

I posted this over on VCFED (https://forum.vcfed.org/index.php?threads/mtc … 03/post-1354721) copying it here:

I setup my FreeBSD server to mount my drive images into its local filesystem so it's easy to add stuff to them. Here's how I did it - steps are probably very similar in Linux but using different programs/commands.

First, I had to enable linux compatibility.

sysrc linux_enable="YES"
now reboot your machine or run:
service linux start

Go to the directory where you'll be storing your disk images. I haven't picked a good place yet so it's all in root's home directory (boo! hiss!)

create a FAT16 2GB hard disk image:
newfs_msdos -C 2047M -F 16 drive0.img

attach a "memory disk" (although really we're just mounting the hard drive image I just made)
mdconfig drive0.img
(this will return something like /dev/md0 - use that in the next steps)

mount the image under /mnt
mkdir /mnt/dos0
mount -t msdos /dev/md0 /mnt/dos0

share the drive(s)
./netdrive serve

I can now navigate directly into my drive0.img at /mnt/dos0 and add/remove/manage whatever I need to like any other local filesystem. I connect to it from my MS-DOS machine via:
netdrive connect 192.168.1.66:2002 drive0.img d:

It's probably a really bad idea to try and write to it from the MS-DOS system while you're doing this but I like to live dangerously. Next I'll export it via samba so I can just load whatever I want onto it from a workstation, and will probably setup multiple disk images based on what they contain.

deepthaw wrote on 2023-12-18, 03:04:

I setup my FreeBSD server to mount my drive images into its local filesystem so it's easy to add stuff to them. Here's how I did it - steps are probably very similar in Linux but using different programs/commands.

Another FreeBSD user - hi :)

deepthaw wrote on 2023-12-18, 03:04:

It's probably a really bad idea to try and write to it from the MS-DOS system while you're doing this but I like to live dangerously. Next I'll export it via samba so I can just load whatever I want onto it from a workstation, and will probably setup multiple disk images based on what they contain.

I would also expect this to go sideways really quickly, unless you make sure the image is read-only to netdrive. I'd also expect changes to the image server-side to be confusing to the client, especially if any kind of caching is added client-side. Even something as simple as caching of the FAT could cause interesting side-effects, but at least in read-only mode you won't ruin anything :D

/Eirik

On Linux, netdrive reports "Error opening file" if file permissions are read only for image file. I do not want to give RW access to my images. Can netdrive open image files read-only ?

ivdimkra wrote on 2023-12-20, 18:11:

On Linux, netdrive reports "Error opening file" if file permissions are read only for image file. I do not want to give RW access to my images. Can netdrive open image files read-only ?

You can do it client-side by appending -ro as option to NETDRIVE.EXE, but server-side I don't know, have not gotten that far in my testing yet.

Btw read the manual, it has some nice options to support read-write mounting with per-client ephemeral writes.

/Eirik

ivdimkra wrote on 2023-12-20, 18:11:

On Linux, netdrive reports "Error opening file" if file permissions are read only for image file. I do not want to give RW access to my images. Can netdrive open image files read-only ?

What exact file permissions did you use on the image file?

The code certainly handles read-only files; I designed it for that use case.

mbbrutman wrote on 2023-12-20, 18:43:

ivdimkra wrote on 2023-12-20, 18:11:

On Linux, netdrive reports "Error opening file" if file permissions are read only for image file. I do not want to give RW access to my images. Can netdrive open image files read-only ?

What exact file permissions did you use on the image file?

The code certainly handles read-only files; I designed it for that use case.

Image files are owned by root:root and permissions are 644 (only root can write them, group and others read-only). Netdrive uses dedicated 'netdrive' account to run.

ivdimkra wrote on 2023-12-20, 19:18:

Image files are owned by root:root and permissions are 644 (only root can write them, group and others read-only). Netdrive uses dedicated 'netdrive' account to run.

And traversal rights (+x) on parent directories, and read on the image directory? Stared myself blind on that kind of thing more often than I care discuss ;)

ivdimkra wrote on 2023-12-20, 19:18:

mbbrutman wrote on 2023-12-20, 18:43:

ivdimkra wrote on 2023-12-20, 18:11:

On Linux, netdrive reports "Error opening file" if file permissions are read only for image file. I do not want to give RW access to my images. Can netdrive open image files read-only ?

What exact file permissions did you use on the image file?

The code certainly handles read-only files; I designed it for that use case.

Image files are owned by root:root and permissions are 644 (only root can write them, group and others read-only). Netdrive uses dedicated 'netdrive' account to run.

Ok, that's a problem. As a work-around please change the owner of the file to the dedicated netdrive account.

I'm stat'ing the file and checking the mask, and in this case it looks like a read-write file. I did not check the owner was the same as the current user, so that makes it effectively read-only to the current user. But I'm still trying to open it read-write based on the filemask, hence the error.

(I didn't anticipate people running this as a daemon.)

mbbrutman wrote on 2023-12-20, 22:24:

Ok, that's a problem. As a work-around please change the owner of the file to the dedicated netdrive account. […]
Show full quote

ivdimkra wrote on 2023-12-20, 19:18:

mbbrutman wrote on 2023-12-20, 18:43:

What exact file permissions did you use on the image file?

The code certainly handles read-only files; I designed it for that use case.

Image files are owned by root:root and permissions are 644 (only root can write them, group and others read-only). Netdrive uses dedicated 'netdrive' account to run.

Ok, that's a problem. As a work-around please change the owner of the file to the dedicated netdrive account.

I'm stat'ing the file and checking the mask, and in this case it looks like a read-write file. I did not check the owner was the same as the current user, so that makes it effectively read-only to the current user. But I'm still trying to open it read-write based on the filemask, hence the error.

(I didn't anticipate people running this as a daemon.)

For this case, adding option '-ro' for serve command can do the job. Open all images in read-only mode.
Or, client side can have a hint like myimage.dsk:ro to force read-only mode on the server.
Thanks !

Excellent work again mbbrutman, thank you!

My use case is mostly creating drive backups into a single image file that's easy to update. A big plus is that it preserves file attributes, which I believe you cannot do with FTP. Although WinImage seems to ignore them when extracting files from the image, but that has nothing to do with NetDrive of course.

Is it normal that transfer speed is much slower with NetDrive than with FTP? ~300KB/s vs ~500KB/s on a 386-40 with a 10Mbps NIC. It doesn't really matter as I understand NetDrive isn't meant to replace FTP for simple file transfers but to cover edge cases and different scenarios, I'm just wondering.

(There is a small typo you might want to correct in some subsequent release, the output text of "netdrive serve help" lists the default port as 2022 instead of 2002)

konc wrote on 2023-12-21, 08:35:

Excellent work again mbbrutman, thank you! […]
Show full quote

Excellent work again mbbrutman, thank you!

My use case is mostly creating drive backups into a single image file that's easy to update. A big plus is that it preserves file attributes, which I believe you cannot do with FTP. Although WinImage seems to ignore them when extracting files from the image, but that has nothing to do with NetDrive of course.

Is it normal that transfer speed is much slower with NetDrive than with FTP? ~300KB/s vs ~500KB/s on a 386-40 with a 10Mbps NIC. It doesn't really matter as I understand NetDrive isn't meant to replace FTP for simple file transfers but to cover edge cases and different scenarios, I'm just wondering.

(There is a small typo you might want to correct in some subsequent release, the output text of "netdrive serve help" lists the default port as 2022 instead of 2002)

What size is the image you're copying to? I think the directions mentioned something about certain sizes working better than others for efficiency/mapping purposes.

deepthaw wrote on 2023-12-21, 18:50:

What size is the image you're copying to? I think the directions mentioned something about certain sizes working better than others for efficiency/mapping purposes.

I did read the hint in the documentation about "power of 2, minus 1" so I created a 2047MB FAT16B image with the provided tool. But I think it refers to the cluster size for minimizing the wasted space and not performance.

I haven't played with different image sizes and FAT type on the same PC to be honest, only made this observation and thought to mention it.

konc wrote on 2023-12-21, 08:35:

Excellent work again mbbrutman, thank you! […]
Show full quote

Excellent work again mbbrutman, thank you!

My use case is mostly creating drive backups into a single image file that's easy to update. A big plus is that it preserves file attributes, which I believe you cannot do with FTP. Although WinImage seems to ignore them when extracting files from the image, but that has nothing to do with NetDrive of course.

Is it normal that transfer speed is much slower with NetDrive than with FTP? ~300KB/s vs ~500KB/s on a 386-40 with a 10Mbps NIC. It doesn't really matter as I understand NetDrive isn't meant to replace FTP for simple file transfers but to cover edge cases and different scenarios, I'm just wondering.

(There is a small typo you might want to correct in some subsequent release, the output text of "netdrive serve help" lists the default port as 2022 instead of 2002)

The performance difference has an easy explanation. The most I can send in a UDP packet is two 512 byte sectors (1024 bytes) while FTP can send about 1460 bytes in a packet. Also, because FTP uses TCP it does not need to wait for the other side to acknowledge a packet before proceeding to send the next packet. (This is a feature of the TCP sliding window.) I can't really do that here because you need to wait for reads to arrive and you don't want to send the next read or write without knowing if the previous write is done.

In general, FTP is always going to be faster, and it's going to be a lot faster across long distances. But NetDrive should be more than adequate on a local area network.

(And thanks for the report on the typo!)

mbbrutman wrote on 2023-12-22, 00:14:

The performance difference has an easy explanation. The most I can send in a UDP packet is two 512 byte sectors (1024 bytes) w […]
Show full quote

konc wrote on 2023-12-21, 08:35:

Excellent work again mbbrutman, thank you! […]
Show full quote

Excellent work again mbbrutman, thank you!

My use case is mostly creating drive backups into a single image file that's easy to update. A big plus is that it preserves file attributes, which I believe you cannot do with FTP. Although WinImage seems to ignore them when extracting files from the image, but that has nothing to do with NetDrive of course.

Is it normal that transfer speed is much slower with NetDrive than with FTP? ~300KB/s vs ~500KB/s on a 386-40 with a 10Mbps NIC. It doesn't really matter as I understand NetDrive isn't meant to replace FTP for simple file transfers but to cover edge cases and different scenarios, I'm just wondering.

(There is a small typo you might want to correct in some subsequent release, the output text of "netdrive serve help" lists the default port as 2022 instead of 2002)

The performance difference has an easy explanation. The most I can send in a UDP packet is two 512 byte sectors (1024 bytes) while FTP can send about 1460 bytes in a packet. Also, because FTP uses TCP it does not need to wait for the other side to acknowledge a packet before proceeding to send the next packet. (This is a feature of the TCP sliding window.) I can't really do that here because you need to wait for reads to arrive and you don't want to send the next read or write without knowing if the previous write is done.

In general, FTP is always going to be faster, and it's going to be a lot faster across long distances. But NetDrive should be more than adequate on a local area network.

(And thanks for the report on the typo!)

Ah so it's expected. Thank you for the detailed explanation, it makes total sense now

Grzyb wrote on 2023-12-17, 00:30:

doshea wrote on 2023-12-17, 00:21:

General question directed at anyone who knows: does DOS even support changing media for block filesystems?

I guess it does - how else could it support floppy disks?

Thanks, but oops, I didn't explain my thoughts properly! I was thinking about what I suppose are "hard drives" - the drives that get assigned letters C: onward, but are obviously not just "fixed" disks because of this:

mbbrutman wrote on 2023-12-17, 04:16:

DOS supports changing the media type when the media changes. It also allows the driver to provide a new BIOS Parameter Block, which in turn changes the Drive Parameter Block. (The DPB is derived from the BPB.)

Great, thanks for the info, that's nice to know!

I did not use any undocumented DOS features.

Wow!!

mbbrutman wrote on 2023-12-20, 22:24:

I'm stat'ing the file and checking the mask, and in this case it looks like a read-write file. I did not check the owner was the same as the current user, so that makes it effectively read-only to the current user. But I'm still trying to open it read-write based on the filemask, hence the error.

I think those kinds of checks are hard to get right, and even if you get them right, they're racy in that the permissions could change between your checking them and opening anyway, so it's not as if you can assume the attempt to open will succeed just because you checked the permissions beforehand. The rule of thumb at most places I've worked is to just trust open()/fopen()/etc., i.e. in this case just try to open it read-write, and if that fails then fall back to opening read-only (which could obviously fail too). You probably need to know the file size too, and I suppose the safe way is to seek to the end of the file after opening it and then find out what the file pointer value is rather than call stat(). Maybe it's overkill in this case to do things "safely", but I don't think it's generally harder.

doshea wrote on 2023-12-24, 00:51:

I think those kinds of checks are hard to get right, and even if you get them right, they're racy in that the permissions could change between your checking them and opening anyway, so it's not as if you can assume the attempt to open will succeed just because you checked the permissions beforehand. The rule of thumb at most places I've worked is to just trust open()/fopen()/etc., i.e. in this case just try to open it read-write, and if that fails then fall back to opening read-only (which could obviously fail too). You probably need to know the file size too, and I suppose the safe way is to seek to the end of the file after opening it and then find out what the file pointer value is rather than call stat(). Maybe it's overkill in this case to do things "safely", but I don't think it's generally harder.

I consider this approach the best one, too: There might be mechanisms that influence r/w openability beyong locally visible file permissions: Most current Linux file systems support ACLs. SELinux might prevent some access that seems permitted according to the classic permissions. The file might be on a network file system with the server implementing some kind of permission check that isn't fully transparent to client-side visible permissions. This is in addition to the race-codition issue.

While the seek-to-end method is working correctly, guaranteed to return information about the file you actually opened, extremely portable, and can be implemented on top of the stdio abstraction layer, there is an easier method if you only target Unix-like operating systems and already work on the file-descriptor layer: You could also use fstat with the current file descriptor instead of seeking the file, still getting the same complete set of stat results you used to get using stat by name.

ivdimkra wrote on 2023-12-12, 14:21:

I'm testing netdrive server on linux (ubuntu). Works fine, but can i run netdrive serve like a daemon, without terminal commands input ? I wish to start it from systemd service unit ..

That would prevent you from seeing/accessing/using the rather nice TUI it provides, but others (including me) have daemonised this and it works just fine.
How it's done depends on your platform; systemd is but one of many ways to manage services on Unix and unix-like platforms. I don't think the author should be expected to do that job, given that the tool was clearly made for interactive use. :)

/Eirik