View Full Version : VEDIT Ver. 6.21.3 loses files

December 10th, 2011, 04:52 PM
I've been using VEDIT (32-Bit) Ver. 6.21.3 for Windows 09/12/11 for while, after using 6.20.1 for a few months on Win7 Home Premium 64-bit system, and had the occurrence of it losing a file, something I've never experienced in using Vedits since 1987. I changed the backup method from .BAKs in the same dir to using the Vedit backup dir, and also to lock the files rather than share. And it happened again. Trying to save the file-to-vanish gets a message that the backup file cannot be created, followed by the message that it is locked by another program, which it couldn't be since they were both .cmd files that had finished running and closed their command windows before I attempted to edit the files again. After waiting a few seconds, the file vanishes, along with its backup, and is not seen in the Recycle Bin, or findable by those recovery utilities.

I'm way past my official support period, but want to mention this as an FYI.

Now I know that when I see those error messages, I need to save the file with a new name, to avoid it vanishing entirely.

The files are named run.cmd, in several directories. and are edited via the right-click context menu, Open with Vedit.
I've had my Instance control set to 1, and will now try it as 0.

It almost happened again. Instead of Windows own Explorer, I use a 3rd party alternative called XYplorer. It shows the actual file size in bytes, unlike Explorer, and has two panes to operate in. This time I had the windows of the open applications arranged differently, and went to close XYplorer, and saw that Vedit was open behind XYplorer, so maybe the "other" application wrestling with the file is another instance of Vedit.

Since this Vedit was installed via the .zip files, and as the Windows type installation that used the common files area for config storage, I decided to unistall, and re-install from the .exe, and as the traditional C:\Vedit structure. When I went to enable the "Open with Vedit" context item, Vedit replied that it "is not currently available under Vista/Windows 7". So using that Open with Vedit context menu wasn't supposed to be possible, in the first place, which means that I shouldn't have been using it. But it had seemed to work OK before ver. 6.21.3.

December 14th, 2011, 06:54 AM
a message that the backup file cannot be created, followed by the message that it is locked by another program, which it couldn't be

I did get that message on my Windows XP system from time to time as well in the last years.
Unfortunately it wasn't reproducable at will.

Haven't seen it for some time now - but I'm not using Vedit on a hourly basis any more ...

December 14th, 2011, 04:40 PM
I have heard of an occasional problem, but nothing anyone nor I can replicate.

Does your problem happen with anything other than these .cmd files that you are executing?

Also, since your problem is occurring in the current version, it doesn't matter if your support period is expired; we are eager to fix any problem we can replicate.


December 14th, 2011, 06:08 PM
The install of ver 6.21.3 via the unzipped zip files didn't go smoothly, so it may have been faulty. It was upgrading the previous version, so maybe the vshellx.dll usage was from then. XYplorer is a 32-bit application, so 32-bit shell extensions work. The conflict may be that access to C:\ProgramData\ is not as assured as Vedit may want.

I'm sure the run.cmd's were finished executing before editing them again. I also had other text files of output open at the same time.

The re-installation of ver 6.21.3 via the .exe into C:\vedit went smoothly. I made my own "Open with Vedit" context item the old-fashioned way, via the registry, HKCR\*\shell\Vedit\command. I haven't had any trouble yet, but haven't done as much editing as I was doing that day. And I didn't seem to have any trouble at all before ver 6.21.3.

December 15th, 2011, 07:17 AM
We learned long ago to not trust the Windows-prescribed folders for many functions.
(We have never kept our documents in MyDocuments.)

And, since Vista, we learned it is best to not install to Program Files for many programs.

Our shipping installs do NOT install to Program Files...
And, since we are not doing anything maliciously, Windows does not need to protect our users from anything...

December 15th, 2011, 05:12 PM
Getting "older" type programs to work in the new Vista/Win7 scheme is a whole science unto itself. Ideally Vedit itself would be made to work with the new scheme, or some built-in Win7 compatibilty troubleshooting setting should be determined, or the more extensive Application Compatibility Toolkit settings. Other tools like LUA Buglight might shed some light. Something should be said in the readme's or whatsnew's about 32-bit vs 64-explorer shell extensions issues. Maybe the non-DDE way of "Open with Vedit" should be offered as alternative, as I did myself. I haven't made any effort to try to find what went wrong with my install. The "Program Files" type structure works OK in XP, but I'm using C:\Vedit in Win7, to be safe, as I also am used to directly working with all the Vedit directories.

