2

I made a backup of a directory with some directories inside, using rsync -aPv source/ dest. It did not output error messages, neither returned a failure status, and progressed through to the end. It copied every file from source into dest, or so have I thought.

The problem is that only the files from the root of the source directory were properly copied, and can be opened and used. The rest of the files and the directories have somehow corrupted, and errors occur:

~/Pictures $ cd Screenshots/
cd: Permission denied: “Screenshots/”
~/Pictures $ ls -l Screenshots/
ls: cannot access 'Screenshots/2016-05-02-23:11:15.png': Permission denied
ls: cannot access 'Screenshots/2015-08-07-17-26-33.png': Permission denied
ls: cannot access 'Screenshots/screenshot_2019-05-27_20-41-55_665836194.png': Permission denied
ls: cannot access 'Screenshots/screenshot_2019-05-05_23-17-16_571047883.png': Permission denied
...
total 0
-????????? ? ? ? ?                ? 2015-03-22-03-49-39.png
-????????? ? ? ? ?                ? 2015-04-03-20-17-31.png
-????????? ? ? ? ?                ? 2015-05-18-22-09-39.png
-????????? ? ? ? ?                ? 2015-08-07-17-26-33.png
...

I can access those directories using certain file managers (I tried PCManFM; ranger did not work) and it reveals the files are corrupted and can not be opened with designated default programs (e.g. qimgv for images, mpv for videos).

I am unsure if this issue has corrupted the files or the directories only, in a way that the actual content is not accessible but maybe it is still there, or maybe metadata is corrupted (they are JPG and PNG files mostly). How can I recover access to those files and their content?

  • 4
    This may be a bad disk rather than something that rsync caused. – Kusalananda May 30 at 21:30
  • @Kusalananda running fsck on the partition checking for bad blocks did not give errors. – ranisalt Jun 2 at 2:30
5

The output is exactly like what you get if you try to list a directory whose x permission bits are missing.

Here's an example on how to reproduce the situation:

$ cd /tmp
$ mkdir dirperms
$ cd dirperms
$ touch foo bar baz
$ mkdir zot
$ cd ..
$ chmod a-x dirperms
$ cd dirperms
bash: cd: dirperms: Permission denied
$ ls -l dirperms
ls: cannot access 'dirperms/baz': Permission denied
ls: cannot access 'dirperms/bar': Permission denied
ls: cannot access 'dirperms/foo': Permission denied
ls: cannot access 'dirperms/zot': Permission denied
total 0
-????????? ? ? ? ?            ? bar
-????????? ? ? ? ?            ? baz
-????????? ? ? ? ?            ? foo
d????????? ? ? ? ?            ? zot/

So, using testdisk was probably overkill; you could simply have fixed the permissions of the Screenshots directory with a chmod -R u+X Screenshots.

The root cause of erroneous permissions might be that the original source filesystem was perhaps a filesystem that did not support Unix-style permissions, and so the permissions reported by the filesystem driver (for the sake of POSIX compatibility) did not match the reality of what the driver actually allowed rsync to access. So rsync replicated the fake permissions to the destination filesystem, where they were actually used as real permission settings, thus causing the problem.

  • Thanks for the detailed explanation. The source and destination filesystems are the same, though. – ranisalt Jun 10 at 5:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.