I'm trying to automate some stuff in SVN, and part of that is copying a .svn file (the one that contains where a directory should update their files from) to a local drive.
I'm using the following code:
File.Copy(#"X:\SVN\.svn", #"C:\SVN\.svn, true");
And I get the following error:
Access to the path 'X:\SVN\.svn' is denied
Am I just not allowed to move these types of files around? I know by default they are hidden, so maybe that's what's going on. Or is there a way in C#, I can just create a new .svn file so I don't have to bother with permissions and the like?
Thanks!
Last time I checked, .svn was a directory. You probably can't copy a directory with File.Copy, or the directory is in use (sharing lock).
Have a look at ProcessExplorer's find function (in Sysinternal Suite) to find out which process uses it (perhaps TortoiseSVN?)
Perhaps schedule your replication using Rich Copy which is a RoboCopy clone from Microsoft that will copy permissions, incremental update etc.
Typically this is because you have tortoise running, and the tortoise cache has the file locked. If you shut it down in task manager you can do whatever you'd like with hit.
That said, what is the purpose of copying it? Are you cloning the project?
If you are on Windows and using TortoiseSVN, then the .svn is actually a directory so you can't use File.Copy on it.
Related
In my C# code I want to be able to use some Shadow Copy mechanism in order to copy files that are being used by another process.
I've seen that solutions exist on the web, in enterprise or command line tools. But could it be done programmatically in order to mimic a simple file copy?
It appears that alphavss does what you want. The sample file VssBackup.cs here seems to do exactly what you want.
This class encapsulates some simple VSS logic. Its goal is to allow a user to backup a single file from a shadow copy (presumably because that file is otherwise unavailable on its home volume).
I am making a data backup program. I need to copy files from one folder to another, while some files are still being used by a running process. It's OK when the running process shares file access. But I will get exception if files are not shared. (FileShare.None)
I am wondering if there is any way to read a non-shared file in C#.
Thanks,
C# under the hood uses the file access operations your operating system provides, including its file sharing behavior. So I'm afraid C# cannot go beyond this.
There is a technique if you are using Vista or later. You can use the Volume Shadow Copy feature. However, getting to work in C# will be tedious, and all that I can provide for help are references. However, if you wanted to administrate a solution instead of developing one, you could use Windows Backup to copy the files on a schedule.
Links:
Shadow Copy Explained
Shadow Copy SDK
Video Presentation on Shadow Copy
When I try to delete a file occurs the following exception:
The process cannot access the file ''
because it is being used by another
process.
My code looks like:
string[] files = Directory.GetFiles(#"C:\SEDocumentConverter\SOURCE");
foreach (string file in files)
{
File.Delete(file);
}
How can I solve this problem?
There is no way to delete a file that's currently being used by another process. You have to close whatever program has that file open first, before you can delete it.
If you don't already know which program that is, you can figure it out using Handle or Process Explorer.
You can P/Invoke the Windows MoveFileEx function, and use the MOVEFILE_DELAY_UNTIL_REBOOT flag, with a NULL destination name. This will delete the file when you reboot.
If the file is being used you're out of luck in trying to delete it. I can't tell you based on your code what process might be using the file(s), but try looking here or here or here, or at any of the other questions that show up as related to this one for guidance regarding this issue, and by all means follow the guidance from #Cody Gray about using Process Explorer.
slightly off topic: But it seems from your code that you are trying to delete all files of your folder.
Well instead of deleting them one by one we have another method Directory.Delete(path, True) which will delete the directory as contained in the string named path. Then you may recreate the directory if you want. But your problem may persist here too.
Another way is to find all open handles to the file and close them forcibly.
Works nice for you, bad for any apps which were using the file.
Could try that in UI with SysInternals ProcessExplorer.
Just rename this file. This will do the thing for whoever tries to write to that location.
Notes:
1) Of course the file is not deleted physically yet. Nice to do the MoveFileEx trick mentioned here around to complete the job.
2) If you want to delete a locked file to write smth new in its place (e.g. during build), just rename the file to a GUID name. If you need the folder to be clean, either use an ignored extension / hidden attribute, or rename the file to a path under %TEMP% (if on the same drive).
3) Not all locked files can be renamed, but it works for me for like 90% practical applications. You can move a file without affecting an open read/write/execute handle, it will continue working with the moved file just good (if moved within the same NTFS volume of course).
4) That's what Windows Installer would basically do before it asks you to please reboot somewhen soon: move the file away from your eyes, schedule to be removed upon reboot. Usually the newly-installed app can be used right away.
Practical Use:
My favorite is with MSBuild. Overriding the <Copy/> task with this stuff makes all the build go linux-way. You don't care if a prev version is still running somewhere, can still build&run. The old app keeps using the old version of the files. The new app loads the newly-written version.
Might be moving to %TEMP% if on the same drive (not my case though). I'd just rename them to an extension which is ignored with the current source control client.
I've got a large folder on an offsite backup machine that gets populated with files by rsync (through deltacopy) every night (running windows xp) from the main work site. I've discovered some annoying folders that cannot be opened, or deleted, or even checked for file sizes. I get the such and such a folder is not accessible, access is denied message when I try to click on it in windows explorer. According to the windows explorer tooltip they are also "empty" and the properties of these folders say 0 bytes and 0 files.
I currently have a C# program that goes through every folder and file and tries to copy the whole backup directory to a dated backup-backup directory, which is how i discovered this problem in the first place. The regular System.IO library seems helpless against these blasted folders. Exceptions are thrown when I even try to access the folder path.
Does anyone have any clue how I could, say, on an access denied exception in my existing copy code, force the delete of these folders so rysnc can recreate the directory again and get the whole thing synced again?
First thing I think of when I see this is time to do a checkdisk. From the sounds of it, it feels more like a file system problem than something solvable the way you want to go about it.
Yes, try the awesome "Process Explorer" from Microsoft (formerly SysInternals).
Although it's for the processes in the windows filesystem, you could search for your folder in the explorer window & it will tell you who is locking it.
Once you release the process, your program would be able to delete the folder.
If that doesn't work, see if you can specify additional parameters to bruteforce the delete in your program.
It sounds like the filenames are either bad or contain characters that are invalid in Win32. Did you try to delete the directories with rd /r? Did you do a dir /x on them and try to delete the files/directories using their short names?
I would say that you first have to figure out why you can't delete the folders. Once you figure that out, you can write a program to fix it.
OK, so now that you know it's a permissions problem, the first step is to take ownership of the files (so you can set the permissions), then change the permissions so that you can delete the files.
Here's code to take ownership of a file:
WindowsIdentity currentUser = System.Security.Principal.WindowsIdentity.GetCurrent();
FileSecurity acl = File.GetAccessControl(filename);
acl.SetOwner(currentUser.User);
File.SetAccessControl(filename, security);
The trouble was that SYSTEM owned these files. I set deltacopy to run as administrator so that administrator would own the files deltacopy makes.
I guess windows is doing its job. The permissions are airtight. But if this happens again someday where I'd have to grab ownership from some other user to the current user (who has administrator permissions) how would I do that in code?
A question for another day I suppose. Thanks again everyone.
I'm trying to monitor a folder using C# and FileSystemWatcher. everything works well, except the fact that i can delete the folder i'm actually watching
I used to do this in C using ReadDirectoryChangesW, by creating a handle to the folder, and locking it, which prevented delete or rename from the user to that folder (i'm talking about the actual monitored folder, not it's contents)
Is there any way to lock that folder so people don't delete it while it's being watched?
(note that I don't want to change permissions to the folder because it might be on a FAT32 partition/usb drive/etc , which doesn't support permissions)
Not sure if that's an option, but you could create a (temporary) file in said folder and keep it open for the duration of the 'watch'. You'll need to clean it up again afterwards off course. (You might even give it the hidden attribute so it doesn't show up to 'normal' users).
Not the nicest solution and the file will remain littering around when your program crashes before removing the file...