Symlinks break sync function

[grasponcrypto]

Describe the bug I have a few symlinks within my directories, this causes the sync function to fail.

To Reproduce Steps to reproduce the behavior:

1. In your /photos directory create a symlink ln -s /photos/dirName /photos/linkName
2. Click on 'scan'
3. See error

Expected behavior Skip symlinks and/or continue past the error

Screenshots If applicable, add screenshots to help explain your problem.

Your environment: Feel free to remove and add what you think might be useful.

• Are you using Docker? [yes]
• Database [mariadb 10.5]
• Version [undefined]
• Build Date [2021-07-22T16:25:13Z]

[viktorstrate]

The best solution might be to make follow symlinks an opt-in, as detecting cycles might be complicated.

[nakal]

Oh my god.. I've been looking for a reason why my pics are not imported at all for several days. Logs don't help at all the scan just stops after reading in all directories and says "folder has pictures" and then no single picture appears.

I changed permissions even everything is perfectly accessible. I've read across all NFS bugs here but the errors are all different.

Then I found this bug... I removed the two symlinks I use to refer 2 more private albums that also contain auto-synced photos from mobile phones.

It started to work then. I cannot imagine why you don't support symlinks. There are functions that find out the absolute paths so you can avoid circles. And even just ignoring symlinks would be a better result than this bug. Also not reporting errors at all is a bad thing.

[kkovaletp]

@nakal do you know that you could achieve the same result, as with symlinks, by using multiple volumes for the Photoview media location (1st volume to map the root folder of the main part of your media library, and then each new volume for the root folder of each originally symlinked external media lib to be mounted in some folder inside the main lib inside the docker)?

While this is a pure workaround and it does nothing with the mentioned bug, it might help you in practice

[nakal]

@kkovaletp Yes, thank you for the useful hint. I'd maybe be able to find this workaround, too, if PhotoView just reported an error/warning accessing the softlink.

[niklas88]

I too just lost a few hours on this mostly because there is still no useful error shown on the command line. It's a shame because otherwise this is an amazing app and it works great when it does scan photos.

It's especially sad because the README proudly states:

When your media has been scanned they show up on the website, organised in the same way as on the filesystem.

Well on my filesystem my photos are oganized as:

2023
  01
    photo_in_january_2023.jpg
    …
  02
    photo_in_feburary_2023.heic
    …
  …
2022
  …
New Year's Party
   photo_in_january_2023 -> ../2023/01/photo_in_january_2023.jpg
   …
 …

Which is quite practical in that it gives you both timeline and album access even in normal file browsers while not needing any copies. It's also pretty much the format the Google Photos Takeout Helper would generate once they implement my request to use relative symlinks which are still valid after mounting in docker vs absolute symlinks which break. No sadly this then doesn't work at all if you break on symlinks.

Most weirdly though just scanning the albums (e.g. New Year's Party above) did work for me!?!?

[kkovaletp]

@niklas88 I'm just curious: what will be in case you replace your softlinks with hardlinks - will it still work for you? will it start working after mounting into the Photoview container? Do you see some negative impact for this solution?

[niklas88]

Since I'm using btrfs I could use cp --reflink but this is much less portable than simple relative symlinks also with symlinks you can easily see where the "real" files are supposed to be. Also with photoview the symlinks worked when album folder was added explicitly (with the whole folder being volume mounted into the docker container) but not when scanning the whole folder.