Closed oweitman closed 2 years ago
This seems sensible. Out of interest, which filesystem supports hardlinks and not softlnks?
Not sure if I have the same issue but I am using the sync to pull down photos from one album and keep getting ERROR Symbolic links not supported I triied --use-hardlinks and same results
I am using the code on a raspberry-pi Distributor ID: Raspbian Description: Raspbian GNU/Linux 10 (buster) Release: 10 Codename: buster Kernel: Linux 4.19.118+
i have mounted a NAS-Drive with Samba/SMB-Protocol with the following parameters //192.168.1.125/Public/Shared\040Pictures/_googlesync /media/fotosync cifs auto,username=username,password=password,vers=3.0,mfsymlinks,iocharset=utf8,file_mode=0777,dir_mode=0777,noperm 0 0
testing symlinks with the following commands touch /media/fotosync/test ln -s /media/fotosync/test /media/fotosync/symlnk results in error ln: failed to create symbolic link '/media/fotosync/symlnk': Operation not supported
create hardlinks is succseful ln /media/fotosync/test /media/fotosync/symlnk
one more alternative maybe is an option to download duplicate pictures for the albums
@oweitman Thanks, good to know. I'll change the logic to check hardlink capability and a then allow album creation if you specify hardlinks.
@wardwellb I use a pi 4 as my backup server so it can work on this, however it is the file-system you are backup up to that is relevant. Where are you storing your files and how is it mounted on your pi?
sorry I have forgotten to follow up on this - will try to do so this week (probably weekend)
@wardwellb I use a pi 4 as my backup server so it can work on this, however it is the file-system you are backup up to that is relevant. Where are you storing your files and how is it mounted on your pi?
@gilesknap I currently have a usb thumb drive connected to the pi and have the files stored there. Images sync up just fine but gives me the the error of "symbolic links not supported" Gotcha, with the usb formatted in Fat32 so that I can easily view it on windows...symlinks are not supported in Fat32 Do you have a suggestion of making it not sync the album and attempt to create the symlinks each time I update?
Hi sorry for the late reply.
There is an argument --skip-albums that does what you need.
Use --help to see full list of arguments.
On Thu, 2 Jul 2020, 18:21 wardwellb, notifications@github.com wrote:
@wardwellb https://github.com/wardwellb I use a pi 4 as my backup server so it can work on this, however it is the file-system you are backup up to that is relevant. Where are you storing your files and how is it mounted on your pi?
@gilesknap https://github.com/gilesknap I currently have a usb thumb drive connected to the pi and have the files stored there. Images sync up just fine but gives me the the error of "symbolic links not supported" Gotcha, with the usb formatted in Fat32 so that I can easily view it on windows...symlinks are not supported in Fat32 Do you have a suggestion of making it not sync the album and attempt to create the symlinks each time I update?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gilesknap/gphotos-sync/issues/244#issuecomment-653130182, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHLRWYMMXIJQZWJSVJGRADRZS6YLANCNFSM4NZWOOFQ .
I have now tried the "--skip-albums" again and this still shows the same errors as before the skip albums. Where it attempts to create the symlinks for the album
Just to double check is my command correct?
pipenv run gphotos-sync --skip-albums /media/pi/0012-D687/frame --album "album-name"
Let me know if you need more information or if I am doing something incorrectly
hmmm, this might be an issue with the combination of --skip-albums and --album. I can see why it is useful to supply both in this case. I'll investigate ...
Sorry for the delay, I've not had much time to spend on gphotos-sync recently but will fix this soon(ish)
How about defaulting to:
With switches to skip trying symlink and to skip trying hardlink. Specifying both forces copy.
yep I like that. It means that the default behaviour with no flags is as friendly as possible.
On Wed, 29 Jul 2020 at 07:46, Roger Dahl notifications@github.com wrote:
How about defaulting to:
- Try to create a symlink
- If that doesn't work, try to create a hardlink
- If that doesn't work, create a copy of the file
With switches to to skip trying symlink and to skip trying hardlink. Specifying both forces copy.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gilesknap/gphotos-sync/issues/244#issuecomment-665467765, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHLRWYJ76YPTWO5M46M2Y3R57ATBANCNFSM4NZWOOFQ .
Any updates on this issue? Personally looking forward to the most recently proposed solution that would fallback to creating duplicates within the albums.
I've been a bit distracted. I'll try to take a look this week.
I'm releasing a new version of gphotos-sync and closing stale issues. Please reopen if you still want me to look at this. Thanks.
if symlinks are not supported albums are not scanned. https://github.com/gilesknap/gphotos-sync/blob/e5d3185037fc6fbca0f0b9e5fa9f7bd2accdf893/gphotos/Main.py#L378
please check for parameter use_hardlinks in the following lines https://github.com/gilesknap/gphotos-sync/blob/e5d3185037fc6fbca0f0b9e5fa9f7bd2accdf893/gphotos/Main.py#L340 https://github.com/gilesknap/gphotos-sync/blob/e5d3185037fc6fbca0f0b9e5fa9f7bd2accdf893/gphotos/Main.py#L354
or here https://github.com/gilesknap/gphotos-sync/blob/e5d3185037fc6fbca0f0b9e5fa9f7bd2accdf893/gphotos/Main.py#L378