6

I'm seeing a strange interaction between vim, the Cygwin tools, and Windows7. I don't think that it is a bug, but at the same time, I have no idea how to explain what I'm seeing.

I installed Vim (from vim.org, not the Cygwin vim) in:

"C:\Program Files (x86)\Vim".

I cd'd to this directory and edited my _vimrc file using vim itself.

vim _vimrc

I added some settings, wrote the file out, and exited.

I then copied the file to a different directory to create a backup of my changes. 

copy _vimrc c:\tmp

That's when I noticed the issue. The copy of the file did not contain my changes. Much investigation followed. I will summarize the findings.

Within "C:\Program Files (x86)\Vim", I see my changes if I inspect the file with any of the following:

vim, cat, less

(Here, cat and less are the Cygwin versions.)

However, I do not see my changes If I inspect the file with any of the following:

notepad, type, more

(The commands type and more are standard Windows shell commands.)

To give you a flavor:

c:\Program Files (x86)\Vim>ls -l _vimrc
-rwx------+ 1 carlx Domain Users 936 Dec 23 21:15 _vimrc

c:\Program Files (x86)\Vim>dir _vimrc
 Volume in drive C is OSDisk
 Volume Serial Number is 6C86-85EB

 Directory of c:\Program Files (x86)\Vim

06/28/2011  02:09 PM               901 _vimrc
               1 File(s)            901 bytes
               0 Dir(s)  95,964,721,152 bytes free

The Cygwin ls command shows a different file (different date and size) than the Windows dir command.

I thought that perhaps it was some sort of issue with the casing of the filename, but specifying _VIMRC versus _vimrc to any of these commands, makes no difference.

Can anyone explain what I'm seeing here?

Improve this question
4
  • 7
    This is probably file system virtualization.
    – Raymond Chen
    Dec 25, 2011 at 3:40
  • 7
    If this is a virtualization issue, you'll find the edited file in c:\users\<youraccoutname>\appdata\local\virtualstore\program files(86)
    – kreemoweet
    Dec 25, 2011 at 5:28
  • Wow. You are correct, kreemoweet. I looked in the directory that you specified and the edited file is there. That is really strange to me. Do you know where I read more about this Windows' file system virtualization? Thanks!
    – Carl Parker
    Dec 25, 2011 at 5:49
  • 3
    @kreemoweet - You should post that comment as an answer.
    – Nifle
    Dec 25, 2011 at 11:27

4 Answers 4

Reset to default
3

As Raymond Chen and @kreemoweet pointed out above, this is caused by filesystem virtualization. To turn this off, you can use the Local Group Policy editor, gpedit.msc. Type start gpedit.msc into a command prompt and navigate to Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options. Scroll to the bottom of the right-hand window and double-click on User Account Control: Virtualize file and registry write failures to per-user locations. Change the setting from Enabled to Disabled.

Improve this answer
1
  • 2
    Note that since filesystem virtualization is a compatibility measure, turning it off may break some legacy applications.
    – Harry Johnston
    May 17, 2012 at 1:02
0

The NTFS file system typically used by Windows does support multiple files with the same name that differ only in case, as part of Windows' efforts towards POSIX compliance. Additional details are available at http://support.microsoft.com/kb/100625 . However, all of Windows (and presumably most of its APIs) and Windows-provided applications prevent this.

So likely, you do have both _vimrc and _VIMRC existing at the same time - and the standard API is only showing you one of them (not sure what logic is used to choose which one). I was going to say that vim must be using a non-standard API or calling it with a non-standard option in order to result in what you're observing, but I can't seem to reproduce this with vim alone. I would consider this a bug in Cygwin, vim, copy, or whatever it was that actually resulted in this situation - which brings a good point - did you actually use copy (doesn't exist in Cygwin) or cp?

Please also check out http://www.cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-casesensitive . There's a registry setting here that you should check, which isn't even limited to Cygwin.

Improve this answer
4
  • The Windows Copy command is what I initially used to copy the file and which resulted in the "copy" that didn't have my changes. If I use the cp command (from Cygwin), I am able to copy the file (with changes) to a different directory.
    – Carl Parker
    Dec 25, 2011 at 3:50
  • @CarlParker - please also check the link to the Cygwin documentation that I just added to the answer.
    – ziesemer
    Dec 25, 2011 at 3:54
  • What's with all the downvotes here - for both answers?
    – ziesemer
    Dec 25, 2011 at 13:09
  • I don't know what the down votes are about. Although your response was not the answer to the mystery, it was still helpful and I appreciate you responding. (And similarly to @Paul Betts, above.)
    – Carl Parker
    Dec 25, 2011 at 21:47
0

What happens if you run C:\Windows\SysWOW64\cmd.exe's dir? I bet you're being WOW64 File Redirected.

Improve this answer
6
  • Thanks. Under the c:\windows\SysWow64\cmd.exe both dir and ls still report different dates and sizes for the file.
    – Carl Parker
    Dec 25, 2011 at 5:47
  • The Program Files folders are not subject to WOW64 redirection.
    – Harry Johnston
    May 17, 2012 at 1:09
  • @PaulBetts: reference, please. This MSDN article on file redirection only mentions the system32 folder: msdn.microsoft.com/en-us/library/aa384187%28v=vs.85%29
    – Harry Johnston
    May 17, 2012 at 23:19
  • Besides, I've just tried it. Using the 32-bit cmd.exe, I looked in c:\windows\system32 and saw the contents of c:\windows\syswow64 as expected. Looking in c:\Program Files, however, does not show the content of c:\Program Files(x86).
    – Harry Johnston
    May 17, 2012 at 23:24
  • @HarryJohnston Indeed, the MSDN Library page at msdn.microsoft.com/en-us/library/bb756960.aspx seems to imply that any write to any folder can potentially be redirected by filesystem virtualization.
    – Fran
    May 21, 2012 at 16:50
0

As Raymond Chen and @kreemoweet surmised in their comments, this was a file-system virtualization issue, and I found the file in:

c:\users\<youraccoutname>\appdata\local\virtualstore\program files(86)

And that was the answer. Thanks, guys.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .