LabVIEW
Renaming files (Save As: Rename) doesn't work if you only change capitalization
@Bob_Schor wrote:
I can't remember if this is a "Microsoft Thing" or a "LabVIEW Thing". What I do is two renames, "save data.vi" to "save datax.vi" and then "save datax.vi" to "Save Data.vi". That (so far) always works.
Bob Schor
That's my fix as well.
@zou wrote:
This is not a "Microsoft Thing". Works fine if use Windows API or .NET Framework.
Test VI attached.
I think it depends on the file system you are using. I'm pretty sure Windows XP and it's early version of NTFS coughed up a hairball when you tried to change the capitalization on a rename.
@Bob_Schor wrote:
I can't remember if this is a "Microsoft Thing" or a "LabVIEW Thing". What I do is two renames, "save data.vi" to "save datax.vi" and then "save datax.vi" to "Save Data.vi". That (so far) always works.
It's a Microsoft, more precisely Windows, thing. Unlike under Linux, paths in Windows are case insensitive. Modern file systems such as NTFS are case preserving and can be configured to be case sensitive, but there are so many things in Windows that are case insensitive when it is about paths, that Windows does not use the case sensitive feature of NTFS (and if it did it would get in trouble when accessing old FAT filesystems such as when using USB sticks).
LabVIEW painstakingly observes the OS case sensitivity for paths, using according path compare functions that are case insensitive on Windows and case sensitive on everything else. I'm not sure if LabVIEW itself does a plausibility test before attempting to rename a file or if this is simply a baked in limitation in the Windows rename file function, but it obviously causes an error as somewhere along the path the rename fails because it somehow does an old to new path comparison and fails if the equality is considered the same.
Note: Seems that George showed that the Windows RenameFile function is nowadays capable to rename files if only the case differs. That definitely wasn't always the case. And it may still fail if the underlaying file system doesn't support case preservation.
@Kyle97330 wrote:
I actually use a different but similar method, because while what you have listed works in Windows, it doesn't affect source control.
We use SubVersion, so instead I:
- Close LabVIEW
- Ensure the file has been committed in its most recent form and location
- Delete the local file
- Go to the repo-browser in TortoiseSVN
- Rename the file with the correct capitalization there
- Run "Update" on the code folder to get the file back, with correct capitalization
This not only fixes it on my PC, but on any other PC the file gets downloaded to later. If you don't do it this way, the "wrong" capitalization might go into your repo and be there forever.
Some (git) SCCs are case sensitive (by default). See How to make git ignore changes in case? - SO (I never tested it's effect).
The default is much worse than "doesn't effect"... Changing only the case does actually effect SCC, in a bad way.
Windows sees one file, SCC see two. So if you have A.vi in Windows and SCC, and rename it to a.vi (with trickery in LV), changes are SCC sees 2 files, A.vi and a.vi.
This can lead to real mysteries.
When you check out, SCC will check out A.vi, then a.vi, overwriting A.vi (or vice versa).
What I do is include SCC in the LabVIEW trick:
+ Rename with extra character (A.vi to Aa.vi)
+ Commit (A.vi is removed, Aa.vi is added)
+ Rename to other case (Aa.vi to a.vi)
+ Commit (Aa.vi is removed, a.vi is added)
Search LabVIEW like a graph!
@zou wrote:
This is not a "Microsoft Thing". Works fine if use Windows API or .NET Framework.
Test VI attached.
Note that LabVIEW's move works fine too.
