id summary reporter owner description type status priority milestone component version resolution keywords cc blockedby blocking branch_state votes 62 savannah: MC fail to notice when archive is replaced slavazanko "Original: http://savannah.gnu.org/bugs/?19328 ||Submitted by:||Martin Petricek ||Submitted on:||Fri 16 Mar 2007 10:45:16 PM UTC|| ||Category:||VFS||Severity:||3 - Normal|| ||Status:||None||Privacy:||Public|| ||Assigned to:||None||Open/Closed:||Open|| ||Release:||current (CVS or snapshot)||Operating System:||GNU/Linux|| Discussion: {{{ Fri 18 May 2007 01:51:04 PM UTC, comment #1: Some VFS (for example tar and cpio) can detect changed archives, others (bzip, extfs) can't. There is no consistent support of change detection in VFS. Vladimir Nadvornik Fri 16 Mar 2007 10:45:16 PM UTC, original submission: When .tar.bz2 archive is replaced, VFS in MC fails to notice it. If you pack some files, examine the archive, then repack the archive with different files, you see still old files. How to reproduce: Create two valid archives with distinct content (does not matter what content, just it have to be distinct files): a.tar.bz2 and b.tar.bz2 Now move cursor to a.tar.bz2 and press enter. You see the contents. Fine, now go back, delete a.tar.bz2 and rename b.tar.bz2 to a.tar.bz2. Move to a.tar.bz2 (which is actually a renamed b.tar.bz2) and press enter. You will see cached content of previous a.tar.bz2 and you can even extract the files, even though the archive is deleted (I suppose a copy lives in /tmp or in memory) Suggested fix: check date and size of archive when entering it. If it does not match, re-read the archive. This should fix most of the cases. Clean, but maybe slower solution is to re-read archive every time it is entered. I suppose this bug may also affect other archive types (.tar.gz?), though I have not tested it. Martin Petricek }}} " defect new major mc-vfs