LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
August 2008
Previous Thread
Next Thread
Previous by Thread
Next by Thread
Previous by Date
Next by Date
Contact
The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems
Thread
2008.08.23 15:26 "Re: creating sparse files......", by Rogier Wolff
On Fri, Aug 22, 2008 at 04:02:15PM -0400, Phillip Crews wrote:
> Bob Friesenhahn wrote:
> >It is likely that some popular filesystems will fail to seek past the
> >end of the file or will return random bytes (or parts of some
> >previously deleted file) for the uninitialized portions.
> This was my immediate objection to this scheme. Even if it were a
> platform-specific or configuration-controlled option, there will be
> cases where one O/S is writing to a filesystem on another O/S (i.e.,
> over the network), resulting the same random garbage or simply ignored
> seeks.
Ehh. You do have to take into account that this was written in the
module "tif_unix.c" or something like that. Wether this is active on
Microsof operating systems as well, I don't know. Sounds like it
should not be....
> If this is for Windows, the simplest solution for the OP may be to
> store the files in an NTFS compressed folder, or modify TIFFFDOpen
> to accept an additional flag which would set the file as compressed
> on compatible filesystems.
Now this is something that is not portable.
> Note that the DeviceIoControl call will fail on unsupported
> file systems. No further changes should be required (i.e., non-standard
> seeks or checking for zeros). Similar minimal changes should be possible
> for other operating systems as well.
What I implemented is NOT non-standard.
It checks for zeros. It works for all operating systems. Files that
end up on filesystems that don't support holes will simply not have
the compression advantages.
> (NB: I apologize for the HTML mail but I thought it much more readable
> for code; I'm sending in both, hoping that the plaintext version will
> still be readable!)
>
> In *tif_win32.c* (/untested /code follows, my changes in red):
>
> |#include <winioctl.h>
This bombs when I try to compile it: I don't have winioctl.h .
> ...
> TIFF*
> TIFFFdOpen(thandle_t ifd, PCTSTR name, const char *mode)
> {
> TIFF* tif;
> BOOL fSuppressMap = (mode[1] == 'u' || (mode[1] != 0 && mode[2] == 'u'));
> static const USHORT compmode = COMPRESSION_FORMAT_DEFAULT;
> DWORD retbytes = 0; /* Not used but necessary per MS docs */
>
> if (mode[0] == 'w' && (mode[1] == 'c' || mode[2] == 'c') ) {
> /* Compress new files only, otherwise no feedback on slow compression */
> DeviceIoControl(ifd, FSCTL_SET_COMPRESSION, &compmode, sizeof comp,
This will fail to compile on my system, as my system doesn't have have
DeviceIoControl.
Now who is suggesting non-standard solutions?????
Roger.
--
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement.
Does it sit on the couch all day? Is it unemployed? Please be specific!
Define 'it' and what it isn't doing. --------- Adapted from lxrbot FAQ