Unable to rename pas file to versioned ~1~ file - strange issue

[Jacek Laskowski 57]

I have been using VMware Workstation for years, the host system is Windows 10, the virtual machine works under Windows 7, where I have Delphi 10.3 installed. It always worked well. External project and library files are on a disk shared by VMware mechanism called "Shared folders", in the virtual machine they are available as a network disk, which I map to the letter D:\

 

A month ago I built a new computer on Ryzen, and installed Ubuntu as the host system. Under Ubuntu I installed VMware Workstation and moved a virtual machine containing Delphi from the old computer. I've converted the disk file system with projects and libraries from NTFS to Ext4 and it's also shared by "Shared folders". Everything was ok until it turned out that I couldn't make a change in Spring.inc file from Delphi level. But for example, by notepad the change was successful. I couldn't find an explanation, so I worked until now.

 

Since yesterday I have the same problem with one of the files in my project. Trying to save (ctrl+s) changes in *.pas file ends with an error message:

"Unable to rename ...\path\filename.pas to ...\path]\__history\filename.pas.~20~"
 and the file does not save, only a copy of it with the extension *.$$$ next to the source file is created, all this can be seen in the screenshot:

 

 

It seems that the internal (Delphi) file versioning mechanism has some problem with this file. But I've been editing other files from the same project for a month now and I haven't had such problems (except for Spring.inc - outside the project).
This is not a problem of permissions in the Ext4 file system, because I checked and the permissions are identical with all the project files. I also checked the file edition with notepad and rename with move with shell command "mv" - also without any problem.

 

What can be the cause and what else can I check?

 

 

[Rollo62 536]

Quote

only a copy of it with the extension *.$$$

I have seen such behaviour when I tried to include functional code (with implementation section) from one file (.pas or .inc, doesn't matter),into another .pas file.

Instead of integrating this as a whole into the target file, I could not separately debug this, got a similar error and a non-editable file.

If I remember right, I could compile that, only opening the file while debugging caused the issue, but not sure anymore.

 

 

[Uwe Raabe 2057]

I have seen problems with shared folders in VMware when files are touched by the VM - somtimes they cannot be deleted from the hist until I restart the guest OS. I switched to local copies inside the VM and use the source control system to synchronize, so the problem is no longer existent.

 

You might consider exposing the relevant folders as normal network shares and use these inside the VM instead of Shared Folders. This usually worked flawlessly for me.

[Jacek Laskowski 57]

I've worked with Shared Folders for a decade and never had such a problem, no problem at all. Only now (after migrate do Ubuntu and Ext4) the problems have come to light, but the problem is clearly in Delphi and not in file locks, because as I wrote other tools they can modify and move these files without any problem.

[Jacek Laskowski 57]

After a few hours of fighting I discovered the cause of the problems... Maybe somebody will meet with it one day and I'll give you a solution.
As I wrote I migrated from Windows to Ubuntu and converted the disk from NTFS to Ext4. As you know Linux systems are case sensitive and so is Ext4.
Although the files had the correct name, it turned out that in the dpr and dproj files the paths to some files sometimes had the name "\Services\" and sometimes "\services\" and that was the reason.

After correcting the contents of dpr and dproj to the correct directory names, all errors disappeared.

 

[Jacek Laskowski 57]

@Uwe Raabe

 

Perhaps it would be worth adding a function to the Project Magician that will scan the project files and their paths and check if the actual paths on the disk are the same case sensitive?
I know it's not very useful for most programmers, but the workload is small, and such a feature can sometimes save a lot of time. Besides, for programmers who like to keep their projects in order (and that's what Magician is for) even if everything works, it may be important to have the correct paths.

 

[Uwe Raabe 2057]

I actually thought of something in this direction before while I was hit by a case change in a unit name (.PAS became .pas) in combination with a poorly configured version control system (originally targeting - guess what - Linux). I will increase the priority now.

[Jacek Laskowski 57]

Great @Uwe Raabe!
In that case I will add one more thing I came across. Before I was touched by the problem "Unable rename ..." I was struggling with strange behavior of the environment while debugging the code. When I pressed the F7 key while standing cursor on the line with a Spring method call, IDE went to Spring4D sources and then the weird thing happened. The cursor was standing on the first line of the unit (not in the method) and the Spring file was marked by the IDE as modified (asterisk next to the name).

I was looking for a long time for the reason before I came across that Project Magician has end of line correction option set and at the same time my git configuration under Linux didn't force the end as CRLF but Spring files had LF at the end of line!

In such a situation Magician was changing line ends and debugger was stupid. And I was with him

 

Maybe it is worth to add an exclusion path for this Magician function?

[Uwe Raabe 2057]

1 minute ago, Jacek Laskowski said:

 

Maybe it is worth to add an exclusion path for this Magician function?

I think that would be too much of a hassle, especially when you are working with relative paths and/or want to configure that on a per project/-group level. One could even throw wildcards in there to complicate things further.

 

You can either switch off that feature or make the offending files read-only.

 

BTW, I also get these LF problems with Spring4D all over the place, but I usually don't debug it. Interestingly, up to now it seems to be the only library with this hickup.

[Jacek Laskowski 57]

52 minutes ago, Uwe Raabe said:

I think that would be too much of a hassle, especially when you are working with relative paths and/or want to configure that on a per project/-group level. One could even throw wildcards in there to complicate things further.

I also use relative paths in the project, but in the end each path is absolute. And probably others, like me, have some common folder with external libraries (in my case d:\work\libraries) which as a whole could be excluded and the problem would disappear.

52 minutes ago, Uwe Raabe said:

You can either switch off that feature or make the offending files read-only.

 

BTW, I also get these LF problems with Spring4D all over the place, but I usually don't debug it. Interestingly, up to now it seems to be the only library with this hickup. 

Fortunately, git can be configured so that "on the fly" it changes the end of line characters to the ones we prefer and does not treat this as changed sources, so everything works fine. Thanks to this Spring4D has a CRLF at the ends of the line.