The `c' flag in lsattr output doesn't show whether or not
the file is compressed; it is just a "request" for that.
$ gzip -9 fred $ chattr +c fred.gz $ lsattr fred.gz --c---- 32 gzip9 fred.gz $ e2ratio -l fred.gz 467 467 100.0% fred.gz $
In the above, `fred.gz' could not be compressed (as can be seen
from the e2ratio output), but it still has the `c'
(EXT2_COMPR_FL) attribute set -- which indicates that for any
further writes to the file (e.g. if you append a text file onto the
end of `fred.gz'), the kernel will attempt to compress the affected
clusters.
$ chattr +c bigfile $ dd if=/dev/zero of=deleteme dd: deleteme: No space left on device 5234+0 records in 5233+0 records out $ chattr -c bigfile $ e2ratio -l bigfile 3766 1442 38.3% bigfile $ lsattr bigfile ------- 32 gzip9 bigfile
In the above example, on the other hand, the `c' flag is not set
for the file, but it is plainly still compressed (as evidenced by both
the e2ratio output and the lsattr output -- which still
shows a compression algorithm and cluster size).
The usual reason that it would still be compressed is that the disk is full, or was full when you did `chattr -c'. See section What if I decompress a file on a full device?.
Another reason could be that it is still decompressing. However, you
wouldn't usually see this, because chattr doesn't return until
decompression is finished. In any case, just wait a couple of seconds
(duration proportional to size of file, and slowness and load of your
CPU) and try again.
Another could be that an error (other than `disk full') occurred during
decompression. In this case there should be a `E' (or `*') in
column 3 of lsattr output. The solution here is to run
e2decompress on the file, and then have a look at the file to see
if there's any damage.
These are the only situations I can think of. If there's anything else, write to the e2compr maintainer (see section Contact details for e2compr maintainer), as it may be a bug.
Go to the first, previous, next, last section, table of contents.