[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Fwd: Re: handling of files > 2GB]

From: Joerg Kampmann
Subject: [Fwd: Re: handling of files > 2GB]
Date: Wed, 17 Oct 2001 09:41:12 +0200

the "true > somewhat" seems to work:

"df" shows now plausible free and used disk areas !

thnx a lot


-------- Original Message --------
Betreff: Re: handling of files > 2GB
Datum: Wed, 17 Oct 2001 09:35:08 +0200
Von: Joerg Kampmann <address@hidden>
Rückantwort: address@hidden
Firma: IBK-Consult
An: Bob Proulx <address@hidden>
Referenzen: <address@hidden>

Hi Bob,

thanks a lot - I'll try it


Bob Proulx schrieb:
> > I inadvertantly generated during a backup session with tar files which -
> > obviously - are greater than 2 GB. the space occupied appears in "df ."
> > - however trying to "rm" this file this is not possible
> >
> > the errormessage is:
> >
> > rm: cannot remove `backup-share.tar': Value too large for defined data
> > type
> >
> > what could I do to remove that file ?
> Your version of GNU fileutils were apparently not configured to
> support large files.  They do support large files when compiled to do
> so.
> Purely as a workaround I would suggest different things.  At least one
> should work.
> I am sure the perl fans will suggest this.  But this again requires
> perl to be configured for large files.
>   perl -e 'unlink("backup-share.tar");'
> So let's try to hit it more directly.  Truncate the file first.  That
> will make it small and then you can remove it.  The shell will do this
> when redirecting the output of commands.
>   true > backup-share.tar
>   rm backup-share.tar
> However, if your shell was not compiled for large files then the
> redirection will fail.  In that case we have to resort to more subtle
> methods.  Since tar created the file then tar must be configured to
> support large files.  Use that to your advantage to truncate the file.
>   touch /tmp/junk
>   tar cvf backup-share.tar /tmp/junk
> Hope that helps
> Bob

Dr. Jörg Kampmann - IBK-Consult for Real-Time and Embedded Systems
D-31228 Peine - Tel.:+49-177-276-3140 - Fax: +49-5171-13385
===== QNX is the better Choice for Real-Time: http://www.qnx.com ====

reply via email to

[Prev in Thread] Current Thread [Next in Thread]