bneijt/autotrash

crashes on corrupt (?) .trashinfo file

Closed this issue · 2 comments

$ apt-cache show autotrash
Package: autotrash
Priority: optional
Section: universe/utils
Installed-Size: 31
Maintainer: Lorenzo De Liso <blackz@ubuntu.com>
Architecture: all
Version: 0.1.5-1.1
Depends: python (>= 2.5)
Filename: pool/universe/a/autotrash/autotrash_0.1.5-1.1_all.deb
Size: 9242
MD5sum: 52d0cc5d855e4ce3151b447c7251ce15
SHA1: cafdc04f1f67ccf5017da8be0329688a23594948
SHA256: 32b207f642663f25add2740fc6bf55a257149f5060d2df51b53a7d1151e3e8d1
Description-en: purges files from your trash based on age and/or filename
 A script useful to purge files from your trash based on their age.
 It can also be used to purge the files based on the filename
 using a regular expression.
Description-md5: ef1da8d069fca1d8bc8f079afd754d5f
Homepage: http://www.logfish.net/pr/autotrash/
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Origin: Ubuntu

Observed behaviour:

$ autotrash -d 60
Traceback (most recent call last):
  File "/usr/bin/autotrash", line 317, in <module>
    sys.exit(main(sys.argv))
  File "/usr/bin/autotrash", line 251, in main
    file_time = trash_info_date(file_name)
  File "/usr/bin/autotrash", line 96, in trash_info_date
    readCorrectly = parser.read(fname)
  File "/usr/lib/python2.7/ConfigParser.py", line 305, in read
    self._read(fp, filename)
  File "/usr/lib/python2.7/ConfigParser.py", line 512, in _read
    raise MissingSectionHeaderError(fpname, lineno, line)
ConfigParser.MissingSectionHeaderError: File contains no section headers.
file: /home/me/.local/share/Trash/info/IMG_9597.jpg.trashinfo, line: 1
'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'

$ hexdump /home/me/.local/share/Trash/info/IMG_9597.jpg.trashinfo
0000000 0000 0000 0000 0000 0000 0000 0000 0000
*
00000b3

The test file is at http://filebin.net/a7uysrqb1h – but I suppose any file with just a bunch of NUL's will make it crash.

Expected behaviour: Warn about it, but keep trashing.

This is indeed a corrupted .trashinfo file, it only contains binary zero's where autotrash expects these files to contain trash information based on the freedesktop spec[1]: "Its first line must be [Trash Info]."

Seems like your file got corrupted for some reason. Did you systems shutdown uncleanly with some special ext4 mount options??

[1] http://standards.freedesktop.org/trash-spec/trashspec-1.0.html

Anyway.. on to the main point: expected behaviour.

We can have autotrash ignore the file, but I don't have a good idea on handling IMG_9597.jpg in this instance. I think we should start with a patch to ignore trashinfo files that won't parse. Is that what you have in mind as well?

"A. Bram Neijt" notifications@github.com čálii:

[...]

Seems like your file got corrupted for some reason. Did you systems
shutdown uncleanly with some special ext4 mount options??

Probably :)

We can have autotrash ignore the file, but I don't have a good idea on
handling IMG_9597.jpg in this instance. I think we should start with a
patch to ignore trashinfo files that won't parse. Is that what you
have in mind as well?

Ignoring them would be an improvement :)

I think the ideal behaviour for me would be to have autotrash print the following to stderr:

Warning: Couldn't read /home/me/.local/share/Trash/info/IMG_9597.jpg.trashinfo (size: 1 kb)
Warning: Not removing /home/me/.local/share/Trash/files/IMG_9597.jpg (size: 20 MB) since its trashinfo was unreadable

and keep trashing the rest.

This way, a user can see from the logs if something was amiss, but also doesn't have to worry about corruption leading to too much being deleted.