cannot overwrite file on terminal server 3

[captsnappy]

VFP9 built-to-exe running on Windows 2003 Terminal Server.
Program copies files for users. When an existing target file found (same filename), it attempts to delete target file, then copy new file to target folder.

On my development XP machine the file deletion works but not on the Terminal Server. The existing target file does not get deleted. These are graphic files. Previewing them reveals that the existing target file does get overwritten.

I have tried these variations of commands to delete the file - some found on this forum:

if fexist(gcsavefile)     && fexist is function to replace the VFP file()

* one pf these variations
* variation 1	delete file (gcsavefile) 

* variation 2	ccmdline = "del "+ gcsavefile
* variation 2	! &ccmdline

* variation 3   MyCommand = "del " + gcsavefile
* variation 3	LOCAL lcCmd, loShell
* variation 3	lcCmd = GETENV("ComSpec") + [ /C ] + MyCommand
* variation 3	loShell = CREATEOBJECT("wscript.shell")
* variation 3	= loShell.Run(lcCmd,0,.t.) 
* variation 3	* 0 to hide display, .t. to wait for completion

   copy file (thisform.ccorlogf) to (gcSaveFile)	

endif

They all delete the file on the XP dev machine but not on the Terminal server.

On the terminal server if I drag-and-drop, or copy-paste via Windows Explorer all is good, the files get overwritten.

I can not believe that this is becoming an issue with my program! Seems like a super simple function, ha.

Any suggestions will be most appreciated.

 

[EzLogic]

is the file you are deleting being locked somehow? or used? or open?
how about:

lcfile = "whateverfile.txt"
Erase (lcFile)



Ali Koumaiha
TeknoSoft Inc.
Michigan

 

[Olaf Doschke]

As you can delete via Windows Explorer it rather not seems the files are locked. The application might run under different user/rights then you. How is the start of the application configured? As the files can't be locked the only answer is access rights. What is ID()?

You can also check permissions using ICALCS (not wure this is available in Win2003, though, you might need to use CACLS instead):

!icacls "&gcsavefile" /save d:\temp\AclFile.txt

The meaning of the output is described here:

http://msdn.microsoft.com/en-us/library/aa379570(VS.85).aspx

Bye, Olaf.

 

[captsnappy]

Thanks, Tekno and Olaf. I'll try both your suggestions but I have new info that may make the file in use or ACL issues moot.

Found that if I comment out the copy file statement, the target file does, indeed, get deleted. So now I have an empty target folder. I un-comment the copy file statement. Run my program again and it finds no existing target file and copies a *new* file to the target folder. I say *new* file because what gets copied into the target folder is the *original* file, i.e., the file that was just deleted from the folder. Not the source file that is held in thisform.ccorlogf. Both files, btw, are on the TS.

This is crazy to me. And is about to drive me crazy.

I'm about to test with non-graphic files, try some txt files to see if this weird behavior holds for other file types. I'll be back with more info.

Thanks for replying.

 

[captsnappy]

OK, here's what's predictable and repeatable:

If the filename is the same as an included file in the project, the copy will always use the included file, never the one you select as the source file.

I tested filetypes .JPG, .GIF and .TXT and this holds true for all.

My initial confusion was from the silly idea to use graphic files in the project's \proj\graphics folder and that were included via the Project window: Other tab: Other Files....as the test files for the deleting/copying code.

If I remove the file from the Project, recompile to exe, the source file is indeed copied to the target folder.

Is this a known behavior? I'm VFP 9.0 SP2, the TS is Windows Server 2003 Enterprise with Terminal Services enabled.

 

[Dan Freeman]

VFP always searches inside the currently running EXE first. If a right-named file is found, thar she blows! (Next comes the VFP SET("PATH") search path, followed by the MS-DOS search path.)

So, yeah, it's known. It's by design. It goes back a long way.

 

[captsnappy]

Thanks to all, stars to all...so great to learn things the SECOND time....

 

[Dan Freeman]

Some of us are going around it way more than just the second time.

 

