- Issue created by @dcdev11
- π³π±Netherlands megachriz
Can it be that some records reference text files that are in a different directory, but with the same name?
The error message says that a file from the temporary directory could not be written to either the public or private file system because on that file system there already exists a file with the same name.
I'm unable to reproduce the error however. Even when I try to import a CSV file like the following, I don't get an error:
guid,title,file 1,A,http://example.com/feeds/txt/a/sample.txt 2,B,http://example.com/feeds/txt/b/sample.txt
Or this:
guid,title,file 1,A,http://example.com/sites/default/files/bijlagen/sample.txt 2,B,http://example.com/sites/default/files/bijlagen/sample.txt
Can you try to reproduce the issue on a clean install? Maybe a file related module is configured in a way that causes this issue.
Using private:// or public:// as file source is indeed not yet supported. Only http sources are supported at the moment. There is a request to support the local file path a source: β¨ File target: add support for local file path as source Needs work .
I have used a multidev to remove the translation module, thinking it might be generating a temp file request that is problematic, but it didn't impact the error. If there are other modules that are likely suspects, I can remove there. I was considering making a fresh install and trying to recreate the error. I'll probably do that, but it's a fair bit of set up.
RE
Using private:// or public:// as file source is indeed not yet supported. Only http sources are supported at the moment. There is a request to support the local file path a source: #2968671: File target: add support for local file path as source.
Not trying to be difficult, but I don't understand how this is the case. The feeds source that runs the import file references private://ourfeedsdata/importfile.txt. Immediately above the feeds tamper for images, is the feed tamper for .txt file which uses private://ourfeedsdata/[textfiletoken] and works if image import field is unused.
The image field used to replacement pattern private://ourfeedsdata/[imagefiletoken] in D8 and D9 on our internal nginx servers for around 18 months and worked without issue. It also worked when we set it up in pantheon in 2023 (not totally sure when it stopped working but we moved to the above direct public file reference last year)
Can it be that some records reference text files that are in a different directory, but with the same name?
Hi,
So duplicate names file does seems to be the issue. Still working on pinning down the exact process that hits the error, but I cleared the most recent real world error set by making sure the file name wasn't duplicated anywhere.
Let me know if you have experience clearing that problem. The duplicate image files are sometimes the same img src that show on the site, so I can't erase in bulk.
- π³π±Netherlands megachriz
Did you try to reproduce the issue on a clean install? Because when I import two items with the same exact file (with the same name), then I get as result that both items reference the same file entity. In your case, you get an error. So there must exist a difference between my setup and your setup. The most likely difference is that you:
- Have a module installed that I have not.
- And/or have configured a file related setting differently.
To find out what that difference is, try to replicate the error on a clean install so we know which module or setting causes a different behavior.
Based on the current info, the only possible solution that I see is making sure that file names are unique. But there could perhaps exist an other solution if we can find out what causes a different behavior.