Duis mollis, est non commodo luctus, nisi erat porttitor ligula, eget lacinia odio sem nec elit. Sed posuere consectetur est at lobortis. Vestibulum id ligula porta felis euismod semper. Donec ullamcorper nulla non metus auctor fringilla. Aenean lacinia bibendum nulla sed consectetur. Cras justo odio, dapibus ac facilisis in, egestas eget quam. Cras mattis consectetur purus sit amet fermentum. Morbi leo risus, porta ac consectetur ac, vestibulum at eros. Sed posuere consectetur est at lobortis. Etiam porta sem malesuada magna mollis euismod. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Duis mollis, est non commodo luctus, nisi erat porttitor ligula, eget lacinia odio sem nec elit. Cras justo odio, dapibus ac facilisis in, egestas eget quam. Aenean eu leo quam. Pellentesque ornare sem lacinia quam venenatis vestibulum. Curabitur blandit tempus porttitor. Sed posuere consectetur est at lobortis.
Are you using PartitionMagic on a Server? PM8 is a consumer product designed for use on pc’s not servers.
Hi Kreg,
I'm running Windows XP Professional x64 edition. I realise it's based on the Server 2003 infrastructure, but this is a single user server installation.
I've also just tried installing PM8 on my XP Pro 32 laptop, and I get exactly the same problem - when I try to partition or modify any partition on any USB drive on that, PM refuses to commit the changes without rebooting the PC. That's a different setup though, as it does not have USB 2.0 drivers.
I don't mean to confuse the issue, but as an international hardware and software support specialist myself, I always get nervous when a support response focuses on why the product won't work.
So far, it looks to me like PM8 won't commit any changes on any XP Pro system without rebooting, and I don't understand why. I fyou need more information or data, please let me know and I'll do my best to get it for you.
Kind regards,
PCPete
Partition Magic should only require a reboot to apply changes when the main OS partition is affected. Technically XP 64 bit isn't a supported OS for Partition Magic. The fact that you see the same behavior on XP 32 bit as well is strange. Do you have any OS related folders on your USB drive? ex. Documents and Settings, etc. Do you have your page file on the USB drive? etc.
G'day Erik, thanks for your suggestions.
No, there are no "hang over" files or folders on the drives - the USB drive (drives, there are 5 of them) are fairly simple 2.5" Travelstar-type IDE drives that I use for testing MSDOS and W95 systems.
What I try to do (after plugging the drive into a USB adapter for 2.5" drives) is use PM8 to simply create a DOS partition of 512M (FAT16, 16k clusters), and apply the changes. When PM goes to actually create the partition, one of two things happens. It either creates it and then immediately prompts to reboot the system, or it fails with an error 402, then stops progress and shows BADMBR in the progress dialog.
This happens with 5 different drives. I've tried a different USB adapter (using a 2.5" to 3.5" IDE adapter connector), and I get the same results - either I'm prompted to reboot, or the partition creation fails.
Having said that, on one occasion about 2 hours ago, PM8 successfully created the partition, wrote all the changes, and came back without requesting a reboot. I have not rebooted this main system since last night, and this was the 9th or 10th attempt to get PM to create a partition. Since then, I've tried another 5 or 6 attempts, and it's back to errors or reboot requests.
I also use Active @Disk x64, and this works wonderfully well with existing partitions - I can back up and restore partitions on the same drives/adapter without ever getting an error. But of course AD doesn't have the powerful editing capabilities I was hoping to get with PM8.
I was (still am) a bit frustrated with the whole PM8 experience, as the evaluation would not allow me to actually create any partitions or make any changes - so now that I've purchased it, I find that the next step (i.e. actually physically writing the changes to disk) doesn't appear to work at all well. If that had happened during the eval, I would have still raised it as an issue, but now, with US$70 down the gurgler, I'm less than happy with the results. That's probably nothing you can do, but maybe this should be fed back to the marketing team - or else they need to clearly state what OSes PM does NOT support, instead of the generic "works on XP"... I've got XP (x64), and it doesn't work! That's irrelevant here, I'm just frustrated that there was no way to find out these limitations before purchasing.
If there are any steps or other information you'd like me to take to help characterise the problem any more, I'm happy to do so. I understand that this may be a no-win game if XP x64 isn't tested or supported, but I'd sure like to try. PM8 would seem to be a perfect fit for my legacy work, but if it's not worth the effort, I still have Active @disk.
Regards,
PCPete
The laptop is a different issue altogether, I'm finding that there are some issues with the USB layer drivers that aren't working properly. It has all the SPs properly applied, but it's a 6-year-old laptop, and the hardware platform is not designed for this kind of USB usage.
Do you have system restore enabled? If so, try disabling on the USB drives to start and if that doesn't change things, try disabling system restore on all drives. Unfortunately I'm not familiar with error 402, but the error is similar to another that implies a problem on the sector of the drive where the MBR would exist. Have you run checkdisk or any other error check utility on these drives? Considering the inconsistent behavior it sounds like there might a problem with the configuration you're using with USB to 2.5/3.5". Have you tried plugging any of these drives direct to the motherboard via IDE to see if that makes a difference or is there a specific reason why you are using USB for your testing purposes? The problem could be something as simple a data transfer problem through your adapters.
Erik, that's a couple of things I'd never thought of... but system restore is definitely disabled for all but the boot drive on this system.
I've also noticed that each time I try to extend or edit FAT partitions on the target drives (all the drives) with PM, it keeps complaining that there is no active partition. And that's confusing! To test this, I deleted all part table entries (using FDISK) and installed a standard MS-DOS 6.22 partition using FDISK on the target system (with CHS settings in the BIOS), to create a single, active, bootable FAT16 partition on the 5.0G drive. I copied all the system files, etc (using the standard MS-DOS setup procedure), and the system was booting and running from that drive. WHen I plugged the drive (via the USB adapter) into my primary system, PM showed the correct partition, plus all the free space, and when I tried to get PM to add an extended partition, it complained that there was no active partition on the drive. So that's one issue.
The other thing I've just noticed is that PM seems to identify each drive I use (5.0G, 8.0G, 60.0G) as the correct size in the properties dialog, but in the drive display window (which I'm currently looking at with the 5.0G drive plugged in), it shows the 5.0G drive having 3 unallocated blocks, 4094.7M, 674.6M, and 3263.2M... I'm not sure what's going on there, is PM maybe getting the wrong values from the USB controller? (Is the USB interface maybe caching the drive parameters? Is there any way I can override this behaviour with PM?)
Unfortunately I don't have the luxury of being able to plug the drives directly into the main system motherboard and reboot. This is a quad-core AMD system with a single (no, I'm not kidding, the H2000 motherboard only has one single :() IDE channel that I already need for boot and swap drives. The rest of the system disk volumes and CD/DVD burners are hardware RAID5 and SATAII respectively. That's one reason I need USB-IDE interfaces.
The other reason I'm doing it this way is because my legacy systems are either PCMCIA or 2.5" IDE drives, and even with 40/44 adapters, they're difficult to mount and unmount without power-cycling the main system. And this is a 99.85% uptime system, so rebooting and shutting down is an option of last resort.
I guess this could be an issue with the USB adapters I'm using... I have two adapters, one using an LTM72438 interface controller, and the other uses a JM20337 PATA bridge.
Both appear to connect and disconnect OK (when I put a "normal' NTFS filesystem on the target devices), and I can copy files to and from all devices without any errors, using Explorer, Directory Opus, or any command window. Using PM to extend or bridge or build NTFS partitions on the drives seems to work without error - it's only when I try to manage FAT (FAT12 or FAT16) filesystems that I get reboot requests. I haven't tried other filesystems (FAT32, linux) because I have no way of using or testing them.
I've built and rebuilt the partition tables using the original systems (wafer PC, Omnibook 600C, etc), and I can access and boot from all devices with minimum configurations (i.e. max partition size of 508M on the DOS system) without error. It's only when I plug them in and try to edit the otherwise stable and normal partitions with PM that I get these errors and reboot requests.
My workaround at the moment is to build a partition table using the standard DOS/BIOS tools on the target system, then use Active@Disk to restore their original data set (dir structure, etc) and expand the partition table to the maximum supported, but because that's trial-and-error (because I can't just simply define the maximum legal size without counting heads and cylinders and adding offsets), that's where I was hoping PM would help, and remove the need for A@D altogether - once the systems are running, I can backup and recover the entire partitions with PM without any trouble - it's just building them that PM seems to have trouble with.\
I'm sorry if this is confusing. I was hoping to be able to find out why PM is having so much trouble with the FAT-type partitions, but I'm running out of time, and I've surely taken up far too much of your time.
Partition Magic will only report back what it receives from the Partition Table/MFT/etc. The fact that you see two other partitions once connected through the control is incredibly confusing and to me points that that might be the potential root cause here. I won't give the "Partition Magic does not support RAID 5 support response" even though it was never tested on that configuration. You aren't making changes to the array, so that should be a moot point. Because you see a difference due to the controllers, that's where I'd bet my money the problem that causes the strange behavior is due to. Unfortunately I don't know enough to make any sound recommendations other than, if you found a work around I recommend using that work around. I wish I could be more helpful, but we've definitely run up to the limit of my experience here. You could try looking at other enclosures/controllers but I can't make any particular recommendations. Since you have a need for testing on DOS or Windows 95 partitions (seems a little archaic in my opinion), have you looked at using vmware or another virtualization program for your testing or does it need to be installed natively?
I have to agree - what the controllers (USB bridge) are reporting seems to be anomalous. Even after disconnecting the device, powering down, shutting down PM, reconnecting, restarting PM, I see the same "ghost" segmentation.
You're right, I'm not using PM (or any other disk product) at all to touch any of the host system drives, I just wanted to be able to manage 'foreign' IDE drives as "natively" as possible through (what I thought would be) plug and play USB connections.
Unfortunately, while I do use VMWare and Virtual PC, they have significant limitations in connectivity - Virtual PC 2007 is a bit of a joke, as it's unable to handle any kind of USB devices natively without first sharing them externally and then dynamically (manually!!) mapping them within the VM; and VMWare is extremely problematic on XP x64, although on the rare occasion when it does work, it handles USB devices very nicely. That's a whole other can of worms, and although I agree that it looks like this host system is the problem, I can assure you that's not the case. This system deals with literally terabytes of complex data every day, and has done flawlessly for over a year with less than 3 hours total downtime - so I know that in and of itself, the host system is as stable as I can make it.
For the rest, I'm just guessing that I'll need to go back to first principles and try different USB bridge devices until I find one that works properly. That's a tall order these days, since most USB bridges are built to cost, not spec. I think that's what's killing PM here - it's not getting reliable access to valid data. Why the data persists across connections I don't know or understand.
I'd still like to understand why PM wants to reboot the host after making changes to a USB-connected partition defined as removable (that's wrong in so many ways I don't know where to start), but again I understand that if you guys can't verify PM on x64, I'm on my own.
Thanks for taking the time to try and understand the problem, I appreciate you've tried more things than some other vendors have been willing to even consider. And I really appreciate you not taking the corporate line regarding supported devices that are moot.