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.
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)
dcdev11 → created an issue.
Looking at this I think I see an issue I didn't explain. The .txt files is extracted and become the description field value so it's not url link value or a file download location anything. A typical .txt is like bio, so it's content says "John Doe worked at the company 40 years and did all this stuff..." and that become the description field.
id,title,file
1,Foo,http://www.example.com/file1.txt
2,Bar,id,title,file
1,Foo Updated,http://www.example.com/file1.txt
2,Bar Updated,
Both of these would be expected to work if the file1's contents was updated. If we changed 40 to 50 in the years "John Doe worked at the company 50 years and did all this stuff..." then I'd expected to see any updates added to the record.
If bar is updated, but file1 is the same content it generates a temp file, gets stuck, throws an error and bar is not updated in the record.
The following are actually csv entries with dummy data that create a node type. The strings are all plain text, mostly names and other short values. Some numbers are internal, some are public facing and with associated template labels provide location information users can use and sometimes will report if they are inaccurate. The .txt file defines content for. a long description field.
Every week a csv import file is submitted and a feeds import is run. In the most recent case it had over a record hundred changes, but it can be more or less. During the import records with a .txt file that have not been updated (but other fields have been updated) will fail to update, while other records will update as expected. The feeds log will confirm the record(s) that hit the temp files error and the total number of updated/created records will be lower by the number times the error happened.
Working record update
The .txt file and nothing else had been updated and the error didn't occur. This was an updated record, but if this had created a new record for the first time it appears to work as well from my testing on the dev site. It also would work if the other data had been updated along with the .txt file.
“123”,”string”,”123,”string”,”string”,”123”,”123",”date”,”123”,”123”,”123”,”123”,"123,” ","string","string","string","string"," ","updated.txt","","string","123"
Several other times, the records looked this. The "345" represent updated numeric data in the record field values. "same.txt" indicating no changes to the file contents (in either case the name of the file doesn't usually change). In this instance an error happens following this pattern "File 'temporary://filegqK5QQ' could not be copied because a file by that name already exists in the destination directory ('') and the record can't be updated with feeds.
Failing record update
“123”,”string”,”123,”string”,”string”,”123”,”123",”date”,”345”,”345”,”345”,”345”,"123,” ","string","string","string","string"," ","same.txt","","string","123"
Most records don't have .txt files and update without issue
Less advanced working record update
“123”,”string”,”123,”string”,”string”,”123”,”123",”date”,”345”,”345”,”345”,”345”,"123,” ","string","string","string","string"," ","","","string","123"
A typical node will look like this, but the fields are optional so some records have a lot more then others.
"John/Jane Doe" //title
"John/Jane Doe associates/associations"
"More John/Jane Doe associates/associations"
"a long description field" (from the .txt file)
"an image of John/Jane Doe"
"location data" ( a typical pattern this is tba and left blank, then added a month or so later)
"date created"
A couple of internal id fields that aren't displayed.
dcdev11 → created an issue.