[Olaf Doschke]

Yes, it's true VFP first searches in an EXE. Had you said the files are included in the exe it would have been obvious. Copy File should at least copy from source dir, if you use that fully qualified name in gcsavefile and the file name isn't found in the exe, but if you just specify the file name without it's path there are also other paths foxpro could use besides it's current path. The exe is always first, as that obviously speeds many things up, if it would be menat, and it has precedence even when you fully qualify a name in many cases, as in COPY FILE, FILE() and others. Help topic on FILE() says: "Files included in an APP or EXE FoxPro application have precedence over the files on a disk. The path is irrelevant for such files. Use ADIR( ) function to locate specified file on a disk only."

You can save a bit of such frustrations and be sure there is no such precedence or search along the EXE interior ot other paths, by using the COM Scripting.Fileysstemobject, which has options to find files, copy files, move files, uses capitalisation as on disc, and even could open files as text stream. It obvoulsy isn't using VFPs precendences or default path or SET PATH. oFS = CreateObject("Scripting.FilesystemObject").

On the other side VFPs mechanism to serach more than just what is specified, helps a lot to SET PATH and then rely on foxpro to find things, prgs, vcxes etc. But actually directly addressing a file always is fastest, so I am not a fan of that mechnism myself and don't rely on it. It can also cause frustration with the use of similarly named classes and other stuff.

Bye, Olaf.

 

[Mike Lewis]

Next comes the VFP SET("PATH") search path, followed by the MS-DOS search path.

Are you sure about the MS-DOS search path, Dan? My understanding is that it will look in the EXE first, then in the default directory, and then in VFP's path, and that's it. I don't think Fox has ever been aware of the MS-DOS search path.

Mike




__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Olaf Doschke]

Mike,

The help topic on LOCFILE() supports that VFP does not use MSDOS Paths. Simple testing shows to me, FILE() does not use MSDOS Paths, the last path searched is HOME() perhaps, even if not inclluded in SET("PATH"), but not GETENV("PATH"), which is MSDOS Path environment variable.

I remember, though, that some bug of VFP7 or 8 was related to MSDOS Path containing nonexisting paths. I think this was about searching the foxruntime at the start of an exe, something like that.

Searching help I found the terms "program execution chain" and SYS(2450). But nothing about MSDOS Path usage besides output of severl commands or functions support MSDOS pathing syntax or return short 8.3 names. And some info on MSDOS Codepages.

Bye, Olaf.

 

[Mike Lewis]

Thanks, Olaf, for confirming that. I also just did a quick test. As expected, VFP failed to find a file that was present in the DOS path but not in VFP's.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Dan Freeman]

It used to search the DOS path, but admittedly I hadn't tested it in more than a decade even before they stopped development.

Having been bit by filename issues many times over the years, I just adopted a practice of NEVER ALLOWING IT TO BECOME AN ISSUE which solves the issue nicely. <g>

 

[captsnappy]

Olaf - I was including the full path of the source file in thisform.ccorlogf. And full path on the destination gcsaveFile as well. I was assuming an explicit path would be sufficient to avoid any files in the EXE. Obviously not as you and Dan have taught me.

I'll look at using the COM Scripting.Fileysstemobject from now on.

Dan - for me it began with DBaseII running under C/PM on a Heathkit computer with 8" floppies ! HA!

 

[Olaf Doschke]

Yes, a file included in the exe is also found before looking at the full path. So the full path is only a solution, when excluding anything from the EXE. Even then a file not found where expected triggers the next level of searching for a file along foxpros paths. So foxpros searching along several paths is not stopped by specifying a full path. Still it's the best practice you can do within VFP.

Bye, Olaf.

 

[captsnappy]

I've replaced all my file() and file copy statements with FileSystemObject comands, e.g.,

oFS=CREATEOBJECT("Scripting.FileSystemObject")
oFS.copyfile(sfnam, dfnam, lowr)

Thanks to all for replying and here's to hoping for no more problems like this.