H
HalRogers
There is a difference between file closing on a drive connected on
Windows platform (all of the examples that worked) and a file closin
across a network to a different operating environment (SAMBA)
There may indeed be a simple fix in SAMBA to deal with windows app
that do not close files the way Word, UltraEdit, Excel, and othe
apps do it
Windows does not have a single standard for closing files, which i
nice I suppose, it gives the developer flexibility to choose th
standard instead of following a single one.
The reason for the problem is related to the allocation of file spac
in chunks. There are always extra bytes at the end of a file, in th
same cluster, so determining the end of file has to follow either th
ASCII standard (an EOF "MARK") or the binary standard (setting th
filesize in the directory entry). The extra bytes used to be used b
some developers to stick extra code on the end of an EXE file, the
close the file and alter the directory entry to a new size, leavin
the extra bytes on the disk, but they would not get copied if th
user moved the file rather than re-install it (since COPY honors th
filesize in the directory when determining when to stop copying)
The errors noted are all fixable if the directory entry is changed t
reflect the actual number of bytes in the usable content of the fil
-- notice the errors reported are always due to extra character
appearing AFTER the expected END OF FILE. Bytes that are on the disk
but should not be read into the application, but ARE read in becaus
the filesize is wrong
Yes, it would be nice to see this fixed, but it's being caused by th
way the files are closed and the directory is (not) updated
As to problems with DVD ISO images
DVD-R ISO images may exceed the 32-bit FAT limitation of 4 GB (o
thereabouts). Microsoft describes the FAT-32 limitations for fil
size as "You cannot create a file larger than (2^32)-1 bytes (this i
one byte less than 4 GB) on a FAT32 partition" - since DVD images ma
be more like 4.7 GB, it's possible that you are exceeding the FAT-3
limit
Ha
Windows platform (all of the examples that worked) and a file closin
across a network to a different operating environment (SAMBA)
There may indeed be a simple fix in SAMBA to deal with windows app
that do not close files the way Word, UltraEdit, Excel, and othe
apps do it
Windows does not have a single standard for closing files, which i
nice I suppose, it gives the developer flexibility to choose th
standard instead of following a single one.
The reason for the problem is related to the allocation of file spac
in chunks. There are always extra bytes at the end of a file, in th
same cluster, so determining the end of file has to follow either th
ASCII standard (an EOF "MARK") or the binary standard (setting th
filesize in the directory entry). The extra bytes used to be used b
some developers to stick extra code on the end of an EXE file, the
close the file and alter the directory entry to a new size, leavin
the extra bytes on the disk, but they would not get copied if th
user moved the file rather than re-install it (since COPY honors th
filesize in the directory when determining when to stop copying)
The errors noted are all fixable if the directory entry is changed t
reflect the actual number of bytes in the usable content of the fil
-- notice the errors reported are always due to extra character
appearing AFTER the expected END OF FILE. Bytes that are on the disk
but should not be read into the application, but ARE read in becaus
the filesize is wrong
Yes, it would be nice to see this fixed, but it's being caused by th
way the files are closed and the directory is (not) updated
As to problems with DVD ISO images
DVD-R ISO images may exceed the 32-bit FAT limitation of 4 GB (o
thereabouts). Microsoft describes the FAT-32 limitations for fil
size as "You cannot create a file larger than (2^32)-1 bytes (this i
one byte less than 4 GB) on a FAT32 partition" - since DVD images ma
be more like 4.7 GB, it's possible that you are exceeding the FAT-3
limit
Ha