>I'd be interested in hearing what kind of problems you've had here. I've never encountered any problem with WNetCancelConnection(). The only real potential problem that I see is with files that aren't closed or buffers flushed.
>

The specific problems involved VFP 3, with UNCs dynamically mapped to NetWare 3.x server volumes. A call to WNetCancelConnection() for one or more WNetAddConnection2() or WNetAddConnection3() added drive letters, followed by carefully releasing the .DLL declarations and a QUIT or CANCEL consistantly caused Fault 0x0E from Win95/95a/OSR 2.0. The workarounds we arrived at were to leave the drive letter mappings, clean them up externally with an app that we lauched with WinExec() just prior to QUITting, which went and did WNetCancelConnection()s on our behalf when our VFP app died off, or to call WNetCancelConnection() and then terminate by cleaning up the VFP debris as best we could and terminating the VFP app with a call to ExitProcess(). Being able to not use UNCs in virtually all circumstances under VFP 5 solved most of our headaches, although we had to be careful to clean up connections later to avoid holding seats on servers.

>I map everything to a drive letter rather than using the UNC. I find that it's much easier to restore the environment. I think that doing so is important since (in theory) it should free resources, as well as, freeing a license on he target server.
>

If I have the freedom to do so, I much prefer mapped drives, too; I have clients who require that we not make permanent or external drive letter mappings for some apps (this causes real registry headaches for us, too.)

>>
>>The real PITA is not getting the blocksize, but computing the size of the directory allocation needed on the target system when disk space is really tight. FAT volumes without LFNs were trivial, since you had a fixed number of directory entries per block that was easily computed; LFNs complicated things, since the nuumber of directory entry structures required per filename varies according to the length of the filename. NT, various ?nix filesystems and NetWare have even more complex requirements because of how their directories are structured, and because there is (or can be) security information that further increases the amount of space required per file or per directory.
>>
>>Compression makes anything but a ceiling value pure guesswork - you can get physical allocation in blocks through the API, but determining the actual size of the base allocation unit is a problem, especially with compression methods like DriveSpace and NetWare that use suballocation units for small files to reduce slack space on your system.
>>
>>As long as overestimation of physical space required isn't a problem, and you aren't so tight on free space that the size of the directory structures is a problem, it is pretty easy to do...
>>
>>Ed
>
>No question about it. I think, however, under most circumstances (especially given the size of drives these days) that this problem probably isn't as prevalent as it used to be.

I thought so, too - it seems compression on server volumes, especially under NetWare 4.1, is extremely popular at some very large corporations. We've even been told of people who compressed their RAID 5 arrays, which seems very silly since it makes crash recovery a real nightmare. At least compression on the workstation does seem to be less and less prevalent, especially with FAT32 and NTFS, which use smaller base allocation units for larger volumes; it's hard to argue with suballocation when you have tons of small files and 32K cluster size a la FAT16 on 1-2GB partitions.

Ed