Tweet
As anyone here already knows, Beyond Compare 3 is exceptionally good software. Powerful, flexible and reliable.
Imagine my shock to find out that it was incapable of handling large files in XP, somewhere in the range of 40 to 100 GB for an individual file. I haven't tested the problem in more recent versions of the Windows operating system.
Whose fault this is depends on how you look at the issue. Beyond Compare 3, not surprisingly and reasonably enough, uses Windows API calls to actually perform some of its work, and it's the API calls that are failing in this case. There's nothing wrong with having files that are tens of gigabytes in size under Windows XP, it's just that copying them becomes problematic because the Windows API calls to COPY them don't work properly; it simply a known bug within the copy routines that Windows provides. Many (if not most) applications, such as Windows Explorer, bomb out after being well into the copy operation with a Windows error 1450 because the API calls being used have this bug in them.
Currently I'm getting around the problem by using some free shareware that performs the copy without difficulty. I actually have several files in this size range because I use virtual disk volumes in TrueCrypt. I especially have them on my net book in case my net book gets lost or stolen, and so synchronizing these large files is a common and regular problem for me.
In reporting this problem to Scooter Software, I was told:
1. It's not their problem, it's Windows fault.
2. I'm the only person who had EVER reported the problem (although actually I think I found two instances in the forms that touched on it) and it's an "extreme corner case".
3. They aren't going to be making any changes to their "copy engine" just now, MAYBE in a future version, they'll stick it on the bug list.
4. Fixing this bug might break something else.
Does nobody have a problem with this sort of response but me?
In my view:
1. The decision to use Windows subsystems to do heavy lifting within their application was a choice they made, and not an obligatory one. This doesn't somehow give them an "out" when their application doesn't work.
2. It simply obvious an application whose raison d'être is copying files shouldn't fail halfway into the process simply because the file being copied is big.
3. Such limitations should be prominently posted on sales literature so that buyers can make an informed decision to accept software with such limitations.
4. Marginalizing a user who is reporting a problem should not be a company practice.
5. Software development companies should not say "we're not fixing such-and-such a bug because it might break something else". Logically, with this sort of attitude, no bug would EVER be fixed, would it?
6. And lots more reasons.
Does anybody else have any comments they'd like to make about this?
Imagine my shock to find out that it was incapable of handling large files in XP, somewhere in the range of 40 to 100 GB for an individual file. I haven't tested the problem in more recent versions of the Windows operating system.
Whose fault this is depends on how you look at the issue. Beyond Compare 3, not surprisingly and reasonably enough, uses Windows API calls to actually perform some of its work, and it's the API calls that are failing in this case. There's nothing wrong with having files that are tens of gigabytes in size under Windows XP, it's just that copying them becomes problematic because the Windows API calls to COPY them don't work properly; it simply a known bug within the copy routines that Windows provides. Many (if not most) applications, such as Windows Explorer, bomb out after being well into the copy operation with a Windows error 1450 because the API calls being used have this bug in them.
Currently I'm getting around the problem by using some free shareware that performs the copy without difficulty. I actually have several files in this size range because I use virtual disk volumes in TrueCrypt. I especially have them on my net book in case my net book gets lost or stolen, and so synchronizing these large files is a common and regular problem for me.
In reporting this problem to Scooter Software, I was told:
1. It's not their problem, it's Windows fault.
2. I'm the only person who had EVER reported the problem (although actually I think I found two instances in the forms that touched on it) and it's an "extreme corner case".
3. They aren't going to be making any changes to their "copy engine" just now, MAYBE in a future version, they'll stick it on the bug list.
4. Fixing this bug might break something else.
Does nobody have a problem with this sort of response but me?
In my view:
1. The decision to use Windows subsystems to do heavy lifting within their application was a choice they made, and not an obligatory one. This doesn't somehow give them an "out" when their application doesn't work.
2. It simply obvious an application whose raison d'être is copying files shouldn't fail halfway into the process simply because the file being copied is big.
3. Such limitations should be prominently posted on sales literature so that buyers can make an informed decision to accept software with such limitations.
4. Marginalizing a user who is reporting a problem should not be a company practice.
5. Software development companies should not say "we're not fixing such-and-such a bug because it might break something else". Logically, with this sort of attitude, no bug would EVER be fixed, would it?
6. And lots more reasons.
Does anybody else have any comments they'd like to make about this?
Comment