VSS and SQLCMD temporary files

[bakdo03]

VSS is Visual Source Safe, and SQLCMD is Microsoft Command Line SQL utility.

I have UE associated with SQL scripts (*.sql)

I have seen this problem in a couple of applications: I use 'view' in VSS which doesn't extract a physical file to look at an old version of file that is associated with uedit32.exe When UE opens, it says temporary file xxxx is no longer available, do you want to keep it open in the editor.

I also just ran into this when trying to use UE as the SQLCMDEDITOR in Sql Server 2005 SQLCMD which allows you to assign an editor to edit your command line query. UE displays the "file is no longer available" message, and when you say yes keep it open, it must be explicitly saved when you exit. Normally this is transparent, when you close the file, if it isn't saved, it prompts you to save, and returns the edited text back to the command line.

I try notepad as my tool for VSS or SQLCMD, and the "file is no longer available" message doesn't appear, or at least notepad is able to implictly save the file to the original location.

I am a long time US user, and I have seen this behavior in VSS / UE for several versions.

Thanks,

[Mofi]

I don't know VSS or SQL. According to your description it looks like using "view", the file or whatever is temporarily saved into a file to a folder, then the editor is called to open the file and then the file is deleted by VSS or SQL before the edited file is closed. If this is true, then VSS or SQL make it wrong.

For example when I have open a RAR archive with Total Commander (my favorite file manager) and press F4 to edit it with UltraEdit, Total Commander (short: TC) asks me, if I really want to extract the current file to a temporary folder and start (edit) it. If I click Yes, then TC unpacks the file to %temp%\_tc\ and starts UltraEdit with the file in the temp folder as command line parameter. Next I can edit the file and do whatever I want with it. TC waits until I have closed UltraEdit. After editing is finished and I have saved the file and closed UltraEdit, TC gets back the focus. TC now checks if the file in the temp folder has been modified (last modification date changed) and if this is true, it asks me if I want to pack the modified file to the RAR archive updating the existing file in the archive. Last TC always deletes the temporary file.

In your case it looks like VSS and SQL are deleting the file before you have finished the editing session with UltraEdit. You can use for private usage free Filemon from SysInternals to log what is happening on your hard disk when you view a file.

Why is there no problem with Notepad?
I think, because Notepad does not detect if a currently opened file is deleted in the background.

In UltraEdit you have several configuration settings at Configuration - File Handling - File Change Detection to customize the file change detection. For example you could enable Ignore file changes if the file was deleted.

[johnnygreenapple]

I have the exact same symptoms the original poster described, and I do believe it's caused by UltraEdit's behavior. I ran filemon as suggested, and here's what appears to be happening:

1) I select "view" in VSS to open the file in UltraEdit
2) VSS creates the file under C:\Temp
3) UltraEdit opens, reads, and *closes* the file
4) VSS deletes the file (since it thinks the application is done with it)
5) UltraEdit throws out the "<file> has been deleted, or is no longer available" warning

I can watch this activity in C:\Temp. When UltraEdit is the application selected as the file viewer, the file is created in C:\Temp and immediately disappears. However, when I designate other applications (Notepad, Wordpad, MS Word) as the file viewer in VSS, the file is created in C:\Temp, and it persists until that application closes the file.

As the original poster commented, this entire experiment is repeatable in SQLCMD instead of VSS. The problem seems to be that UltraEdit prematurely "closes" the file when it's actually still in use.

I *love* UltraEdit, but this behavior is a huge annoyance. It seems to be worse since I upgraded to v13+, but that could be my imagination. Any chance of a fix or workaround?

[Mofi]

By default UltraEdit uses itself a temporary file for every file opened. UltraEdit works with the temporary file instead of the real file which gives other applications the possibility to modify the file while UltraEdit has it open, for example when UE is mainly used for viewing a file and not for editing it. For more details read the IDM power tip Temporary Files.

Maybe in this situation it would help to enable the configuration setting Lock file for write while editing at Advanced - Configuration - File Handling - Miscellaneous what other editors by default do to prevent other applications to modify the opened file when loaded for editing.

