Hi your analysis seems correct, I'll see what I can do to fix it. but it is indeed a strange time settinng behaviour of windows.
There is a patch pending of robocopy, and that seems to have better functionality this is however not yet included in the trunc :-( http://jira.public.thoughtworks.org/browse/CCNET-1091 maybe you can try it out with kind regards Ruben Willems On Fri, Feb 20, 2009 at 7:12 PM, Jeremy <[email protected]> wrote: > > Update: > > I found a quasi-solution to my problem, but it doesn't make sense. > The network share is on a network computer that runs Windows Server > 2008. Here's what I did to fix it: > 1. First, I logged into the remote computer, and went into the > advanced sharing options for the "Share Directory" shared folder. I > changed cashing so that "Files or programs from the share will not be > available offline." This didn't seem to help. > 2. Second, I shared the "subdirectory" folder as well. Still, it > didn't work. > 3. Third, I pointed the repository root to point directly to the > "subdirectory" folder that was now shared, like this: <repositoryRoot> > \\RemoteComputerName\subdirectory</repositoryRoot> > Previously I had pointed through the other shared folder: > "\RemoteComputerName\Share Directory\subdirectory" > > Bingo! That third step made it work. It would actually notice when I > changed files. This doesn't seem to make sense, though because > sharing the "Share Directory" folder should open up all sub folders to > sharing. I had my share and file permissions set to be wide open for > "Share Directory," so changing the setup using the steps above should > not have made a difference. Thoughts? > > Another possible bug is that, even now that is is working, it doesn't > seem to catch all changes that happen to a directory. For example, > consider this sequence of events: > 1. You create a file named asdf.txt and give it some content. > 2. CCNET performs a check on a filesystem sourcecontrol directory that > is is watching, and doesn't notice any changes to the directory. > 3. You copy the asdf.txt file to the filesystem sourcecontrol > directory. > 4. CCNET performs a check on the filesystem sourcecontrol directory, > and doesn't notice any changes. <-- I tried it out, and this > happened. > > This seems wrong, until you look at the properties of the file that > you copied to the filesystem sourcecontrol directory, you'll see that. > * The created date and accessed date of the file are the date and time > that you copied the file to the filesystem sourcecontrol directory. > * The modified date is the time that the file was originally created/ > edited by you, before you copied it. So, it's actually modified > before it was created/accessed, according to the file's properties. > > It seems like CCNET only checks the modified date on the file, and > since it sees that the modified date for that file is prior to the > time of the previous build, then it considers it to be up to date. Is > that how it works? If so, then there is a flaw in the filesystem > sourcecontrol strategy. I can't be sure that CCNET will detect new > files, or changes that occur prior to the previous check. This is > troubling, because CCNET's filesystem sourcecontrol block is what I > need to use for my build approach. > > Thoughts? > > Thanks for your input, > Jeremy > > > On Feb 19, 4:45 pm, Jeremy <[email protected]> wrote: > > I set up a filesystem source control block in my ccnet.config file. > > > > <sourcecontrol type="filesystem"> > > <repositoryRoot>\\RemoteComputerName\Share > Directory\subdirectory</ > > repositoryRoot> > > <autoGetSource>true</autoGetSource> > > </sourcecontrol> > > > > For some reason, CCNET does not see changes to files that change in > > the "subfolder" directory. It continues to say that no changes are > > detected. It doesn't matter if I force the build, or let CCNET > > perform the check through a timed trigger. > > > > To diagnose the problem, I tried pointing the repository root to a > > local folder on the same computer where CCNET is installed, and it > > detected the changes fine and downloaded the new files. This seems to > > indicate that something isn't right with the network share that I am > > pointing at. > > > > I've set up my shared folder to have wide open sharing permissions, > > and security permissions to allow reading from "everyone" but still, > > it doesn't see changes to the files. > > > > Any ideas? I'm at a loss here. > > > > Thanks, > > Jeremy >
