Hello,
I actually had the same issue and message with version 3.8.1 on Windows 10 right now.
The problem appears to be the selection through the pre-defined “Image” folder from Windows.
If I select a folder within the Windows Image folder to be imported to Darktable, I do get while importing the message: Cannot write xmp file “…”: Bad file descriptor.
However, if I add the location manually ( by clicking on the Plus symbol on the top of the folder pane and walk my way through the folders until I reach the images I want to import within the Windows Image folder), the xmp files are created and I can initiate to have these overriden if desired.
That appears like a bug to me, that is existent since many versions now. I had tried it with many different versions right now and in each of the once I tried (3.6.0, 3.6.1, 3.8.0, 3.8.1) it is the same behaviour.
Meaning you will sign up with GitHub soon…? If not, someone else could probably report it for you, but it would be better if you did.
@europlatus Best leave OneDrive out of the equation. It can cause issues with open-source software. That and Defender. Either add your directories as exceptions or disable the services permanently. Maybe try symbolic linking[1] your local non-syncing folder with the OneDrive one. ([1] Forgive me if I used the term wrong…)
One other thing I though of in Windows some people have an admin account but work in a user account so that things are a bit more locked down. Again just throwing darts but any chance @K_W that might be it…if so you could try to run DT as an admin and see if the issue resolves …as I said just guessing here…
Can you describe better what is the “image” folder in windows. Is this the Libraries - Pictures? Maybe a print screen might be helpful to understand your problem.
Hi, and sorry for the long scilence!
I have worked a bit more now with Darktable and found that I had a setting on my Windows Machine that did hide the XMP files that are created when importing the image files to Darktable. When I now disable this option - I remember that I did activate it in the past as the additional files next to my image files did not suit me - then everything works fine again. No warning messages, changes are stored in the XMP files etc.
So this solved it for me.
I recognized it when I did copy all image files into a new folder and imported the new folder. The XMP files were not hidden by default in the new folder and could be created and were visible. When trying to copy these newly created XMP files back to an old folder I got a warning that the file did already exist - but was not visible.
I started noticing this error since I upgraded to v4.6.0 on Windows 11. I have my collections placed in a Drobpox issue, so this makes sense with the sync process.
I have also noticed that I usually get this message when I move a slider during a certain amount of time. When I make changes by clicking the slider I do not ususally get those kind of messages. Furthermore, some modules seem to be more prone to cause these messages than others. The new RGB Primaries modules is where I find it more frequently. But it could also be that, because it is new, I tend to play with this module sliders more than others.
But as I said, with the same computer settings I never noticed this message on v4.4.x.
Some people have reported mysterious file-related problems on Windows, which then turned out to be some Windows process (such as OneDrive sync, Windows Defender or an antivirus) locking files darktable tries to write to. Maybe check if one of those could be relevant for your case; if possible, exclude your image collection and darktable’s config from such processing.
But the tooltip says the number is in seconds. And the time it takes to get this error seems more a question of milliseconds. I tried both to set a bigger number (30 seconds) or even disable auto-saving, but the error is still happening.
@kofa I’m trying to figure out how to exclude the collection folders from Windows Defender (first preferred option) or reduce the sync frequency for those folders in Dropbox (second preferred option). But I wouldn’t like to have these folders removed completely from the cloud sync. I can do it for a quick, test but not as a long term solution.
Thank you all for your quick responses, but I hadn’t experienced this until a couple of days ago.
And the guilty was - of course - Windows Defender. I excluded my collections folders from Windows Defender and, ta-da, the issue completly dispappeared.
