Jump to content

Copying 4GiB file from 98SE to XP share hangs 98SE


RetroOS

Recommended Posts

I have discovered an interesting problem. I think it's a bug somewhere in Windows 98SE.

I have a large file (10GiB) that is spanned over several files (created on 98SE).

Each spanned part is 4GiB-512 bytes (4,294,966,784 bytes).

I have no problem copying these large files around on the local drives...

However, recently I have made a complete backup of my 98SE files onto a NTFS share on a Windows XP SP3 PC.

Files of all sizes copied with no problem, 3GiB for example, nearly 200GiB of files...

However, when I was copying the 4GiB-512 bytes files, Windows 98SE hard locked (mouse stuck etc) on the last 65024 bytes (63.5KiB)

So, only 4GiB-65536 bytes (4,294,901,760 bytes) copied.

I've tried quite a number of times but with the same result...

That to me sounds like an internal overflow or some other internal problem in Windows 98SE...

What I've tested:

1. Copy 4GiB-512 bytes file using Windows Explorer on local drive - okay - WinDiff compare okay

2. Copy 4GiB-512 bytes file using Windows Explorer to network share - hard lock - Windiff compare mismatch (after reboot)

3. Copy 4GiB-512 bytes file using xcopy in DOS VM to network share - hard lock - file smaller by 65024 bytes

4. Copy 4GiB-512 bytes files using Windows Explorer from network share - okay - WinDiff compare mismatch

5. Copy 4GiB-65536 bytes files using Windows Explorer to network share - okay - WinDiff compare okay

6. Copy 4GiB-65536 bytes files using Windows Explorer from network share - okay - WinDiff compare okay

The reason tests 2 and 4 mismatch and test 3 is smaller, is because Windows Explorer preallocates the file even if the data fails to finish copying.

From these tests it would appear that reading or writing is failing to copy the last 64KiB of data just below 4GiB...

It's the first time I've seen this kind of hard lock while copying a file, but it's also the first time I've tried to copy such a large file to a network share...

My Windows 98SE has all available updates installed that I know of.

Many people say that the absolute file size limit in Windows 98SE is 4GiB-1 byte.

This is presumably because the FAT32 file system has this limit.

However, NTFS and therefore access to NTFS network shares have been around well before Windows 98/SE/Me existed.

So, the potential to access very large files has also been there.

Windows Explorer and Windows 98SE's internal file system support can easily display file lengths and data sizes over 4GiB on a network share, so why can't it manipulate them???

There is obviously internal support for 64-bit data sizes...

I've had a look at the Win32 API functions related to file access.

The CopyFile and MoveFile APIs only require source and destination filenames and do not indicate any file size.

ReadFile, ReadFileEx, WriteFile, and WriteFileEx all use 64-bit file position pointers back to Windows 95.

(Hehe) It looks like Vista (and XP - see comments) have their share of large file copy problems: http://www.howtogeek.com/howto/windows-vis...-windows-vista/

Edited by RetroOS
Link to comment
Share on other sites


My Windows 98SE has all available updates installed that I know of.
Well, the problem may be with the COPY2GB patch, in this case. Check any available documentation on it and/or contact the author, if possible.
Link to comment
Share on other sites

...Well, the problem may be with the COPY2GB patch, in this case...

Yeah, I thought about that one... But the files copy without a problem on the local drives... It's only a problem when copying via Microsoft Networking (over TCP/IP)...

Link to comment
Share on other sites

Urgh! Some file operations (AFAIK) "pass through" a user profile folder before they "hit" the target (final destination folder). Maybe that's where it garfs?

Haven't tried this, but maybe this would be a solution/workaround - set up the XP (or whatever) as an FTP server and try using FlashGet (or another good downloader; they usually allow pre-allocating directly in the target) in the 98SE.

Link to comment
Share on other sites

  • 3 months later...

Update

I've been using Microsoft SyncToy to do incremental synchronisation backups of my Windows 98SE PC.

Since it would not run on 98SE (even with KernelEx), I've run it from Windows XP on another PC.

I access shares on the Windows 98SE PC.

What I've found is that the 4GiB-512 bytes files copy with no issue from Windows 98SE on the Windows XP PC via Microsoft Networking (SMB).

I was also able to copy a 4GiB-512 bytes file back to a Windows 98SE share, on Windows XP, again with no problem.

I then successfully compared the original file on 98SE with the copy made from XP.

This makes the original problem even more odd.

However, I have a different problem that I have discovered with Microsoft Networking when copying on Windows XP from Windows 98SE.

Some special characters in filenames on Windows 98SE appear on XP as invalid, and are replaced with underscores (_).

Examples are ®, ø, ’, ³, ™, " " (yes really, some 'spaces' are invalid!!!), —, •, –.

This causes a file read error since the filename is now incorrect...

Short of renaming the offending filenames on Windows 98SE, I'm not sure if there is any solution to this...

[rant]

Remember:

- Windows NT family is Microsoft Operating System/2 (MS OS/2 deceptively named evolved into Windows 3.x, 4.x, and so on)

- Windows 9x family is the real improved original Windows - Windows 1.x, 2.x, 3.x, 4.x (9x)

It is obvious now, that there are fundamental incompatibilities between NT and 9x Microsoft Networking file naming.

[/rant]

Edited by RetroOS
Link to comment
Share on other sites

Remember:

- Windows NT family is Microsoft Operating System/2 (MS OS/2 deceptively named Windows 3.x, 4.x, and so on)

