The big problem for me is that File.Copy copies the read-only bit the first time, then fails when trying to overwrite the read-only file the second time. When building using references from CVS, we tend to overwrite read-only files often. I really need this behavious for my SolutionTask.
This code path is only triggered if the user specifies "overwrite". I would imagine that the user wants the file overwritten, no matter what the state of the read-only flag.
Grr... Very annoying behaviour on .NET's part. :)
Philip Nelson wrote:
--- Matthew Mastracci <[EMAIL PROTECTED]> wrote:
This fixes the problem with read-only file destination for the <copy> task. If noone objects, I'll check this in.
snip
> if (File.Exists(dstPath))
> File.SetAttributes(dstPath, FileAttributes.Normal);
I would *love* to have this in but I would worry about performance when the file set is a network share instead of the local file system. I currently use the attrib task to accomplish the same thing. That would be almost as good if we had (maybe we do now?) fileset references like Ant does.
Since the copy task only copies over older files, if the attribute was only reset if the file was actually going to be copied it might be OK. I tend to think it should still be optional though because some people may depend on the current behaviour.
------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