December 18th, 2011, 09:18 PM
Well, it happened again, even with the traditional C:\Vedit installation described above. I went in to one quick edit to a run.cmd that I'd run and saw a the pause that some parameters were set wrong, got that cannot create backup, another program has the file error, that zapped run.cmd and its backup out out existence.

As mentioned, my own Open with Vedit is done by:
@="Open with Vedit"

@="C:\\vedit\\vpw.exe \"%1\""

I've for set "VEDIT=-s" set in the environment variables, and backups going to C:\Vedit\backup\, with locked/no sharing files set.

December 19th, 2011, 04:29 PM
Some more details about my setup:

Vedit Dashboard Report
Report Generated: 12/19/2011
Vedit Version Info : VEDIT (32-Bit) Ver. 6.21.3 for Windows 09/12/11
Vedit support period has expired
Vedit is running under Windows 7
Vedit HOME folder location: c:\vedit
User HOME folder location: c:\vedit
Vedit Macro folder location: c:\vedit\macros
User Macro folder location: c:\vedit\user-mac
Vpw.exe location: C:\vedit\vpw.exe
Vedit.ini location: c:\vedit\vedit.ini
Startup.vdm was executed on start of Vedit
Location of Ustartup.vdm is c:\vedit\user-mac
Use of UStartup.vdm is turned off
"As installed" backup copy of Ustartup.vdm is located in
Backup Mode : Copy original version to c:\vedit\backup
Name of Tool Menu is: &Tools
Name of User Menu is: &User
Use of file configuration event macro is disabled
File Configuration Event Macro is loaded in T-register 115
Use of file open/close event macros is disabled
File Open Event Macro T-register (110) is empty
File Close Event Macro T-register (111) is empty
File Pre-Open Event Macro T-register (112) is empty
File Post-Close Event Macro T-register (113) is empty
File Buffer Switch Event Macro T-register (114) is empty
Double Click Event Macro T-register (116) is empty
Edit Session Restore is disabled
This report saved as Dashboard.txt in c:\vedit

(In the original attempt at this post, I had output from cacls.exe and SetACL for the C:\vedit and C:\Utilities directories, where the run.cmd files are being edited, but the board rejected the messages saying I had 16 images and/or videos, while the maximum is 4, so I removed the cacls.exe output.)

December 19th, 2011, 04:46 PM
Now I'm trying to find a way to cause the problem.
In my C:\Utilities\SetACL directory, I made a get.cmd file torun SetACL on the c:\vedit dir to log the permissions. I put a pause at the end, so when the get.cmd file is clicked to run, it stays on the screen.

With XYPlorer as my file manager, I let the window stay open, meaning get.cmd is not released yet, and editited the file smoe more in Vedit. After a few cycles of this, never closing the command window that get.cmd opened by letting the pause end, I eventually got the "cannot create backup file" message, with get.cmd vanishing when the command windows were finally allowed to close.

Trying the same in Windows Explorer wound up the the get.cmd file "Access is denied", then it vanished.

So this is a way to make Vedit lose the file.

December 19th, 2011, 05:06 PM
Have you had this problem with a more benign file, such as a plain ol' .txt file or somesuch?
Might it be because the .cmd file has some particular Windows attributes that may be not readily apparent?

December 20th, 2011, 11:48 AM
Have you had this problem with a more benign file, such as a plain ol' .txt file or somesuch?
Might it be because the .cmd file has some particular Windows attributes that may be not readily apparent?

Exactly. .cmd might be treated as an executable or dangerous file type. I think either Windows or your antivirus is blocking it.