- Windows 9x family is the real Windows - Windows 1.x, 2.x, 3.x, 4.x (9x)

Deceptive seems a bit harsh, but remember NT4 and Win9x were *different* kernels - obviously both NT and 9x had the same shell (and NT 3.5x and 3.1 had the same shell), but they were still pretty different kernels underneath. I'd say Microsoft chose to go with NT-based systems because (1) they were natively 32bit (and with NT4 and up, could be compiled natively 64bit as well), (2) they did not have a flat memory model but per-process and per-user security, and (3) they were easily portable to other platforms (which was important at the time for NT4 and 2000 and still is to a lesser extent today, to support running on things like Alpha, MIPS, RISC, and Itanium - 9x was always intel x86-only). I can see you like the 9x systems, and I'm not bashing 9x (it was a good OS in it's day, and still is to a point today), but statements like this are patently false and inflamatory for no good reason I can think of. From a business and security perspective, it makes sense to go with the NT-based kernel vs the 9x (flat) kernel for both security and a fairly CPU architecture-agnostic codebase (WinCE, WiMo, WinEmbedded, etc).
Windows Explorer and Windows 98SE's internal file system support can easily display file lengths and data sizes over 4GiB on a network share, so why can't it manipulate them???

There is obviously internal support for 64-bit data sizes...

Because there's a difference between caching a 64bit pointer in a process space with a 4GB max limit versus trying to actually cache the actual stream data without running out of process space.

It'd have to be debugged to say for sure, but it seems from your observations that this is indeed an overflow in the fact that the file just can't be cached enough in the 4GB (minus loaded modules and drivers) space before hanging. Perhaps the larger byte sizes actually make it more efficient over the network with the way the stack is tuned in 9x? I haven't tried network copy tests from or to a 9x box in years, but it seems logical that a properly-tuned box for LAN traffic would handle a 64K file stream far better than a 512byte file stream, and could size TCP windows accordingly to transfer more data more quickly, thus minimizing the chance for a buffer backup large enough to hang the 9x box.

Link to comment
Share on other sites

...

Deceptive seems a bit harsh, but remember NT4 and Win9x were *different* kernels... ...but statements like this are patently false and inflamatory for no good reason I can think of...

Point taken. I've toned down my previous rant...

...

From a business and security perspective, it makes sense to go with the NT-based kernel vs the 9x (flat) kernel for both security and a fairly CPU architecture-agnostic codebase (WinCE, WiMo, WinEmbedded, etc).

I agree! I think the NT family (Professional/Business) is ideal for a business environment.

It's just a shame that Microsoft abandoned the 9x family.

Calling Windows XP Home a replacement for Windows Me (or any 9x), is a slight on home users!

If Microsoft call restricting access to security permissions to Safe Mode only, progress, then I think they've lost the point of the 'NT line'...

...it seems logical that a properly-tuned box for LAN traffic would handle a 64K file stream far better than a 512byte file stream, and could size TCP windows accordingly to transfer more data more quickly, thus minimizing the chance for a buffer backup large enough to hang the 9x box.

Hmm, you've given me an idea of some more tests to try...

Link to comment
Share on other sites

BTW, I'd still disagree with you that 9x was the original Windows - you forget that NT 3.1, 3.5 and 3.51 were actually out in the Win 3.x timeframe, were 32bit native, and predated Win9x (which was still 16/32bit hybrid) by 2 full years ;). I'm just nitpicking, of course, the post is fine. I just feel the need to reply to posts that state 9x was the original or true Windows, when it was in fact predated by NT 3.1 by 2 years (and 9x never became true 32bit, making it impossible to port to 64bit and thus one of the major reasons the NT line went forward instead of the 9x kernel - you can't run 16bit code on a 64bit processor when it's in native 64-bit mode). Again, 9x was a fine OS in it's day, but there are technical reasons (and business reasons, of course) why it died as it did.

Link to comment
Share on other sites

...you forget that NT 3.1, 3.5 and 3.51 were actually out in the Win 3.x timeframe, were 32bit native, and predated Win9x (which was still 16/32bit hybrid) by 2 full years ;)...

One could even say that Windows 3.1x was the end of the original Windows trunk, and that NT 3.1 onwards was a branch followed later by Windows 95 as another parallel branch.

One has to admit though, that NT was the result of MS OS/2 1.3. Afterall, Windows NT was orginally going to be called Microsoft NT OS/2...

It was because of the success of Windows 3.0 and various issues with the joint venture with IBM, that the upcoming NT OS/2 3.0 'merged' with Windows to become Windows NT 3.1, and Microsoft left IBM to continue IBM OS/2 2.0.

In many ways, Windows NT was Microsoft OS/2 with Windows compatibility, look, and feel.

However, with NT 4.0, Microsoft dropped the driver for the OS/2 HPFS file system, and somewhat redesigned the kernel to allow them to finally drop the MS OS/2 1.3 kernel layer with Windows XP/2003.

Call it a fetish, but I just plain like Windows 98SE!

I've used every version of Windows from 2 to 7 and I still like 98SE... (What was there to like about Windows 2 with mono or four colour CGA anyway?)

I never could get Windows 1.0 running...

Link to comment
Share on other sites

HAHHAHAHAH OMG!

I STILL have MS-DOS 5.0 disks and MS-Windows 1.01 disks.

EDIT = I got it all installed in VMWare!

Can't get the mouse to work but I can keyboard around most of it.

What where the himem tweaks and such to add to the start up files?

Does anyone remember?

Edited by Kelsenellenelvian
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...