windows Filename is throwing dbase-io-windows-findfile-1

[anbraten]

Describe the bug
On windows my file isn't recognized and throwing dbase-io-windows-findfile-1. My code uses filepath.Join(pi.Config.DBPath, 'daten', 'my-table.DBF') which works on my linux clients. However on windows the path with the config prefix does not work. I printed the path Y:\some-folder\daten\my-table.DBF already and checked if it exists by entering it to win+r and everything worked as expected. I am a bit lost where the issue could come from.

To Reproduce
Example code to reproduce the behavior:

package main

import (
    "fmt"
    "github.com/Valentin-Kaiser/go-dbase"
)

func main() {
    configPath := 'Y:\somefolder'
    p := filepath.Join(configPath, 'daten', 'mytable.DBF')


      table, err := dbase.OpenTable(&dbase.Config{
		Filename:   p,
		TrimSpaces: true,
	})
	if err != nil {
		return dbase.GetErrorTrace(err)
	}
	defer table.Close()

       [...]
}

Expected behavior
It should find the file 😅

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

Desktop (please complete the following information):

• OS: windows 10 amd64
• Go version: 1.21.2
• Package version: v1.11.9

Additional context

Related code part should be the call of os.ReadDir(filepath.Dir(name)) in

go-dbase/dbase/io_windows.go

Line 788 in e80f581

files, err := os.ReadDir(filepath.Dir(name))

[Valentin-Kaiser]

Can you please provide me the error string after base-io-windows-findfile-1?
Please try to run the code again with the debug option and send me the output, then I can help you better :D

dbase.Debug(true, os.Stdout)

[anbraten]

Thanks for looking at it already. Just tested on a windows 11 machine and there it works. Will test tomorrow using the win 10 machine again and report here again.

[Valentin-Kaiser]

Any news on this?

[Valentin-Kaiser]

I hope the problem has been solved. I will close the issue for now due to lack of response. If it still exists please open it again.

[anbraten]

I have tested it again: windows 11 works, but 10 does not.

The complete error is: 2024/01/09 12:04:37 dbase-io-windows-opentable-2:dbase-io-windows-findfile-1:open Y:\...\data: Das System kann den angegebenen Pfad nicht finden.

[anbraten]

Also tried dbase.Debug(true, os.Stdout) which seems to have no effect as the actual dbase reading is never started.

[anbraten]

What's the reason for the _findFile function scanning the directory although it just seems to return the same filename in the end 🤔

[Valentin-Kaiser]

The _findFile function is intended for a somewhat more complex scenario. My library supports opening and reading dbase database files. These contain a list of all tables, but the name is not always case-sensitive. I have implemented this helper function so that the files can still be found correctly.

The interesting thing is that it already fails when reading the directory:

files, err := os.ReadDir(filepath.Dir(name))
if err != nil {
    return "", newError("dbase-io-windows-findfile-1", err)
}

Can you please test the following code?

configPath := "Y://somefolder"
p := filepath.Join(configPath, "daten", "mytable.DBF")
files, err := os.ReadDir(filepath.Dir(p))
if err != nil {
    panic(err)
}

[HighQualityWaschbaer]

I tried to reproduce this issue but did not run into any error.

I tried to be as close as possible to the given setup:

• Windows 10 [email protected]
• Go version: 1.21.2
• Package version: v1.11.9

My code:

package main

import (
	"fmt"
	"path/filepath"

	"github.com/Valentin-Kaiser/go-dbase/dbase"
)

func main() {
	configPath := "U:\\Anwendungsentwicklung\\Database Folder\\Company"
	p := filepath.Join(configPath, "Backup Version", "table.dbf")

	fmt.Printf("Opening table %v\n", p)
	table, err := dbase.OpenTable(&dbase.Config{
		Filename:   p,
		TrimSpaces: true,
	})
	if err != nil {
		panic(dbase.GetErrorTrace(err))
	}
	defer table.Close()
	fmt.Printf("Table: %v\n", table.TableName())
}

Things to consider:

• Double quotes were used and i had to use double backslashes because of unknown escape sequence error.
• The filepath on windows is case sensitive so i had to keep that in mind

[anbraten]

Thanks for having a look again, I will do some further testing and report back. (might take a bit as I normally only have access to the systems on working days)

[Valentin-Kaiser]

Any news on this?

[anbraten]

Took me quite some time to figure out. Actually it seems the path does simply not exist for the admin account, but for the normal user. Thanks for the help and sorry for stealing your time 🙈

https://learn.microsoft.com/en-US/troubleshoot/windows-client/networking/mapped-drives-not-available-from-elevated-command