Verbose sync logs trying to read a usb3 ntfs formatted HDD on osx. Every file is rejected with fileFilterNoStat. Exiftool run on the commandline works fine.
Is it possible OSX/perl/commands to foreign FS mounts are a bit iffy? I am reluctant to cp the images into local storage. (Doing import/autoarrange, so a copy is meant to come in)
That filter means that node couldn’t stat the file.
You may be banging up against macOS file security permissions: see this post for how to verify.
If that’s not the issue, please run ./photostructure info --debug /path/to/a/image/on/your/external/drive.jpg, email me the resulting logs (nothing private, please!), and we can look at it together.
The problem is that it “works” if I specify a single file. It’s failing when the request is to sync a directory tree (e.g. my google takeout) which has subdir structure
so I get failures on the dir scan (it seems) buf if I do exiftool to a specific .JPEG and then sync that specific file, its fine.
I just added photostructure by path to the System Preferences Full Disk Acess list. Didn’t seem to change this.
Monterey. Still want --debug? If I do it to a singleton it won’t break. It has to be a directory tree import from the look of things.
Further to this I did an rsync from the removable to local storage of a parallel directory structure and it syncs fine. I strongly suspect this is about the portability of the stat() call on NTFS mounted FS.
Thanks for digging into that and sharing the results. I’ll try to reproduce this soon on my mac hardware and see what’s breaking readdir.
Cheers!
Are you passing the bigint config setting to fs.readdir() and fs.stat() it defaults to false, but thats risky on 1tb external and foreign fs like ntfs, mapping disk block numbers to inodes for posix compatibility.
Its a pretty full drive and my photos are late additions at the back.
(Only a theory)
Oh, nice tip! I’ll try that first thing tomorrow morning.
I looked into that option, and the bigint option is for exact precision for file metadata that exceeds 2^52: so we’re not bumping up against that issue (at all: 2^52 is 4,503,599,627,370,496: that’s 4.5 peta bytes). I’ll poke at it soon and see what’s making readdir grumpy.