Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Cannot Create file (error 1102)
Message
De
04/11/1999 09:21:17
 
 
À
04/11/1999 05:47:56
Information générale
Forum:
Visual FoxPro
Catégorie:
Codage, syntaxe et commandes
Divers
Thread ID:
00286033
Message ID:
00286812
Vues:
39
>Robert - Thanks I will be talking with the network folk today and see if they were having any problem at the time the local properties were tring to send the files.
>
>Gaylen
>
>
>>Gaylen,
>>
>>I've had a similar problem when copying a file to an Iomega Zip drive, if the access was very slow. What would happen was:-
>>
>>VFP -> ZIP (via OS) "create file x"
>>ZIP ->VFP "File Created"
>>VFP ->ZIP (via OS) "does file exist"
>>OS -> VFP "No" (but ZIP drive is still whirring and writing the file, which is created correctly, etc.).
>>
>>...although the file exists on the ZIP drive. This only happened when access to the Zip drive was slow, as if it had replied that it had created the file when in fact it was in the *process* of creating the file (and the file was buffered somewhere) so VFP continued to the next statement.
>>
>>Perhaps the network / comms line was particularly busy for these six sites (as I think Sanjay suggested) and you ran into a similar problem, perhaps related to NT buffering (just guessing). You could try putting a pause before testing for the file, calling doevents() or putting the error routine into a loop.
>>
>>Just a suggestion.

Hi Gaylen,

If you are using TCP/IP (most likely) as your comms protocol, what really should happen is that NT creates a temporary buffer for the info packets coming down the comms line until TCP/IP confirms that all packets have been successfully transmitted. It also allocates a pointer to this buffered area.(TCP/IP may not transmit data in packet sequence ie you may receive packet 4 of 6 before packet 1 of 6)

Once NT's kernel is aware of all data received, all it does is re-writes the FAT entry of the pointer of the original file with the new one its just buffered. It will then send a message to the requesting app that the operation is complete, and from there, the app itself assumes charge. (All app requests go through to the NT kernel which handles the request.) If your call comes to test if the file's written comes too fast (as Robert's pointed out) you could perhaps be out of sync somewhere!

Just a theory. That's all!
Sanjay Kapoor

Relatively speaking is a conversation with Einstein
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform