Mail Archives: cygwin/2005/02/02/13:08:28
On Feb 2 17:18, Eric Blake wrote:
> > I am not sure whether this is a 128 k problem. I tested with a file that
> > had 1 MB of data at the beginning and another 1 MB of data at the end. In
> > between there were some 18 MB of zeroes (checked this with a hex-editor).
>
> I did the following test on Win2000 SP4, using cygwin 1.5.12 and coreutils
> 5.3.0-2 (actually, I strace'd the following calls to more closely track what
> syscalls were happening).
> $ dd bs=1 seek=128K of=t < /dev/null 2> /dev/null
> $ cp --sparse=always t u
> $ cp u v
>
> Since fsutil is not present except on win2003 or XP, I used an alternative
> method to check whether a file is sparse: opening up Windows explorer, and
ls -s works, too. The size given is the actual size on disk in KB. For
sparse files you'll see it's lower than the filesize.
> However, it points out a related bug in cygwin. cp uses lseek() followed by
> write(), so cygwin made u sparse because the write was at 128k beyond the end
> of the current file size. But dd uses lseek() followed by ftruncate(), and
> cygwin just moved the end of the file without checking whether the file
> should
> be made sparse. The logic in write() needs to be copied to truncate() and
> ftruncate() to allow dd to create sparse files in the first place.
Thanks for the hint. I'll fix it at one point.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader mailto:cygwin AT cygwin DOT com
Red Hat, Inc.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -