$(YEAR) variable in Import settings doesnt work on windows 10 > DT 3.8

Introduction
the default naming pattern of:
$(YEAR)$(MONTH)$(DAY)_$(JOBCODE)
Gives me the directory name
$(YEAR)0119_no_name
So the $(YEAR) variable doesn't seem to work.

Did you buy darktable from an application store ?

darktable is free but selling it is technically allowed by the license, at the condition that
the seller provides extra services and assistance to users.
If you bought darktable on a store, it was not from the darktable team but from a third party.
Support is therefore the sole responsibility of the third-party seller,
and the darktable team will not offer free support for licenses paid to a third-party.
Please contact your seller, assistance is part of your after-sale rights.

Describe the bug/issue
The default import naming pattern for "subdirectory naming pattern":
$(YEAR)$(MONTH)$(DAY)_$(JOBCODE)
Gives me the directory name
$(YEAR)0119_no_name
So the $(YEAR) variable doesn't seem to work.

Low priority, but wanted to report it. Workaround obviously to just use actual year instead of variable,.

May be windows 10 specific

To Reproduce
Attempt to import images and use $(YEAR) in the "subdirectory naming pattern"

Expected behavior
$(YEAR) > 2022

Platform
_Please fill as much information as possible in the list given below. Please state "unknown" where you do not know the answer and remove any sections that are not applicable _

• darktable version : 3.8.0.0 e
• OS : Win 10 build 19041
• Memory : 32gb
• Graphics card : RTX 2070
• Graphics driver : 27.21.14.6259
• OpenCL installed : yes
• OpenCL activated : yes

[phweyland]

At export time does it work ?
Would $(EXIF_YEAR) work ?

Wow that was a fast response :)

Interesting, so both $(EXIF_YEAR) and $(YEAR) fails at import. BUT, exporting they both work for for both filename and directory.

So seems to be only in import.

[phweyland]

Strange indeed. For me it works (on Debian Sid).
But I don't see what could be specific to windows here ...
Maybe, whatever the variable you put in the first place fails as well ...

Yes! Its the first variable indeed (Any variable) . But if I use a 2022 instead, it works (and the first variable after 2022_ works)

But its more going in, when it imports it also runs trough the images with""
"Error loading file <directory\filename.nef"
"Imported 48 images"

From there I am not moved to that "filmroll", i have to go manually to the directory via "add to library". But it was actually imported

And after upgrading, the "recently used filmrolls" are populated, but clicking them does nothing.

This was an upgrade from 3.6, and i clicked yes to rebuild the config during install. I could try a wipe and clean install, but i tried:
darktable.exe --configdir "/tmp

And i see the exact same

I reproduced again with debug on, and see this:

darktable-log.zip

_import_session_path testingJ:camdump$(YEAR)_01_blaaaa99999999999' 1 _import_session_path testing `J:camdump$(YEAR)_01_blaaaa99999999999' 1[import_session] Using filename DSC_7902.NEF.

(darktable.exe:14096): Pango-CRITICAL **: 16:14:41.174: pango_font_describe: assertion 'font != NULL' failed

(darktable.exe:14096): Pango-CRITICAL **: 16:14:41.174: pango_font_description_get_variant: assertion 'desc != NULL' failed

(darktable.exe:14096): Pango-CRITICAL **: 16:14:41.174: pango_font_describe: assertion 'font != NULL' failed

(darktable.exe:14096): Pango-CRITICAL **: 16:14:41.174: pango_font_description_get_variant: assertion 'desc != NULL' failed
36.942758 [lighttable] expose took 0.0044 sec
_import_session_path testing J:camdump\$(YEAR)_01_blaaaa99999999999' 1 _import_session_path testing J:camdump$(YEAR)_01_blaaaa99999999999' 1[import_session] Using filename DSC_7903.NEF.

(darktable.exe:14096): Pango-CRITICAL **: 16:14:41.225: pango_font_describe: assertion 'font != NULL' failed

(darktable.exe:14096): Pango-CRITICAL **: 16:14:41.225: pango_font_description_get_variant: assertion 'desc != NULL' failed

(darktable.exe:14096): Pango-CRITICAL **: 16:14:41.225: pango_font_describe: assertion 'font != NULL' failed

(darktable.exe:14096): Pango-CRITICAL **: 16:14:41.225: pango_font_description_get_variant:

assertion 'desc != NULL' failed
36.993159 [lighttable] expose took 0.0041 sec
_import_session_path testing J:camdump\$(YEAR)_01_blaaaa99999999999' 1 _import_session_path testing J:camdump$(YEAR)_01_blaaaa99999999999' 1[import_session] Using filename DSC_7904.NEF.

(darktable.exe:14096): Pango-CRITICAL **: 16:14:41.276: pango_font_describe: assertion 'font != NULL' failed

(darktable.exe:14096): Pango-CRITICAL **: 16:14:41.276: pango_font_description_get_variant: assertion 'desc != NULL' failed

(darktable.exe:14096): Pango-CRITICAL **: 16:14:41.276: pango_font_describe: assertion 'font != NULL' failed

(darktable.exe:14096): Pango-CRITICAL **: 16:14:41.276: pango_font_description_get_variant: assertion 'desc != NULL' failed`

[kmilos]

Could it be because of the Windows path separator "\" being interpreted as a control character, i.e. it protects "\$" to be interpreted as literal "$" instead of a hint for a variable?

[dwar]

Could it be because of the Windows path separator "" being interpreted as a control character, i.e. it protects "$" to be interpreted as literal "$" instead of a hint for a variable?

I think it could be true.

If I try to import from the root of a drive, I see the first character of the folders is omitted.
My photos are in a subfolder of E:\DCIM\ . But when I'm in the root the folders shows up as CIM\ (And the import fails)

[github-actions]

This issue did not get any activity in the past 60 days and will be closed in 365 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.

[github-actions]

This issue was closed because it has been inactive for 300 days since being marked as stale. Please check if the newest release or nightly build has it fixed. Please, create a new issue if the issue is not fixed.

[Quas7]

using "/" instead of "\" for defining folder structures solves this for me on win10