December 20th, 2011, 05:43 PM
A .cmd is a text file, with a .cmd extension, which is like a .bat file. They are files I create, using Vedit, and it a directory I also create.
The .cmd file that gets lost has been executed and edited a number of times before it cannot be backed up, and then disappears.
If Windows or an antivirus were to block it, why wait until the file has been executed and a edited a few times before taking action?
The issue seems to be who is "in charge" of the file, after the execute/edit cycles.
(My antivirus program is GFI/Sunbelt's VIPRE Premium, and is very controllable.)
I have been doing the edit/execute thing with batch files since somewhere around DOS 3.
This board somehow won't let me post xacls or SetACLS output, or I'd show the permissions listings on the files and directories involved, but since they are created by me, and not in the restrictive Windows or Programs Files areas, there shouldn't be permissions issues at play.

May 8th, 2012, 10:07 PM
a message that the backup file cannot be createdThis has been quite common with at least one of my computers. I am fairly certain this has been witnessed on XP SP3 (x32) and Vista x64. However I have always used create bak files in same location as original.

Have you had this problem with a more benign file, such as a plain ol' .txt file or somesuch?Yes. In my case there was nothing special going on with locks or permissions AFAIK.. Shouldn't have been.

Over years of dealing with that error, I had somewhat narrowed down a pattern of use which -seemed- to be related. The best I can recall the problem was pronounced with creation of new files. I'd do a lot of copy -> paste -- grabing privacy policy text and such, often quite long, pasting them into an unnamed vedit buffer. I'd then commence to name and save and get the error.. IIRC this was at least one situation where the 'backup cannot be created' problem occurred for me.

..if memory serves, it wasn't only on huge pastes like legal text and such but I may be mistaken.

I always considered it a bug with vedit but just never spent the time to nail down a consistent recreation procedure. I also just dealt with the problem since (to further confirm the cut-paste into empty vedit) the work-around after the error was easily dealt with by simply re-pasting the windows clipboard in notepad or doing rmb -> new text file on the desktop and pasting the clipboard into a pre-created file.

Since this is apparently afflicting the latest vedit I am going to try and pay attention if/when I see this error.


June 27th, 2012, 05:58 PM
The problem happened again last night, with a cycle of editing a .cmd file to test the arguments for an executable.
I am now running Pro64, with a current SSP, on the same Win7 Home Premium system, with C:\Vedit for vedit.
My system differs from the usual due to using that sourceforge Classic Start Menu, and XYplorer (paid).
Since I anticipate the problem, I use XYPlorer's "Duplicate" function to make a quick copy of the file with an increment number before executing the .cmd file.
When Vedit can't make the backup, and both the original and .BAK vanish, I have the duplicated file as a functional backup.
Reading in passing elsewhere implicates the Windows cache, but I recall having the problem with Vedit very rarely over the years.
It is only now, where I have some edit, test, edit some more cycles on .cmd (batch) files that really triggers it consistently.

Update Sat 6-30: After executing a .cmd file that was all REM statements, I went to edit it to remove REM from the line with the excecutable, and upon trying to save the file, got Vedit's cannot create backup file.

July 2nd, 2012, 07:41 AM
I have seen those "cannot create backup file" errors with Vedit sometime, too.
The reason was that some other program had locked the file.
Maybe the program that runs the .cmd file (XYPlorer?) locks the file and only releases it after some delay?

July 2nd, 2012, 08:26 PM
In a test I posted about earlier, the problem still happens when using Windows Explorer .
So there seems to be a conflict with Windows over who is in charge of the file.
What puzzles me is how both the original file and the backup can vanish, as if they never existed in the first place.

ian binnie
July 3rd, 2012, 08:06 PM
In a test I posted about earlier, the problem still happens when using Windows Explorer .
So there seems to be a conflict with Windows over who is in charge of the file.
What puzzles me is how both the original file and the backup can vanish, as if they never existed in the first place.

I am not so sure that file ownership is the cause.

I used to lose files this way (on XP).
This seemed to happen when I had created a new file and copied/pasted from other sources then tried to save it (or maybe it was just more annoying when you have lost half an hour's creative work).

There may be some problem with access to the backup directory, but I still think it is an internal vedit problem.

I developed a habit of copying to clipboard before doing any new save.

I haven't noticed this recently, but then I only use vedit infrequently these days when I need to run a macro.

July 4th, 2012, 08:04 PM
As a test, I alternated between Vedit run from the desktop icon, and the donothing.cmd file run from a command prompt, using the up arrow to recall the previous execution.
Each edit added one more "REM" line for the command file, so it was 1, 2, 3, 4, 5, 6, 7, and 8 lines long, executed each time.
The file didn't disappear, so the problem must be in how Vedit is called to edit the file while in Windows Explorer or XYplorer.
The command shell I would normally use to execute the working command files would be one created by XYplorer.

The next time I do a cycle of edits and executes, I will run Vedit from the destop icon, and use a command shell from that icon on the desktop, so see if I have files disappearing files under those circumstances.

July 5th, 2012, 08:05 PM
On the very real command file that I am tuning the syntax on for running a program with command line options, using the method described above, where I use the desktop shortcut to Vedit to edit the file, and execute it from a command prompt also starting from desktop shortcut, I did seven edit and execute cycles, without having the unable to create backup problem.
So this points to something happening at the running-Vedit-from-the-explorer-context-menu level.
Since I had this happen in a test case with Windows Explorer, I hesitate to blame my XYplorer alternative explorer.
(They have a very active forum where the minutest bug seems to be readily discovered and addressed.)
I'm thinking that there must be some underlying Windows issues at play.

July 8th, 2012, 01:01 PM
One idea that I just tested was to turn off the creation of backup files, by setting that option to zero.
Redoing that donothing.cmd file of just REM statements, on the second editing attempt, via the right-click context menu in XYplorer, I got the error message:
I then chose to Abandon, and upon exiting Vedit, the donothing.cmd file was gone.

My next step was to uncheck that "Lock files (no sharing) when opened" and see if Vedit will play nice with whatever the "other" program is doing, and either let me bow out gracefully, leaving the file untouched, or possibly let me take control of it and successfully edit it.
That also got the error message show above, and Abandon still resulted in the file vanishing.

Trying the same experiment in Windows Explorer got the same result.

Watching a cycle with Sysinternals Process Monitor showed my VIPRE Internet Security 2012 taking an interest in the operation, and since making a file disappear into its quarantine is what happens when it doesn't like an executing file, I temporarily disabled the Active Protection, but still had the file disappear. (Normally when VIPRE quarantines a file, it gives a message, and I can find the file in the quarantine area.)

The only clue I've seen so far is the log entry:
explorer.exe Createfile C:\tmp\donothing.cmd DELETE PENDING
What would trigger any sort of deletion activity?
A Google search finds something about explorer.exe not releasing file handles.

Another thought is that somehow cmd.exe is not letting go of the file.
Another search found this item:
"Why would SYSTEM continue locking executable file handles after the app has exited?"

And I do have that Application Experience service disabled, which I've seen implicated in some of the related problems.

Re-trying the edit then execute cycle, but waiting several minutes between the execution and the next editing, resulted in the file not being deleted.

Reading a bit more, it seems that there are problems running Windows 7 with Application Experience disabled, so I will re-enable it.


July 20th, 2012, 10:59 AM
There is a little utility "unlocker" (Google unlocker ccollomb) which will tell you if a file is locked and by what. I have used it for a couple of years on Win7/64 with no problems and found it handy for situations just like this.


October 9th, 2012, 07:05 PM
Since I made the change above, I've edited and executed many .cmd (aka "batch") files from XYplorer without any problems.

But today, in preparation for updating Flash, I wanted to edit again the file located at:

Knowing that it shouldn't work (since I'm running Win7), I used the existing non-admin instance of XYplorer to attempt to edit the file.
Upon deleting the target line, the attempted save got that cannot make backup error message, and the file vanished from:

Unlike the vanished .cmd files from when I had that problem, the edited files were found in the two locations:
C:\Users\Reed\AppData\Local\VirtualStore\Windows\S ysWOW64\Macromed\Flash\mms.cfg

For a *user* to delete a file from the system32 dir, a UAC prompt needs to be ackowledged.
How was Vedit able to remove a file from there *without* a UAC prompt?

December 2nd, 2012, 12:23 PM
As it turns out, I really wasn't editing in C:\Windows\system32, but C:\windows\SysWOW64 due to using a 32-bit file browser (XYplorer) rather than Windows Explorer which is 64-bit.

To get to the actual System32 directory, I need to make the Sysnative alias as described at http://msdn.microsoft.com/en-us/library/windows/desktop/aa384187%28v=vs.85%29.aspx