-
Notifications
You must be signed in to change notification settings - Fork 69
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
winapi: Implement CopyFileA #499
Conversation
lib/winapi/filemanip.c
Outdated
@@ -241,6 +242,130 @@ BOOL MoveFileA (LPCTSTR lpExistingFileName, LPCTSTR lpNewFileName) | |||
} | |||
} | |||
|
|||
BOOL CopyFileA (LPCTSTR lpExistingFileName, LPCTSTR lpNewFileName, BOOL bFailIfExists) | |||
{ | |||
static const DWORD readBufferSize = 65535; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For such constants I prefer constants like 0xFFFF because it will be much more obvious where it originates (not much of an issue for 16 bit, but still; also avoids confusion with 0x10000).
Also: Why not 0x10000? Won't the unaligned value trip the allocator?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point, changed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Personally, I'd prefer it like 64*1024
.
As for the buffer size, it currently is only 4KiB (64KiB previously). That's a bit small imho - XDK code seem to copy in 16KiB chunks (at least that's the size Halo 2 uses to copy files), which I think is a reasonable compromise between performance and saving memory.
} | ||
bytesRead -= bytesWritten; | ||
bufferPos += bytesWritten; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doesn't the kernel offer some call or IOCTL to copy files?
This user-space copy loop feels a bit involved and there's probably a lot that can go wrong (stuff like not applying the proper flags to the file when creating it, not taking advantage of file-system optimizations etc.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Totally agree; I didn't see a function that looked appropriate in xboxkrnl.h
so I assumed there was no lower level method that could be utilized. Similarly I did not have luck searching the win32 docs.
Is there someplace else I could look?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Poked around a bit more, the only lower level copying I found was added as part of windows server after win2k/xp days.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Possibly something more like NtWriteFile()
than using the user abstraction WriteFile()
is what he's hinting at?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I assume he was looking for something more like https://docs.microsoft.com/en-us/windows/win32/api/winioctl/ni-winioctl-fsctl_duplicate_extents_to_file where the entire copy loop is handled at a lower level (but that's not available in the XBOX kernel).
I think a switch to NtWriteFile
would end up duplicating much of the content of WriteFile
and still operating in user-space. I don't know enough to say if the efficiency gain warrants the maintenance cost, but happy to make that change if it's preferred.
@JayFoxRox can you clarify?
de303b5
to
7091a3d
Compare
aa3ff3f
to
7a81aab
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks very close to being ready to merge now, so I should probably mention that, while this isn't explicitly mentioned in this file, the winapi part of nxdk is licensed under the MIT license. Just want to make sure you're aware and fine with that.
You don't have to add any license or copyright info to this file yourself, I'll add that when I slap SPDX headers on everything.
26525d8
to
f486aa3
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the heads up on the license, MIT is totally fine with me.
6276e60
to
597921d
Compare
77b4815
to
9827911
Compare
I took the liberty to force push away the merge conflict. I'll merge once the CI has run through. Thanks for the contribution! |
Implements CopyFileA.
Tests can be found at abaire/nxdk_tests