+ Reply to Thread
Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 23

Thread: VEDIT Ver. 6.21.3 loses files

  1. #11
    Quote Originally Posted by folioite View Post
    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.

  2. #12
    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.

  3. #13
    Quote Originally Posted by ReedD View Post
    a message that the backup file cannot be created
    This 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.

    Quote Originally Posted by folioite View Post
    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.

    John

  4. #14
    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.
    Last edited by ReedD; June 30th, 2012 at 04:15 PM.

  5. #15
    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?
    Pauli -- Using Vedit 6.24.2 on Windows 7 Enterprise (64 bit) and on Windows 10 (64 bit)

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

  7. #17
    Quote Originally Posted by ReedD View Post
    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.
    Ian Binnie

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

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

  10. #20
    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:
    CANNOT CLOSE FILE (LOCKED BY ANOTHER PROGRAM?)
    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?"
    http://superuser.com/questions/26037...e-app-has-exit

    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.

    PROBLEM SOLVED.
    Last edited by ReedD; July 8th, 2012 at 06:23 PM.

+ 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