Skip to content
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

Allow use of SE_BACKUP privilege #24

Open
candera opened this issue Mar 18, 2011 · 4 comments
Open

Allow use of SE_BACKUP privilege #24

candera opened this issue Mar 18, 2011 · 4 comments

Comments

@candera
Copy link
Owner

candera commented Mar 18, 2011

It's possible that making using of the backup privilege will help hobocopy succeed in scenarios where it usually fails. Need to do research into this, see if it will help, and add support for it. Open questions:

  • Should it be an option or should we just always enable it if possible?
  • If it's an option and we can't enable it, should we fail or try to proceed anyway?
  • If it's an option, should it default to on and the switch turns it off or the other way around?

Here's a link to code that can enable the priv: http://msdn.microsoft.com/en-us/library/aa387705.aspx

@danielj23
Copy link

Hey Craig,
Check out this link about SE_BACKUP. I can't help but feel that hobocopy is severely crippled without this ability, or the ability to copy ACLS/DAT file information along to the destination.

http://www.experts-exchange.com/OS/Microsoft_Operating_Systems/Windows/2000/Q_24208805.html

If you need the text (you have to be a member see the results) I am pasting it below.

There are two comments I feel are pertinent.

"You are indicate that you are writing your own backup application. Therefore presumably you have the source code. Which Win32 API is failing, and what is the source code context?
The QUERY INFORMATION op is used by many different Win32 API calls: GetFileAttributes, FindFirstFile, CopyFile, MoveFile, etc.
Are you trying to use CopyFile()? That won't work. You need to open the file with the flag FILE_FLAG_BACKUP_SEMANTICS. Neither CopyFile nor MoveFile set the flag when they call CreateFile internally.
Microsoft uses the undocumented function PrivCopyFileExW. It sets the FILE_FLAG_BACKUP_SEMANTICS when it calls CreateFile internally.
For mere mortals the only supported way to back up a file while bypassing all security is to explicitly call CreateFile with FILE_FLAG_BACKUP_SEMANTICS, and then use the documented APIs BackupRead or BackupWrite. This is the only way to reliably capture all metadata associated with the file (alternate streams, sparseness, DACL, SACL, attributes, extended attributes, hard links, object ID, etc.)"

follow this link and look at the link it refers to on "Kernel NG"
You will find some particularly relevant MSDN articles on the issue.

Whether they are pertinent STILL is what I am not sure of. Some things lead to this being a FAT/32 API call, but I am sure it has been updated probably in MSDN for NTFS systems

@candera
Copy link
Owner Author

candera commented Jun 24, 2011

Sadly, I did not see this comment until just now. Thanks a ton - very helpful!

I'm still trying to figure out whether it even makes sense for hobocopy to be a backup tool - sometimes I think it would make more sense just to shell to robocopy after handling all the shadow volume creation stuff. But I'm still torn.

At any rate, assuming hobocopy retains file copy capabilities, this information will be super helpful. Thanks again!

@danielj23
Copy link

Glad I could help. I would love to see robocopy more fully functional as a drive backup utility, rather than just a file/folder backup tool.

Let me know if I can offer more assistance. I know some C, but am not fluent enough to fix/replace the code.

@candera
Copy link
Owner Author

candera commented Jul 6, 2011

Additional grist for this particular mill:

http://groups.google.com/group/hobocopy/browse_thread/thread/50e8b737ec1fc535

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants