+ Reply to Thread
Page 1 of 3 123 LastLast
Results 1 to 10 of 23

Thread: VEDIT Ver. 6.21.3 loses files

  1. #1

    VEDIT Ver. 6.21.3 loses files

    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.
    Last edited by ReedD; December 11th, 2011 at 12:58 PM.

  2. #2
    Quote Originally Posted by ReedD View Post
    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 ...
    Used VEDIT for more than 20 years, finally 6.24.1 on Windows 7. Now I'm on Linux, without VEDIT...

  3. #3
    Join Date
    Aug 2011
    Ann Arbor, MI
    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.


  4. #4
    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.

  5. #5
    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...
    VEDIT 6.24.2, Win 10/64 Pro
    Using VEDIT daily, since 1987...

  6. #6
    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.

  7. #7
    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.
    Last edited by ReedD; December 18th, 2011 at 10:23 PM.

  8. #8
    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.)

  9. #9
    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.

  10. #10
    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?
    VEDIT 6.24.2, Win 10/64 Pro
    Using VEDIT daily, since 1987...

+ Reply to Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts