Further to this problem, I discovered it has nothing to do with operating systems or Delphi versions.
I discovered that the hex editor I was looking at the file with was preventing the file from being truncated by my app. I'm guessing the editor is opening the file in a shared read/write mode and even though my app can open the file in readwrite mode, it cannot truncate it if it's open by the editor. That is rather dangerous in my situation and I would rather not be able to open the file except in readonly mode in this situation. Is there a simple way to check if the file is open by another app in readwrite or write mode? I don't need to know if the file is open in read mode by another app as this appears to work fine when truncating. Thanks, Ross. ----- Original Message ----- From: "Ross Levis" <[EMAIL PROTECTED]> To: "Delphi Discussion List" <[email protected]> Sent: Wednesday, January 18, 2006 5:48 PM Subject: Truncate Some time ago I wrote a routine to write and maintain a custom file tag stored at the end of audio files. I've just noticed there is a serious problem now which didn't exist when I wrote it. The only difference I can think of is that I'm now using D7 rather than D5. I tracked the problem down to the delphi Truncate procedure (IO routines) which is suppose to trim the filesize of the file at the current seek position. This is not working now. It does nothing whatsoever. I need this to keep the tag at the correct offset from the end of the file. Does anyone have any ideas why this doesn't work anymore. Is there perhaps an alternative using the newer (non-pascal) file IO routines. Thanks, Ross. _______________________________________________ Delphi mailing list -> [email protected] http://www.elists.org/mailman/listinfo/delphi
