Hi,
I'm going explain the problem in detail another time:
Distribution:
*Red Hat Enterprise Linux ES release 4 (Nahant Update 3)*
*I'm connected as root.*
I have this zipped file:
Code:
-rw-r--r-- 1 root root 678183271 abr 7 15:30 Master032010.zip
it contains a 2,4G file
Code:
df -h
S.ficheros Tamaño Usado Disp Uso% Montado en
/dev/cciss/c0d0p6 4,0G 3,5G 282M 93% /
/dev/cciss/c0d0p1 124M 13M 105M 11% /boot
none 4,0G 0 4,0G 0% /dev/shm
/dev/cciss/c0d0p7 56G 17G 37G 31% /opt
/dev/cciss/c0d0p3 985M 18M 917M 2% /tmp
/dev/cciss/c0d0p5 5,0G 404M 4,3G 9% /var
/dev/sda1 270G 220G 37G 86% /database
/dev/sdb1 125G 63G 56G 54% /data
/dev/sdc1 826G 138G 646G 18% /data2
The zip file is in /dev/sdc1 under /data2/elos/files/in
as you can see this partition has space enough to unzip a 2,4G file
(646G free)
I have also tried to unzip the file in the /dev/sda1 under /database but
in both cases I have the same problem:
Code:
[root@ELOS-BD in]# unzip Master032010.zip
Archive: Master032010.zip
inflating: SongMaster201003.txt
SongMaster201003.txt: write error (disk full?). Continue? (y/n/^C) y
bad CRC 9695f189 (should be 0cab6361)
I have tested the file:
Code:
[root@ELOS-BD in]# unzip -t Master032010.zip
Archive: Master032010.zip
testing: SongMaster201003.txt OK
No errors detected in compressed data of Master032010.zip.
I have typed free:
Code:
[root@ELOS-BD in]# free -m
total used free shared buffers cached
Mem: 8054 8038 16 0 5 7222
-/+ buffers/cache: 809 7244
Swap: 1023 72
I have unzipped the same file in my own machine (ubuntu 9.10) and in
windows and I have no problem.
Besides, the problem is that it is a task that should be done by a Java
application because the unzipped file need to be processed. This task is
repeated 1 time per month.
I was making tests because when unzipping from java I was having
problems, then I tried throught the command line and found this problem...
Thanks
cliff here escribió:
I agree, I think e's trying to expand the file in a partition that is full
On Mon, Apr 12, 2010 at 10:05 AM, <m.roth@xxxxxxxxx> wrote:
No problem with the file:
[root@ELOS-BD in]# unzip -t Master032010.zip
Archive: Master032010.zip
testing: SongMaster201003.txt OK
No errors detected in compressed data of Master032010.zip.
I'm connected as root.
But, you are right, it seems that changing the permissions to 777 it
unzips ok.
<snip>
This bothers me. I haven't been following this thread, but does it unzip
with 666, rather than 777? A zip file does not need be executable.
mark
--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list
--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list
