How do I copy 10gb file to another folder already containing

I have 32 bit in XP & W7, no problems in XP

W7 wants to copy it (what I did not mention is that the destination folder is on a small partition drive just to accommodate this file, so there is no spare space)

I get the usual message with smaller files in W7 when I copy & paste if file exists in destination, but not with this file

Delete the old file and copy the new one to the now empty space. What happens?
If it works OK now, you know how to do it in Windows 7.

Kees

I would say that a good test is to see if this 10GB file will copy elsewhere on the hard drive, on the partition where Win 7 is located. If that works then you have eliminated both OS problems and corrupt file problems, and are left with the small partition being the cause.

Alternatively, as you are trying to Copy/Replace, then simply delete the one you are trying to replace first, then copy over.

Mark

That has nothing to do with it. What would impact this sort of thing is FAT32 v NTFS filesystems. FAT32 only supports files up to 4GB (exFAT or FAT64 I believe removed this limitation, but it's virtually never used and IIRC FAT16 could only handle files up to 2GB in size, which was almost inconceivable when it was created) in size, so if you try and copy a file over 4GB in size it will give an error message along the lines of there's insufficient disk space. The 32/64-bit nature of the OS has absolutely nothing at all to do with this. People were using 10GB files with ease on 32-bit versions of Windows NT and 2000 long before the majority of the world had ever even heard of a 64-bit OS or even really knew that Windows was 32-bit as opposed to any other value (because technically the pre-XP consumer versions of Windows weren't 32-bit operating systems).

The filename suggestion mentioned below is also a possibility, though not one you run into very often. Even with the full path counting as part of the 255 characters, most people just don't name files things like "This is my dissertation where I show that plants respond to Bach more than Mozart piano concertos".

What seems to be the case is that there simply isn't enough space to copy the new file. Windows will first copy the new file, then delete the existing file after the new file has been completely copied over. This is how you can abort the process without the initial file being affected. It's the same thing for when you "move" a file. Windows actually copies it and only after a successful copy does it delete the original file. So you need enough space for the new file before you start copying, regardless of whether you're overwriting an existing file.

First: the file name has only 8 characters, so that has nothing to do with it
Second: I cannot delete the file first as it is has sensitive data, so if I were to delete it would take 30 mins with eraser
Third: The drive I am copying to only has 1gb free
Fourth: I have been doing this for 2 years with XP with no problems, to same drive, same folder
Fifth: The copy/replace feature works if I copy to drive C\test, then do a second time, so free disk space is the issue with W7
Sixth: As I am a programmer I will now try to write a program to do this, as it is most frustrating, may take a while so will get back when I try it

So, Mark Flax, thank you, but it still does not answer why I can do it in XP & not W7

I can't explain why this worked in XP, but I'm betting both James and Jimmy have highlighted the problem.

It is likely that Win 7 is attempting to copy the new version of the file to the partition before asking if you want to delete/replace. If that is the case then partition size becomes a factor and if there is not sufficient free space on that partition, the copy/replace will fail.

I bet if you simply attempted to copy the file (with a different name) to that partition, you would get the same error.

May I ask? Why use a partition on the same hard drive? Why not just use a different folder on the main partition where the OS resides? There is no benefit that I can see to using partitions, except for dual booting different OSes. But for data storage, folders work just as well.

Do you have a backup of this 10GB file? If the hard drive fails then any partition storage is also lost of course, so backups away from the main hard drive is the safest way.

Mark

I can guarantee that if you took the exact same drive and file and put them on an XP computer, you would get the exact same results. XP and Windows 7 operate in exactly the same way when it comes to copying/moving files. The likely reason it worked before on XP is because either there was more free space on the drive at that time and/or the file size was smaller.

You just weren't letting facts get in the way of a good crotchety old man routine about how things were so much better back in the day when you had to walk to school barefoot, over broken glass, up hill 15 miles, both ways, in the waist deep snow that is blowing around so you could barely see the hand in front of your face, wind chill of -500F, killing and skinning animals with your bare hands to fashion a coat out of their pelts if you got cold, because it made a man out of you and all the people today are soft and lazy, etc, etc.

You have a choice to make: You can either delete some other stuff from the drive to free up another 10GB of space and then move the file in question over, or you can spend 30 minutes using a secure erase program to delete the version on the drive currently and then copy the new one over.

As a programmer, you should know that trying to create a blind move program might well be impossible on Windows 7 (or XP) since it's a protected mode OS. Unlike the Win9x line, those policies are enforced on XP and 7. You'd have to completely bypass all of the normal file i/o APIs for the OS and create your own which, quite frankly, is well beyond the abilities of even many very good programmers. Quite frankly, if you had the programming skill to pull this off, you wouldn't even attempt it. You wouldn't have likely even asked the question, you would have been able to do the simple logical analysis I did years ago by observing how file copy/move programs work and then put that together with your current lack of sufficient free space. You also realize that if you're worried enough about the contents of that file that you need to use a several pass secure delete program on it, simply overwriting the file is a huge hole in your security policy, basically rendering the entire thing pointless.

Say, for the sake of argument, you had 100GB of free space; more than enough to copy the file you want to copy. The copy program would lay down a fresh copy of this file and then simply mark the file clusters used by the old version as free. It won't overwrite the exact same set of file clusters used by the previous version of the file. As a general rule, no operating system will guarantee a specific set of file clusters are used. So all this time you've been simply copying the new version of the file over to the drive, you've been leaving the old version accessible to any ne'er do well who might steal the drive and run it through some kind of file recovery program. If there is some kind of security policy concerning the stringency in which files must be deleted, you should be following that policy every time. Deleting the old file, using the secure erase program and then copying the new file over. Anything else is an enormous hole in your security policy, sort of like having an entire battalion complete with tanks and heavy gun emplacements guarding the front entrance of a warehouse containing secret cargo, but leaving the back loading gate open and unguarded, not even so much as a security camera, so anyone can just walk in and take whatever they want.

If an 11 GB partition has a 10 GB file with sensitive data, and you copy another 10 GB file to it, there are 2 options (the extremes):
1. The new 10 GB file uses exactly the same sectors on the hard drive as the old one, so it overwrites all those old sensitive data with new sensitive data. No need to use eraser first. But the new sensitive data is easily visible.
2. The new 10 GB file uses 9 GB of sectors from the old file + the 1 free GB of sectors. That leaves you with 1 GB of the old sensitive data unerased and 10 GB of the new sensitive data easily visible.

In both cases, using eraser doesn't make any sense to me.

Kees

If one cuts and copies from one folder to another on the same partition, the only change actually made is in the properties of the file, such that in FAT32 the location of the file is updated in the file attribute table and the actual file remains in the same place on the drive.

Only if the file is moved (cut/paste) to a new partition does anything happen and that is it's copied into the new partition, and then entry in the file attribute table is removed while the file remains in the clusters where it's located until they are overwritten by new data.

Seems there's more question here than just moving a file since security was mentioned.

A work around is to copy the file and then before "deleting" the file from it's previous place is to "encrypt" it.

If I format a drive used previously, I then either use dd command in linux to zero mark the entire partitions on it, or in both windows and linux I can use True Crypt do basically the same thing. There are softwares available to overwrite drives several times with random useless data so nobody can undelete anything or find file fragments and restore them.

Before diving into Java or C# (or even Visual Basic or C) to make your program, I'd try:
1. The command prompt (using copy, xcopy or robocopy)
2. Vbscript (using the filesystem object)
3. Powershell
None of these should be difficult for a programmer.

Kees

And none of them will work, except maybe C, because all of those are abstracted out into a sandboxed runtime. If you made a C program without using any of the .NET Framework libs, you'd have a fighting chance, but you still have to contend with the fact that as a programmer you don't generally have any direct access to the hardware, let alone the ability to specify you want file clusters 123456-123689 to be used for storing this specific file. Typically you call an API which directs the kernel to perform some function on your behalf.

Maybe someone with more programming experience than me can think of some other means of doing it, but I can't see how you could possibly hope to even come close to achieving something like the OP wanted without Ring 0 access. If you know what Ring 0 is, you'd know why it's not something Microsoft makes readily available to any random program. Even with Ring 0 access, a blind copy program just seems like you'd be opening up a huge of worms for no real good reason. One tiny little coding error could have truly catastrophic consequences.

I don't mean to diminish the achievements of application programmers (I'm barely at the level of creating my own little macros), but there is a world of difference between application programming, which is what the vast majority of programmers do, and system level programming which is what the OP is talking about. If the OP presses forward, unless they're far more skilled than their posts would indicate, things are unlikely to end well.

There is obviously some underlying operating change in W7 for both Explorer & Explorer++ as they both report insufficient disk space which did not occur in XP

For those who are not programmers, I cannot help you if this is your problem

For the Programmers I have solved the problem, a simple copy command works perfect
Now I have the code in a program, a single click does everything for me, so much simpler than before when I had to look for the source, copy and then look for the destination.

Here is my code in Vb'

Dim SourceDateTime As Date = FileDateTime("I:\_Personal\Personal")
Dim DestDateTime As Date = FileDateTime("E:\_00\_Backup-Vaults\_Personal\Personal")

If SourceDateTime = DestDateTime Then
MsgBox("No need to copy")
Exit Sub
Else
If File.Exists("I:\_Personal\Personal") Then
If File.Exists("E:\_00\_Backup-Vaults\_Personal\Personal") Then
Try
Me.Text = "Copying"
FileCopy("I:\_Personal\Personal", "E:\_00\_Backup-Vaults\_Personal\Personal")
Catch ex As Exception
Me.Text = "Copy Failed"
Exit Sub
End Try

SourceDateTime = FileDateTime("I:\_Personal\Personal")
DestDateTime = FileDateTime("E:\_00\_Backup-Vaults\_Personal\Personal")

If SourceDateTime = DestDateTime Then
Me.Text = "Copy OK"
Exit Sub
Else
MsgBox("Files copied are not the same")
Exit Sub
End If
End If
End If
End If

That still doesn't cover the gaping hole in your security policy. You don't know for sure what file clusters on the drive are being used, so can't guarantee that it's the exact same set as before, meaning parts of the old file are likely still around.

Looking at that code and comparing it to some basic examples I found for VB exception handling, you don't do any kind of test on the exception. Try...Catch statements are a form of loop: Run this code as long as this condition isn't true. Someone a bit more up on VB would have to confirm, but it looks like the way you have it written you'll just store any exceptions thrown in that ex variable, but since you're not testing it against anything, it's just kind of like a manual override to any built-in safety measures. So hopefully you test the backup every single time, because if I'm reading that code correctly, you're just telling the OS to ignore any warnings and go ahead, meaning it probably only copied about 1GB of the file before erroring out leaving you with a corrupt backup, but since you trap all exceptions, it claimed to complete successfully.

I don't know how far back exactly that behavior goes, but my guess would be it stretches back into the early days of Unix if not further. If there was some sort of a change, it was to try and make the underlying system more reliable and less prone to errors. There's no way Microsoft would ever want to tick off its large enterprise customers, who pay out the large sums of money for volume licenses, by having a flaky file copy system.

the file is an encrypted container (vault) created by cryptainer, so both files are actually the same file, only the contents are different

As a precaution I will check the file size for comparison to ensure copy is intact

It works for me. so I am happy