Modifying the same file by multiple users at the same time

[sashaDG]

Good afternoon, there is a problem. The application is located on a network drive,
users launch the application and select which file to upload to the Grid using the OptionGroup.

After selecting a file, copying took place (if the source was not available successCopied = .F.
(for this try catch) , "old file" was taken as the source
placeTo that was previously created).

	TRY	
		COPY FILE (placeFrom) TO (placeTo)
		successCopied = .T.
	CATCH 
		successCopied = .F.
	ENDTRY

And everything is fine, until two (at least) users try to simultaneously select
the same file (this means that there are two requests for the same path). The second user gets an error:
Code err 2059. "unhandled structural exceptions" ErrorNo 1705. Message: file access denied. LineNo:70 SSET DOHISTORY TO

I understand that it is necessary to make an alert and copy after a few seconds instead of an error. I tried with try catch,
but having learned that it is impossible to use return, I realized that it would not work.

 

[sashaDG]

Why change the extension and rename? Apparently I've been struggling with one question for a long time, I don't understand anything anymore... Excuse me

 

[Chris Miller]

I already explained that. You asked how to signal the copy is finished. This is one way.

Your idea was:

That is, check when the file was last modified

And I already said to you, that's a bad idea, as that modification date already changes when the copy starts and only 0.001% of the file is copeid.

if you check the modifcation date of the destination file, that will already be changed when the copy starts, while you would need to wait for the copy to end.

It still may take a long time before the file is really copied completely and is usable.

Is that now clearer?

Chriss

 

[Chris Miller]

Apparently I've been struggling with one question for a long time, I don't understand anything anymore... Excuse me

It may still be an issue of understanding your needs. But if it's all about copying a file and not doing anything with the source or destination while that copy progresses, then I proposed a solution now.

You've had a lot of bad ideas by lack of experience, I guess.

But you also have a hard time following instructions, advice, answering outr questions and also describing the root of your problem.

All in all, there usually is no problem of reading a file from multiple users, so if users copy the same file to different locations, then you shouldn't even have your problem. The description of what you do is incomplete, obviously.

Chriss

 

[Chris Miller]

You can do without multiple EXEs, too, but you can't do a COPY FILE taking a long time and expect your application to be usable during this copy time. And you can have all kinds of troubles if the file you copy is also accessed in other ways, for example if it's a DBF that some users USE in their client and others COPY.

Chriss

 

[Chris Miller]

Overall, SashaDG,

yes, thi thread is unconventional as it went into very many details though all you want to do is copy a file.
We have learned very little about your goal simply described in text form, non-technical.

Shouldn't be necessary, you will surely say, it's all just about copying a file.
Yes, but you posted about the unhandled exception, you posted about error 1705 and 1707, you posted about things that usually don't occur with a simple COPY FILE, even in multi user mode.
Copying involves multiple files, always, at least a source and a destination file, the latter might just be created or could exist and be overwritten. You can have prolems with file permissions, you can have problems because other users also access the file, not only by COPY, you may work on files that are also - as the title of your thread suggests - modified by multiple users. a COPY FILE does not modify the source file, that's only read, it creates the destinaiton file and the only modification you could talk of is overweriting the target file. Not the usual modification that occurs by a REPLACE or UPDATE of a DBF.

We had the side topic of CDXes as you showed your other use of TRY..CATCH that I understand has nothing to do with your problems, but Mike Lewis and I also talked about that. We - mainly I - also talked about updating a loal EXE, it doesn't seem that problem.

What you do with RETRY in an error handler that bounces back between trying to copy and retrying causes trouble with the EXE responsiveness and I told you why. Sleep does not solve thaat problem, nor would SleepEx do, because you simply never come back to the READ EVENTS state of awaiting and processing further events, like further button clicks, because you'd only get back into that state when eventually a Retry succeeds. And that may never be the case of two clients deadlock each other.

You could have a simple permission problem about the file share or some files within it. Notice when a user creates a file - no matter how, also as the destination of COPY TO - he's the file owner, as he created the file, and that can mean permission problems for other users. So when you copy files from local to share (I even don't know that) this might cause your error 1705. Also others opening files eclusively. But COPY TO won't. The destination, the file that's written, that's "exclusive" to the COPY TO command as long as it copies/writes to it. Are you even aware that the error can be about the source or the destination file? You may only look one way.

I don't know if you ever solve that problem, I also see no light at the end of the tunnel, but mainly because I know too little about what's the whole picture of all of this.



Chriss

 

[sashaDG]

Thanks for the extended answer, I'll back away from this question a bit and come back to it later.

 

[Mike Lewis]

Sasha,

I hope this discussion won't discourage you from asking questions or seeking help in the future. Just be sure to state your problem clearly, keeping in mind that we don't know anything about your application or your environment. And it always helps if you can state an overall goal, rather than focusing on a particular piece of code or error message.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Chris Miller]

I think it all boils down to this, ignoring the unhandled structured exception, the primary error was 1705 - File access denied.

With COPY FILE (placeFrom) TO (placeTo) that can only mean placeTo was the same. You can read the same (placeFrom) with as many users as you have, this is just shared reading.
The only reason (placeFrom) could be a problem is by file permissions, but that would be an error that would be caused by a single user trying to copy a file without having the minimum required read permissions.

I don't know, if this is a situation of "it worked for years and stopped working recently", then I could imagine something on the subject of terminal server, but as Mike said, we know too little about your applilcation and your environment.

Your experiment to handle error 1705 with a retry will only succeed, if you can be sure eventually the one user that succeeds to copy finishes and then the other can copy. But from the certainty the problem is with placeTo all you'd do is overwrite the file that's already copied there. And your delay/retry logic does hinder anything else fom happening in that users session until he finally also gets his copy done. That's no good solution.

Chriss