Changes between Initial Version and Version 3 of Ticket #76


Ignore:
Timestamp:
01/11/14 22:48:26 (10 years ago)
Author:
ossi
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #76

    • Property Reporter changed from slavazanko to ngaba
    • Property Branch state changed from to no branch
    • Property Milestone changed from to future releases

  • Ticket #76 – Description

    initial v3  
    77||Release:||4.6.1||Operating System:||GNU/Linux|| 
    88 
    9 Discussion: 
     9Original submission: 
    1010{{{ 
    11 Thu 08 Nov 2007 01:02:40 PM UTC, comment #11: 
     11Hi! 
     12I simply refer to my mail on ML: http://mail.gnome.org/archives/mc/2007-April/msg00002.html 
     13The workaround I suggested there is not usable, because it is very slow. 
     14The main problem: most archivers cannot do "unpack foo as bar" and  
     15we use "unpack --unpack-to-stdout archive/foo > bar" and unpack  
     16won't return with error in case of disk-full. 
     17A possible workaround (pseudo-code): 
     18extractto-dir = basedir(extractto) 
     19extractto-name = undocumented ;-P 
     20Then we could unpack to extractto-dir with the original name, then  
     21rename the unpacked file to extractto-name. 
     22Bye 
     23}}} 
    1224 
    13 Regarding urar and password protected archives - if you use urar  
    14 from CVS it shouldn't freeze MC anymore. I'll answer the other  
    15 questions later. 
    16         Pavel Tsekov <ptsekov> 
    17 Project Administrator 
    18 Thu 08 Nov 2007 11:05:17 AM UTC, comment #10: 
     25Comment 1 by Pavel Tsekov <ptsekov> at Tue 06 Nov 2007 01:31:16 PM UTC: 
     26{{{ 
     27Are you sure ? 
    1928 
     29[ptsekov@localhost Desktop]$ unzip -p bless-bin-0.5.0.zip bless-bin-0.5.0/NEWS > /bin/mv 
     30bash: /bin/mv: Permission denied 
     31 
     32[ptsekov@localhost Desktop]$ echo $? 
     331 
     34 
     35So errors are reported. Maybe the return status is not checked  
     36properly in the uzip script. 
     37}}} 
     38 
     39Comment 2 by Nagy Gabor <ngaba> at Tue 06 Nov 2007 01:53:47 PM UTC: 
     40{{{ 
     41Well. I'm not really familiar in perl. 
     42But as your example shows, here obviously bash reports the error  
     43instead of unzip. If you modify the script to detect bash errors  
     44too, that would be OK. But imho unzip's disk-full detection is much  
     45better, because it deletes the partly unpacked file and so on. 
     46But I'm sure that uzip/urar ... can corrupt my files, because it did 
     47:-( 
     48 
     49A bit off here: IMHO the whole /tmp stuff should be dropped from VFS 
     50(that is a big speed and disk limitation). 
     51}}} 
     52 
     53Comment 3 by Pavel Tsekov <ptsekov> at Tue 06 Nov 2007 02:11:39 PM UTC: 
     54{{{ 
     55Well, I took the time to try and reproduce an error condition while  
     56extracting an archive entry into tmp (i.e. copyout). The copyout  
     57action reports the error and MC captures it and displays it in a red 
     58dialog box. I don't know what caused the data corruption in your  
     59case but I cannot continue investigating this bug report whithout  
     60further information. Either provide useful info or I'll close this  
     61bug report as invalid. 
     62}}} 
     63 
     64Comment 4 by Pavel Tsekov <ptsekov> at Tue 06 Nov 2007 02:15:17 PM UTC: 
     65{{{ 
     66I did not try a disk full on /tmp but I rather forget the temporary  
     67file name to point to a file writable by root which produces  
     68Permission denied error - but there should be no difference. 
     69}}} 
     70 
     71Comment 5 by Nagy Gabor <ngaba> at Tue 06 Nov 2007 03:31:08 PM UTC: 
     72{{{ 
     73h372926@pc2003:~$ df -h 
     74/dev/sda8 950M 869M 34M 97% /tmp 
     75h372926@pc2003:~$ dd if=/dev/zero bs=50M of=./bigfile count=1 
     76h372926@pc2003:~$ zip a 1.zip bigfile 
     77 
     78Then I starts mc, I press enter on 1.zip, and I try to copy out  
     79bigfile from 1.zip to my home. The result: 34M bigfile in my home,  
     80no error. 
     81}}} 
     82 
     83Comment 6 by Pavel Tsekov <ptsekov> at Tue 06 Nov 2007 04:20:42 PM UTC: 
     84{{{ 
     85Ok. According to the bash manual: 
     86 
     87[...] 
     88A failure to open or create a file causes the redirection to fail. 
     89[...] 
     90 
     91Unfortunately failure to write is not detected :( So, yes - this  
     92method is unsafe. 
     93}}} 
     94 
     95Comment 7 by Pavel Tsekov <ptsekov> at Wed 07 Nov 2007 02:13:17 PM UTC: 
     96{{{ 
     97Instead of using "> /tmp/file" the extfs scripts could pipe the  
     98extracted file contents trough "dd" .. then all errors would be  
     99reported. Comments ? Ideas ? 
     100}}} 
     101 
     102Comment 8 by Nagy Gabor <ngaba> at Wed 07 Nov 2007 02:45:30 PM UTC: 
     103{{{ 
     104If this works well, then OK. 
     105But I would prefer skip /tmp from extracting whenever possible: 
     106Pros: 
     107-sometimes /tmp is small, and you have not enough privileges to  
     108change this: big limiting factor 
     109-if you extract files to a pendrive for example, the extra /tmp step 
     110 [usually on local HDD] slows down the process [this is not a  
     111reasonable slowdown however, but a slowdown] 
     112Contras: 
     113-you loose your "copy-out" progressbar (however, this is not an  
     114informative thing, usually uncompress is much slower than /tmp->/dest copy/move) 
     115-??? 
     116}}} 
     117 
     118Comment 9 by Pavel Tsekov <ptsekov> at Wed 07 Nov 2007 03:02:33 PM UTC: 
     119{{{ 
     120The /tmp step is necessary since extfs tries to emulate real  
     121filesystem operations. If we had a native archiver support it would  
     122be unnecessary. This could happen but not for 4.6.2. 
     123}}} 
     124 
     125Comment 10 by Nagy Gabor <ngaba> at Thu 08 Nov 2007 11:05:17 AM UTC: 
     126{{{ 
    20127I will be a bit offtopic here, but I hope that you tolerate me: 
    211281. If you attach the modified uzip && urar scripts, I will test it. 
    … …  
    33140F3/F4; 'realdest' in case of F5/F6/F7/F8 ... <- if /tmp is still  
    34141needed, the extfs script can use it) 
    35         Nagy Gabor <ngaba> 
    36 Wed 07 Nov 2007 03:02:33 PM UTC, comment #9: 
     142}}} 
    37143 
    38 The /tmp step is necessary since extfs tries to emulate real  
    39 filesystem operations. If we had a native archiver support it would  
    40 be unnecessary. This could happen but not for 4.6.2. 
    41         Pavel Tsekov <ptsekov> 
    42 Project Administrator 
    43 Wed 07 Nov 2007 02:45:30 PM UTC, comment #8: 
    44  
    45 If this works well, then OK. 
    46 But I would prefer skip /tmp from extracting whenever possible: 
    47 Pros: 
    48 -sometimes /tmp is small, and you have not enough privileges to  
    49 change this: big limiting factor 
    50 -if you extract files to a pendrive for example, the extra /tmp step 
    51  [usually on local HDD] slows down the process [this is not a  
    52 reasonable slowdown however, but a slowdown] 
    53 Contras: 
    54 -you loose your "copy-out" progressbar (however, this is not an  
    55 informative thing, usually uncompress is much slower than /tmp->/dest copy/move) 
    56 -??? 
    57         Nagy Gabor <ngaba> 
    58 Wed 07 Nov 2007 02:13:17 PM UTC, comment #7: 
    59  
    60 Instead of using "> /tmp/file" the extfs scripts could pipe the  
    61 extracted file contents trough "dd" .. then all errors would be  
    62 reported. Comments ? Ideas ? 
    63         Pavel Tsekov <ptsekov> 
    64 Project Administrator 
    65 Tue 06 Nov 2007 04:20:42 PM UTC, comment #6: 
    66  
    67 Ok. According to the bash manual: 
    68  
    69 [...] 
    70 A failure to open or create a file causes the redirection to fail. 
    71 [...] 
    72  
    73 Unfortunately failure to write is not detected :( So, yes - this  
    74 method is unsafe. 
    75         Pavel Tsekov <ptsekov> 
    76 Project Administrator 
    77 Tue 06 Nov 2007 03:31:08 PM UTC, comment #5: 
    78  
    79 h372926@pc2003:~$ df -h 
    80 /dev/sda8 950M 869M 34M 97% /tmp 
    81 h372926@pc2003:~$ dd if=/dev/zero bs=50M of=./bigfile count=1 
    82 h372926@pc2003:~$ zip a 1.zip bigfile 
    83  
    84 Then I starts mc, I press enter on 1.zip, and I try to copy out  
    85 bigfile from 1.zip to my home. The result: 34M bigfile in my home,  
    86 no error. 
    87         Nagy Gabor <ngaba> 
    88 Tue 06 Nov 2007 02:15:17 PM UTC, comment #4: 
    89  
    90 I did not try a disk full on /tmp but I rather forget the temporary  
    91 file name to point to a file writable by root which produces  
    92 Permission denied error - but there should be no difference. 
    93         Pavel Tsekov <ptsekov> 
    94 Project Administrator 
    95 Tue 06 Nov 2007 02:11:39 PM UTC, comment #3: 
    96  
    97 Well, I took the time to try and reproduce an error condition while  
    98 extracting an archive entry into tmp (i.e. copyout). The copyout  
    99 action reports the error and MC captures it and displays it in a red 
    100 dialog box. I don't know what caused the data corruption in your  
    101 case but I cannot continue investigating this bug report whithout  
    102 further information. Either provide useful info or I'll close this  
    103 bug report as invalid. 
    104         Pavel Tsekov <ptsekov> 
    105 Project Administrator 
    106 Tue 06 Nov 2007 01:53:47 PM UTC, comment #2: 
    107  
    108 Well. I'm not really familiar in perl. 
    109 But as your example shows, here obviously bash reports the error  
    110 instead of unzip. If you modify the script to detect bash errors  
    111 too, that would be OK. But imho unzip's disk-full detection is much  
    112 better, because it deletes the partly unpacked file and so on. 
    113 But I'm sure that uzip/urar ... can corrupt my files, because it did 
    114 :-( 
    115  
    116 A bit off here: IMHO the whole /tmp stuff should be dropped from VFS 
    117 (that is a big speed and disk limitation). 
    118         Nagy Gabor <ngaba> 
    119 Tue 06 Nov 2007 01:31:16 PM UTC, comment #1: 
    120  
    121 Are you sure ? 
    122  
    123 [ptsekov@localhost Desktop]$ unzip -p bless-bin-0.5.0.zip bless-bin-0.5.0/NEWS > /bin/mv 
    124 bash: /bin/mv: Permission denied 
    125  
    126 [ptsekov@localhost Desktop]$ echo $? 
    127 1 
    128  
    129 So errors are reported. Maybe the return status is not checked  
    130 properly in the uzip script. 
    131         Pavel Tsekov <ptsekov> 
    132 Project Administrator 
    133 Tue 06 Nov 2007 12:45:03 PM UTC, original submission: 
    134  
    135 Hi! 
    136 I simply refer to my mail on ML: http://mail.gnome.org/archives/mc/2007-April/msg00002.html 
    137 The workaround I suggested there is not usable, because it is very slow. 
    138 The main problem: most archivers cannot do "unpack foo as bar" and  
    139 we use "unpack --unpack-to-stdout archive/foo > bar" and unpack  
    140 won't return with error in case of disk-full. 
    141 A possible workaround (pseudo-code): 
    142 extractto-dir = basedir(extractto) 
    143 extractto-name = undocumented ;-P 
    144 Then we could unpack to extractto-dir with the original name, then  
    145 rename the unpacked file to extractto-name. 
    146 Bye 
     144Comment 11 by Pavel Tsekov <ptsekov> at Thu 08 Nov 2007 01:02:40 PM UTC: 
     145{{{ 
     146Regarding urar and password protected archives - if you use urar  
     147from CVS it shouldn't freeze MC anymore. I'll answer the other  
     148questions later. 
    147149}}}