0

I am writing within a heavily managed async (single) thread. it is a FIFO queue in a thread and something is locking my attempt to do a Directory.SetLastWriteTime. It is almost certainly me. but I can't see it. I used this link: and as part of it I tried to use Handle but c# wouldn't understand the reference to handle.exe (failed at line tool.Start();) despite the path to handle.exe being in the system path and it running fine in command.

The problem is I then tried to use the FileUtil example code lower down the answers list but this only works on files I need to see what is locking a folder. bear in mind this folder is not really locked, I can change the LastModifiedDate in Attribute Changer 7 so it is certainly my queue that is dong it wrong.

this is the code I am actually trying to run, that continually says it is locked.

System.DateTime newDateTime = new DateTime(2011,1,1,0,0,0,0,System.DateTimeKind.Utc);
if (Directory.Exists(parent))
{
    Unlocker.unlock(parent); //<--new line
    Directory.SetLastWriteTime(parent, newDateTime);
}

note that I suspect FileUtil works fine for files but I need to modify a folder and it is bombing badly. Can anyone help me get the Process locking a given directory not just a file?

EDIT (see also, <<- new line above) I have abandoned FileUtil but I am now using handle.exe successfully (i.e. if I manually lock it by trying to to give it mouse focus in windows explorer for example it detects it) but handle returns no "locks" when the c# bombs:

public static class Unlocker
{
  public static void unlock(string fileName)
  {
    Process tool = new Process();
    tool.StartInfo.FileName = @"C:\Program Files (x86)\Handle\handle.exe";
    tool.StartInfo.Arguments = fileName + " /accepteula";
    tool.StartInfo.UseShellExecute = false;
    tool.StartInfo.RedirectStandardOutput = true;
    tool.Start();
    tool.WaitForExit();
    string outputTool = tool.StandardOutput.ReadToEnd();

    string matchPattern = @"(?<=\s+pid:\s+)\b(\d+)\b(?=\s+)";
    foreach (Match match in Regex.Matches(outputTool, matchPattern))
    {
            Debug.WriteLine("Unlocker.unlock(`" + fileName + "`) is locked by `" + Process.GetProcessById(int.Parse(match.Value)).ProcessName + "`");
    }
  }
}

SECOND EDIT the SetWriteTime was working all along, it was a looping issue further up the code line, it didn't work when the user has mouse clicked on the folder (which I had been doing accidentally randomly) but the bad outer loop was perpetuating it - a bad finally forever causing a loop counter exception with a faulty "file is locked" message.

Community
  • 1
  • 1
Mr Heelis
  • 2,370
  • 4
  • 24
  • 34
  • 1
    *heavily managed async (single) thread* - can you dissect that phrase a bit? What does "heavily managed" mean? Is your app the only app which is accessing the folder? From my experience, having the folder open in Windows Explorer, or a file from that folder, will prevent you from changing this attribute. – vgru Aug 21 '14 at 12:04
  • it's non GUI thread and it's a heavy lifting thread that does downloads / uploads in sequence.. there are over 16 such operations but they never clash.. as such it waits for items to be complete. what I suspect is that a download has only "just" finished so the lock is possibly the remains of the downloading but I am not sure. There are no other locks on the folder. – Mr Heelis Aug 21 '14 at 12:07
  • But what's the point of setting last write time? Are you using this for some kind of internal syncing, or is this really a requirement? – vgru Aug 21 '14 at 12:12
  • @Groo it's a question about what process is directory locking – Mr Heelis Aug 21 '14 at 12:14
  • That's probably better suited for [SuperUser](http://superuser.com/) then (since you're actually only using `Handle` and `FileUtil` to find what is locking the folder). – vgru Aug 21 '14 at 12:33
  • sigh.. it's actually pretty simple, but since you've decided to force me to go into unnecessary detail: I want to download a folder and make sure that the last modified date is the same as the source folder not when the download happened, it's a c# question nothing to do with file management per se - it's exactly the same as the linked (SO) question but it needs to be for folders not just file – Mr Heelis Aug 21 '14 at 12:33
  • Why do you need to call handle.exe programmatically? Can't you just call it from the command line to diagnose which process is locking the directory? You will then have a better understanding of the problem and what the permanent fix might be. What extra is calling it programmatically going to give you? I also like Process Explorer (http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx) for finding what is locking what (and other things--it is a Task Manager replacement). – Polyfun Aug 21 '14 at 12:40
  • @ShellShock because the lock isn't there when I look for it - I actually specifically say this in the OP – Mr Heelis Aug 21 '14 at 12:44
  • can we just cancel this question I am not interested in repeatedly having to justify my question to people who can't/won't give an answer! I think SO has destroyed the ability to ask sensible questions: like "hey you know that you can get a file lock information, we how about you help me get folder lock information the same way" that is a easy question (probably not an easy answer, but an easy question) and nothing has come back but me having to justify the question; it's a total waste of all our time stop doing it please – Mr Heelis Aug 21 '14 at 12:46
  • I will persevere; apologies for not realising that "It is almost certainly me. but I can't see it" means that handle.exe is not reporting any locks. What does "this is the code I am actually trying to run, that continually says it is locked." mean? Are you getting an exception. If so, please post details of the exception. Also I still think it is worth giving Process Explorer a go. – Polyfun Aug 21 '14 at 12:53
  • I have updated the OP to try to cover what is going on – Mr Heelis Aug 21 '14 at 15:01
  • @ShellShock it was (it seems) a wild goose hunt or a red herring :-/ I first got a lock error, I then introduced a tonne of protective code - but the lock error was legitimate: it was me having mouse focus on the explorer window and the tonne of protection code was faulty and thereby replicated an error every time that said there was a fault but there want't - it HAD been changing the datetime – Mr Heelis Aug 21 '14 at 15:15

0 Answers0