covergen fails to find epubs

[Yuubari]

covergen finishes immediately without doing anything:

PS C:\Software\Kepubify> .\covergen-windows-64bit.exe --regenerate
Finding kobo reader
... Found Kobo Libra H2O at M:
Finding epubs
... Found 0 epubs
Generating covers
0 covers (0 books): 0 updated, 0 errored, 0 skipped, 0 without covers

There are 6.4 GB of epub files in M:\Books.

Wonder if this is related to mattn/go-zglob#27 somehow?

[pgaskin]

That could be likely. Can you try running dir /w /q in the root of your Kobo from Command Prompt and post the output?

[Yuubari]

Sure:

M:\>dir /w /q
 Volume in drive M is KOBOeReader
 Volume Serial Number is 5DB1-CC8D

 Directory of M:\

[.kobo]                   [.adobe-digital-editions] [.kobo-images]            [Books]
[Digital Editions]        driveinfo.calibre         metadata.calibre
               2 File(s)        600,949 bytes
               5 Dir(s)     450,940,928 bytes free

There is also the usual System Volume Information directory. This is a Kobo Libra H2O.

[pgaskin]

Oops, I mixed up the flags (I don't use Windows). I meant to show a verbose listing, not a wide one, but I think I know why. Are you able to access the System Volume Information dir in Explorer?

[Yuubari]

Yes; this is FAT32 so the usual ACLs do not work. Python's os.walk() with onerror set does not result in the error handler being called (to clarify: I am calling os.walk() on the root directory of the e-reader). Explorer is able to open this directly, and unprivileged cmd can list the contents:

M:\>dir "System Volume Information"
 Volume in drive M is KOBOeReader
 Volume Serial Number is 5DB1-CC8D

 Directory of M:\System Volume Information

06/11/2019  15:16    <DIR>          .
06/11/2019  15:16    <DIR>          ..
06/11/2019  15:16                12 WPSettings.dat
06/11/2019  15:16                76 IndexerVolumeGuid
               2 File(s)             88 bytes
               2 Dir(s)     452,165,632 bytes free

Update: I will try to debug this locally later to see where it might be failing.

[Yuubari]

In the end, I have no idea about Go (never touched it before) so to work around this issue I did this in covergen.go:

func filevisit(filelist *[]string) filepath.WalkFunc {
	return func(path string, info os.FileInfo, err error) error {
		if err != nil {
			return err
		}
		if strings.EqualFold(filepath.Ext(path), ".epub") {
			*filelist = append(*filelist, path)
		}
		return nil
	}
}

func scan(root string) ([]string, error) {
	filelist := []string{}

	err := filepath.Walk(root, filevisit(&filelist))
	if err != nil {
		panic(err)
		return nil, err
	}
	return filelist, nil
}

This way it works fine.

[pgaskin]

That's pretty good for a first attempt. I guess I could switch to filepath.Walk since zglob's performance isn't strictly needed in this situation. This seems to be a bug in zglob, but not the one you mentioned.

A few comments:

• You don't need to panic as well as return the error -- returning it is enough.
• You can simplify the definition of filelist to var filelist []string.
• Using a closure would be better in this case, as then you wouldn't need to pass the slice around like that.

[Yuubari]

Thank you for the pointers; I come from mainly Assembler, C and Ada, Go just is not quite my cup of tea so I never tried it before but your Kobo tools are quite nice, so I decided to try my hand at finding a workaround.

Would you like me to polish this a bit and submit a PR?

[pgaskin]

Would you like me to polish this a bit and submit a PR?

If you want to. Otherwise, I'll just commit it directly.

[Yuubari]

I would rather avoid adding extra steps and the possibility of further mistakes, so I will leave it to you. Thanks!

[pgaskin]

OK, I'll do it next week.

[pgaskin]

Sorry, I forgot about this. I'll do it tomorrow.