snip<=-
snip<=-
snip<=-
snip<=-
snip<=-
snip<=-
My question, does Windows handle file permissions differently than
Linux? I can run this all day long on the Linux system with no problems.
My question, does Windows handle file permissions differently than Linux? I can run this all day long on the Linux system with no proble
I suspect yes as often I can see the file seems locked on my Windows system until I close MIS ... and at times when there has been a crash I note it can remain locked. Or at least that's the memory I have of this..
That's what's giving me problems with my programs on Windows systems. I need to find a way to at least copy it, so that I can analyze the log files... I'll figure this out somehow... :)
If you copy and edit the new file, you should'not have any problem.If
you do, then the problem is somewhere else.
Also try to use TFileStream and open the file with share no deny access. May be Reset needs exclusive rights to open the file... not sure for
that.
On 07-10-18 21:08, Avon wrote to Black Panther <=-
My question, does Windows handle file permissions differently than
Linux? I can run this all day long on the Linux system with no problems.
I suspect yes as often I can see the file seems locked on my Windows system until I close MIS ... and at times when there has been a crash I note it can remain locked. Or at least that's the memory I have of
this..
I tried it with 'fmOpenDenyWrite' and also 'fmOpenRead', but neither of them worked on the Windows system. It copies it just fine under Linux...
In linux you can't "lock" a file. If you want someone not to have access to that file, you alter the permissions. So locking a file in linux is
not like in Windows.
Because you are tampering with a log file, which is always been updated
by the server/mis, i think that coping the file and editing the new
file, is the best solution.
Sysop: | altere |
---|---|
Location: | Houston, TX |
Users: | 57 |
Nodes: | 4 (0 / 4) |
Uptime: | 08:00:12 |
Calls: | 513 |
Files: | 6,922 |
Messages: | 285,835 |