Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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?

share|improve this question

migrated from stackoverflow.com Dec 25 '11 at 4:27

This question came from our site for professional and enthusiast programmers.

7  
This is probably file system virtualization. –  Raymond Chen Dec 25 '11 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 '11 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 '11 at 5:49
3  
@kreemoweet - You should post that comment as an answer. –  Nifle Dec 25 '11 at 11:27
    
Please answer your own question and accept it to close the issue. –  vonbrand Jan 29 '13 at 19:20

3 Answers 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.

share|improve this answer
1  
Note that since filesystem virtualization is a compatibility measure, turning it off may break some legacy applications. –  Harry Johnston May 17 '12 at 1:02

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.

share|improve this answer
    
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 '11 at 3:50
    
@CarlParker - please also check the link to the Cygwin documentation that I just added to the answer. –  ziesemer Dec 25 '11 at 3:54
    
What's with all the downvotes here - for both answers? –  ziesemer Dec 25 '11 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 '11 at 21:47

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

share|improve this answer
    
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 '11 at 5:47
    
The Program Files folders are not subject to WOW64 redirection. –  Harry Johnston May 17 '12 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 '12 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 '12 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 '12 at 16:50

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.