Also I used Filemon to log how Notepad opens files. Notepad reads entire file to memory. You can delete or rename the file currently displayed in Notepad and Notepad does not recognize it. You can even edit the content of the file although it was already deleted. And you can save the modified file although the file does not exist anymore. Without being able to test it with VSS, it looks like Visual SourceSafe expects that the viewer loads entire file content to memory and VSS can immediately delete the file after viewer has loaded it.

[msvitale]

Hi,
I get an empty file in UltraEdit when Viewing from Visual SourceSafe (VSS).
I'm running UltraEdit v16.00.0.1037 on Windows 7 Professional (x64).

In Visual Studio 2005, I right click -> View a file and end up in UltraEdit with the correct filepath and filename, but the file is empty. When I monitor this with Sysinternals ProcMon, I find that after VSS builds the temp file, Ultraedit opens it, then VSS deletes it, and Ultraedit then gets an empty file. When I choose right click->Edit instead of View, Ultraedit opens the file successfully, but I must check it out of VSS to do so.

View does work when I configure VSS to use Notepad.exe instead of Uedit32.exe as my "view" editor.

I have my temp path set to c:\users\<myuid>\AppData\Local\Temp.

The following relevant options were turned off in Uedit, but turning them on made no difference:

- File Handling -> File Change Detection -> Ignore file changes if the file was deleted
- File Handling -> Miscellaneous -> Lock file for write while editing

I also have the following setting turned on. I have not changed this setting:
- File Handling -> Temporary Files -> Use temporary file for editing.

Any suggestions for me?

Thanks,
-mark

[bulgrien]

I don't have a VSS test environment. Have you tried configuring VSS to force UE to launch a new instance?

uedit32 /fni "fullpath\filename"

[Mofi]

I can only suggest to set File Change Detection to Disable or to set Temporary Files to Open file without temp file but NO Prompt and test if one of them solves the problem.

I don't know anything about VSS and therefore don't know if VSS supports special switches for the view command or for opening files in an external editor. Also if you have not specified uedit32.exe with the full name in the VSS configuration dialog try if using the full name (path + file name + point + extension) of uedit32.exe makes a difference.

It's also possible that VSS monitors the called viewer in the task list to determine when to delete the viewed file in the temp folder. If VSS works in this way, the problem is that calling uedit32.exe results in a new task, then UltraEdit checks if an instance is already running, passes the file name to open to this running instance and then terminates itself which lets VSS think the viewer closed and therefore the file can be deleted. To determine if VSS works in this way, I suggest to enable configuration setting Allow multiple instances at Advanced - Configuration - Application Layout - Miscellaneous or configure in VSS to call uedit32.exe with the parameter /fni.

[msvitale]

Thanks for the responses. Here are my results:

• I do have VSS configured with the fully qualified path to UltraEdit:
  
  "C:\Program Files (x86)\IDM Computer Solutions\UltraEdit\Uedit32.exe"
  
  This works the same with or without the quotes.
  
  
• When I add the /fni switch within the quotes (or omit the quotes), VSS fails to start UltraEdit:
  
  "error executing "C:\Program Files (x86)\IDM Computer Solutions\UltraEdit\Uedit32.exe /fni" "C:Users\<myuid>\AppData\Local\Temp\<myfilename>"
  
  
• When I add the /fni switch outside the quotes, the /fni option is ignored, UltraEdit starts fine but I get an empty file.
  
  
• When I configure Application Layout -> allow multiple instances, I do get a new instance of UE when I issue View. But I get prompted by UE that the file is
  
  "locked for write by another application and can not be locked; press Yes to continue with file read-only, or No to cancel."
  
  The file is NOT locked by anyone else. If I click yes, I can finally view the file.

So "Allow multiple instances" is a workaround, but the extra prompt and the separate UE instance limit its usefulness for me. I edit many source files all day long, and need to be able to switch rapidly between tabs, search all open files, etc.

[bulgrien]

Does using /r to tell UE to open the compare as read-only eliminate the extra "locked" prompt?

[msvitale]

/r doesn't work for me any better than /fni did; it's either ignored, or causes an error before Uedit gets launched. I think Visual SourceSafe just doesn't deal well with building a command containing switches. Or maybe there's a way to do it that I haven't figured out yet.

-mark

[Mofi]

