FileUtils.touch does not update the mtime of directories on Windows

Some further investigation showed that the problem is in the jnr-posix library. It attempts to use the _utime64 function from msvcrt. The documentation of this function clearly states this does not work on directories. I've modified the windows posix implementation to use SetFileTime instead of _utime64 (see attached patch). This works on both files and directories.

Patch looks ok at a quick glance (needs a reformat to comply with std java formatting, and it has a bunch of whitespace-only changes that should be removed), so VVSiz can test and apply it.

Will take a look. Interestingly enough, I have FileTime class here locally for other needs as well (WinAPI-based fsat impl).

I'm not that familiar with jaffl, I've only used jna up until now. There's a couple of things missing in the patch that you might want to add:

• I couldn't easily find out how to do typedefs in jaffl. CreateFile and CloseHandle require a HANDLE, but for now I've used int instead
• It wasn't 100% clear to me how to handle the case where CreateFile fails
• I added a bunch of constants to the WindowsPOSIX class, you might want to move these to the jnr-constants project instead

This bug is blocking the Apache Buildr release 1.4.
I ran specs with the patch and it fixed all our failing specs on Windows XP. We still have a few oddities on Windows 7 but we can defer them.
Can we include this fix in jruby 1.5.1 please ?

I was going through the MSDN documentation on CreateFile yesterday and noticed there are some limitations with the ANSI variant that is exposed in the patch. Besides being restricted to the ANSI charset, it also has a limited path length of 256 chars. I'm going to work on the patch a bit more today to use the unicode variant instead, this allows the full 32k path length that FAT32, NTFS and so on support.
I'll have a look at the CreateLink function as well while I'm at it. I didn't check yet in the docs, but that one might have the same limitations.

Pepijn, thanks for this great effort! I'll be standing by waiting for your new code. And if you could remove the whitespace changes from the patch, that would be even better.

I'll give it a try, sorry about that. IDEA keeps on insisting on putting these in when I create a patch.

Superset of dir_mtime.patch

• Uses unicode instead of ansi variants of win32 methods
• Absolute paths are converted to 'extended length' paths (i.e., \\?\ prefix is added)
• Retrieve UTF-16LE charset up front to avoid having to handle unsupported charset exception everywhere
• Added some additional test cases for utime, link and mkdir
• Removed newline changes

BTW, you might want to add a comment pointing to http://msdn.microsoft.com/en-us/library/aa365247 in 'toWPath' to explain the '\\?\' black magic...

If it is not possible to get the wide variant working by Friday morning/noonish Minnesota time we may just elect to go with the non-wide version for 1.5.1 and then use the wide version for 1.6. We really want to put out 1.5.1 this week since Railsconf is next week and the non-wide version probably is "good enough" for most users.

With that said it would be double plus awesome to get the right patch in! Obi-wan you are our only hope...

Charles,
Yes dir_mtime2 contains the wide version. The logic I put in is this:

• Check if path is absolute
• If absolute prepend '\\?\'; AFAICT this converts a win32 path (C:\...) to an NT path internally (\device\...)
  This needed to get extended maximum path length
• If relative don't touch it
• Append a nul char
• Convert to UTF-16LE

As for production readiness; I've written a couple of unit tests and those pass on windows XP. I did not have much time to do much more extensive testing than that I'm afraid.

This is fixed on master and for JRuby 1.5.1. I had to make a couple of changes to the submitted patch: 1) It used the Java 6-only API for encoding so I backed off to Java 5 version of String. 2) It used "\\\\?
" and since JRuby internally normalizes files internally as forward-slashes I reversed this string to "//?/". It appears that Windows 7 does not tolerate mixed forward and backslashes.

Those two small issues aside, this patch was great work and we really appreciate people rolling up their sleeves for windows bugs...

Kudos from the Buildr team on the hard work on this one. Thanks Pepijn!