yeah,. fuse filesystems are tricky. they can be anything ... remote, or even hang on access, or just take a long time.

if there is a fuse fs you could also access stuff directly without libgphoto2

@hfiguiere - it looks like you were the author of the commit that removed the FUSE code. Do you remember why (I know, I'm asking you about something from 9 years ago!)?

I don't understand. Why does libgphoto even care if the filesystem is remote? Is the problem that it could hang when trying to do the stat to discover the /DCIM folder, causing bad behavior for GUI applications (such as Darktable) that rely upon libgphoto?

If fear of hanging is the problem (which I can appreciate, I've experienced how annoying/hard to track down it is when my sshfs just decides to hang when I'm trying to do something simple like ls, for instance), how about continuing to blacklist "fuse", but whitelisting known "good" (probably won't hang when accessing them) FUSE filesystems (such as this exFAT driver, and I'd probably suggest the NTFS driver which also uses FUSE).

At the very least, it's impossible for someone reading the code or searching through the commit history to discover why FUSE support is disabled. This is quite frustrating to an end user who is just trying to get their 64 GB SD card working. AFAIK, exFAT (or NTFS) are the only real options for an SD card > 32 GB, as FAT32 only goes up to 32GB, and it looks like @FatBoyXPC's Nikon camera only supports exFAT. I don't think telling people to go through the filesystem is an acceptable answer here, as most end users aren't using libgphoto directly, they're using some other applicaiton (such as Darktable) that depends on libgphoto. Any such users are just going to be confused why their application isn't seeing their exFAT cards, but will see their smaller FAT32 cards.

So you are complaining that exFAT doesn't work. Please read this about exFAT:
https://en.wikipedia.org/wiki/ExFAT#Restrictive_licensing_and_software_patents

In short, don't use SDXC.

Also if your camera is USB Mass Storage you don't need gphoto at all for downloading files.

As for that commit 9 years ago, without checking, it is likely the one about ignoring FUSE gphoto when listing filesystem: infinite recursion. NINE years ago we wouldn't think that card vendor would be stupid enough to let Microsoft f**** over.

Supporting exFAT is definitely out of scope. Switch your Nikon to PTP mode. Or use SDHC cards.

Regarding hooking the camera up directly, I think you're missing the point.
The point is that I specifically want to use my memory card(s). I went on
this mission to switch my work flow from Lightroom to Darktable with
minimal differences (importing from SD card being an important thing not to
lose). Hooking the camera up is too cumbersome and I don't think the camera
supports USB3 (yes, I like faster transfer speeds!).

To clarify - I'm not using gphoto to download the photos, I'm using
Darktable directly. I was curious why Darktable didn't pick up my memory
card, but did pick up my friend's. I learned Darktable used/depended on
libgphoto and went down the rabbit hole.

Why is supporting exFAT out of the scope? There are many other supported
filesystems. I don't think "Don't use -this thing-" is a proper solution, I
think it more of a temporary workaround. These cards will only become more
common as time goes on, so eventually, these will need to be supported
anyway.

Regarding that commit that "must not be important" - I put that in my
original post with a link to the commit. It's in the 2nd to last paragraph.
While nine years ago the assumption might have been made about Microsoft,
it's now determined that assumption is false. It's probably time to do
something about it.

Again - there is an answer to this. We can blacklist FUSE as a whole, and
whitelist certain known good application of FUSE (such as exFAT and NTFS as
@jfly suggested). Doesn't this give the best of both worlds?

On Fri, Feb 5, 2016 at 9:18 PM, Hubert Figuière notifications@github.com
wrote:

Supporting exFAT is definitely out of scope. Switch your Nikon to PTP
mode. Or use SDHC cards.

—
Reply to this email directly or view it on GitHub
#39 (comment).

exFAT is out of scope because it is a file system. libgphoto does implement filesystem, it implement communication protocols that are exposed through APIs. The "disk:" driver is just wrapper around the filesystem API provided by the OS. Again, no knowledge of the filesystem.

But it does have knowledge of the filesystem, at least a little bit. It's checking against a list of known filesystem types and names.

Doesn't the fact that gPhoto explicitly ignores volumes based on the filesystem drivers used to mount them make it very much in scope? That's quite the opposite of "no knowledge of the filesystem." It would be great if we could get some context for what necessitated blacklisting FUSE file systems and figure out if that concern is even still relevant all this time later

fd and floppy are NOT filesystems. FUSE is blacklisted because there is a gphotofs FUSE filesystem. You don't want recursivity, do you?

How about "import from folder". Doesn't darktable to that?

So it should be possible just to have libgphoto ignore gphotofs volumes without taking the hammer to all of FUSE, right? I'll have to poke around at it some if I get some time

As a side note, Darktable doesn't actually do import from arbitrary directories on the file system the same way it does from devices that gphoto detects. But that seems secondary at this point to the fact that the library simply ignores any file system mounted through a FUSE driver, which I imagine has probably confused and frustrated many a user before who didn't have the patience to track down the actual code responsible for their issues, and will likely continue to do so. Is this behavior documented anywhere?

Yes, DT will "import from folder", however, they have purposely made that behavior in a way that it will only reference the files there instead of copy them.

Why are fd and floppy not filesystems? I know that they are being checked against (and ignored if those fsnames are found).

Why don't you want to fix darktable instead.

Well, fixing this actually fixes both in that it gives exFAT support to this library, which consequentially fixes Darktable. Two birds, one stone.

Why are you so opposed to this? Doesn't this all around make this library compatible with more things?

I would characterize Darktable's approach as a product decision. Not one I'm a huge fan of, but they've made it pretty clear that they don't want to be in the file management business and only see the import module as a way to get images off of a device through libgphoto.

I would characterize libgphoto's behavior here as a bug. The library is designed to recognize mounted volumes with a DCIM directory as a camera device, but for a certain subset of external drives (anything that mounts through FUSE) it inexplicably fails to perform as expected. And it takes a very substantial amount of digging to even figure out why. That really seems like something worth a fix

So your solution is to fix a broken app by breaking a library that other app uses. Sounds legit.

No, my solution would be to fix the library. Like I said, Darktable is really secondary at this point, this is an issue in the library that deserves a fix. Arbitrarily disregarding a huge swath of file systems because a single one of them is problematic is unexpected, confusing, and frustrating behavior for end users. It's a huge (and worse, not documented as near as I can tell) feature regression just to fix that one issue, and there has to be a better way to resolve it.

Speaking of gphotofs - that condition is already being checked a few lines above the fuse line (at the end of the fsname block, just before the fstype block). If all we care about is gphotofs causing an infinite loop, that line will certainly prevent it, right? When looking at the commit that introduced this fuse condition, the gphotofs line did not exist. Does this mean the fuse conditions can be removed altogether since gphotofs is already being checked?

well, one approach to solving this would be whitelisting specific fuse filesystems as needed. e.g. exfat.

can we detect that this fuse fs is an exfat?

/etc/mtab output from 1st comment does not look like it, but what do you see with /proc/mounts ?

i tried a fix and it seems to work on opensuse

I think once it is mounted, the fs type is going to show up as fuse (just due to the driver). That's an assumption on my part, though! That fix seems simple enough, though! Thanks!

i think i have good code in ... will be in 2.5.10