recoverjpeg does a chdir to the recovery directory too early

Bug #1603685 reported by Robin Sheat
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
recoverjpeg (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

I'm attempting to recover files into a directory called 'recovered'. When I run:

$ recoverjpeg sdd.img -o recovered/

it says:

recoverjpeg: unable to open sdd.img for reading (No such file or directory)

which is objectively not true:

$ ls -l
totaal 7561512
drwxrwxr-x 2 robin robin 4096 jul 16 21:21 recovered
-rw-r--r-- 1 root root 7742685184 jul 16 21:18 sdd.img
-rw-r--r-- 1 root root 294 jul 16 21:18 sdd.log

running it with strace shows what's going on:

chdir("recovered/") = 0
open("./sdd.img", O_RDONLY) = -1 ENOENT (No such file or directory)
write(2, "recoverjpeg: unable to open ./sd"..., 78recoverjpeg: unable to open ./sdd.img for reading (No such file or directory)
) = 78
exit_group(1) = ?

it should open the file for reading, and then chdir.

Obvious workaround: use the absolute path to the file you're recovering from. Still, I could see this confusing the heck out of someone who doesn't know how to drive strace :)

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: recoverjpeg 2.6-1
ProcVersionSignature: Ubuntu 4.4.0-28.47-generic 4.4.13
Uname: Linux 4.4.0-28-generic x86_64
NonfreeKernelModules: nvidia_uvm nvidia
ApportVersion: 2.20.1-0ubuntu2.1
Architecture: amd64
CurrentDesktop: Unity
Date: Sat Jul 16 21:23:50 2016
InstallationDate: Installed on 2011-04-26 (1908 days ago)
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release amd64 (20101007)
SourcePackage: recoverjpeg
UpgradeStatus: No upgrade log present (probably fresh install)

Revision history for this message
Robin Sheat (eythian) wrote :
Revision history for this message
Sam (sam-rfc1149-deactivatedaccount) wrote :

This is fixed in recoverjpeg 2.6.1 which has just been released.

See https://www.rfc1149.net/devel/recoverjpeg/

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package recoverjpeg - 2.6.1-1

---------------
recoverjpeg (2.6.1-1) unstable; urgency=medium

  * New upstream release. (LP: #1603685)
  * Bumped DH level to 10.
  * debian/clean: added to remove files forgotten after build process.
  * debian/control:
      - Added pandoc to Build-Depends field.
      - Bumped Standards-Version to 3.9.8.
      - Updated the Vcs-* fields to use https instead of http and git.
  * debian/copyright:
      - Added an Upstream-Contact field.
      - Updated the upstream and packaging copyright years.
  * debian/watch:
      - Bumped to version 4.
      - Removed a source to avoid conflicts with uscan.

 -- Joao Eriberto Mota Filho <email address hidden> Wed, 16 Nov 2016 11:52:19 -0200

Changed in recoverjpeg (Ubuntu):
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.