So VSS works as I thought. It monitors the called viewer task in the Windows task list and when the viewer task is terminated, it deletes the file written to the temp folder with a write lock. That is no problem when using Notepad because calling Notepad always results in a new instance of Notepad. But when calling UltraEdit and UE is already running and it is configured that only 1 instance of UE should be active, the file name is passed to the first instance and the second instance of UE terminates and VSS deletes the file.

A possible workaround is to call as file viewer from within VSS a batch file instead of UltraEdit. The batch file contains the lines:

Code: Select all

@echo off
set FileName=%1
if not exist %FileName% goto !EndBatch
rem Remove double quotes at begin and end of filename if present.
set FileName=%FileName:"=%
rem Get file name only without path and extension and get file extension only (with point).
for /f "usebackq delims==" %%i in (`echo "%FileName%"`) do (
  set NameOnly=%%~ni
  set Extension=%%~xi
  )
copy "%FileName%" "C:\Temp\%NameOnly%_view%Extension%"
"C:\Program Files (x86)\IDM Computer Solutions\UltraEdit\Uedit32.exe" "C:\Temp\%NameOnly%_view%Extension%"
:!EndBatch

If you look on the file you see that the batch file creates a copy of the file to view with "_view" before the extension inserted and this file is opened in UltraEdit. So when the batch file terminates and VSS deletes the original file, the "_view" copy is still available for already running instance of UltraEdit. Of course using this batch file when it works requires that you delete the file when not needed anymore. You can do that from within UltraEdit by using File - Special Functions - Delete Active File via menu, icon in the toolbar or a hotkey. (I use hotkey Alt+Del for this command.)

[msvitale]

Today I tried your earlier suggestions that I had overlooked before. Disabling temp files did not help. Nor did disabling file change detection.

I have a colleague who is running the same version of UE and VSS as I am, but does NOT have any problems. I'm going to compare our configurations and see if I can get mine working that way. I'll let you know either way.

Thanks for the script, Mofi, I will try that if the config comparison does not bear fruit.

-mark

[msvitale]

Mofi, I haven't tried your script yet but I will later today. I just want to bring you up to date on what I've learned.

Unfortunately, we were mistaken about my colleague's setup working - he is seeing the same symptoms as I am. If Uedit is not running, a View from VSS will bring up the file in Uedit. But subsequent views bring up an empty file, just as I have been seeing.

The reason for this is explained above - when VSS calls Uedit it always creates a new process (PID), even if Uedit is already running from a previous call. The new Uedit PID does some work and then exits, so VSS deletes the temp file thinking that Uedit is done with the temp file. However, the old Uedit PID then tries to open the temp file but it's been erased - thus we get an "empty" file.

I went back to my old laptop running Uedit 9.10b and verified that Uedit worked differently back then; when Uedit is invoked and it is already running, it runs under the existing process (PID) instead of starting a new, temporary PID. Therefore, VSS never deletes the temp file.

This is how I need the current Uedit to work with VSS - just as it used to before I upgraded my laptop and Uedit. Can you tell me what release Uedit started working this way? Perhaps I can back-level to a previous release.

Thanks for your good support so far,
-mark

[msvitale]

Mofi, your script works fine, thanks again. It has the drawbacks you mentioned (batch file "flash" and manual delete when done), but it's a good workaround for me for now. I'd still like to learn when this behavior started so I can consider a downgrade, or perhaps ask the developers to restore the former behavior.

Regards,
-mark

[Mofi]

Can you tell me what release Uedit started working this way?

As far as I know the process ID is assigned by the operating system (= Windows kernel) to a new process and the applications can use only the function GetProcessId. There is no function SetProcessId. On your old latop you are surely not using Windows 7 x64. Perhaps the old laptop is running with Windows 98 SE which handles PIDs different.

You can easily verify if I'm right with my assumption. Copy into a new directory C:\Temp\UltraEdit9\ UltraEdit v9.10b with all its files in the program directory from your old laptop. Copy from the Windows directory of your laptop the files uedit32.ini and uedit32.kbd (if present) also into directory C:\Temp\UltraEdit9\ on your new computer. Close all running instances of new UltraEdit and set in VSS C:\Temp\UltraEdit9\uedit32.exe. Now start UltraEdit v9.10b first time manually and then execute the command view from VSS. What happens?