File Ext Disappears When I Move Files

Help & Support
21

Would it be more palatable if I had used the Wiki-PediA reference, given by Gemini AI, to an article discussing how magic (file) numbers help to identify file types, even ones lacking a filename extension? Agreeing, as it does, with what Jon alluded to earlier in the discussion.

Is Gemini AI correct in stating that the magic number of an XLSX file is ’PK’ in the hex header? If REN56 loaded his no-ext XLSX file into a hex editor, he would likely find ’PK’ at the start of the hex header. I just created a new XLSX file with only one cell entry and then examined it using a hex editor. Just as suggested, the first two bytes are “PK”.

Next up, is Gemini AI wrong when another of its four suggestions point to the location for the Shell Icons Cache, IconCache.db? On my Win 7 machine there is only one such file located in %appdata%\Local.

Now, I well know that AI can be wrong. It suggested the cache file is in %appdata%\Local\Microsoft\Windows\Explorer. Is it wrong about the location or is that a Win 10 location? In any case, since the icons were not missing in REN56’s examples, does that mean the Shell Icon Cache is complete? Or perhaps REN56 may find creating a new cache file will shed more light on the missing extensions, as they may rebuild in the cache as he opens the files. Or at least prompt more research about the contents of the Shell Icon Cache.

I know AI can get confused, especially after several rounds of questions and refinements. I’ve seen where it loses track of time after “we” have set up a discussion for the next morning of the results of today’s course of testing by it asking, ten minutes later; “How did the test go?” But my experience tells me that the more concise and conservative the query, the better the answers received from AI (only two that I have experience with; XhatGPT and Gemini AI).

Should we be so picky about where all information comes from? When Gemini AI refers to a WikiPediA article, should that info be heavily discounted because the AI LLM gathered it in rather than we ourselves having done the digging? Having said that, I understand, allowing AI a free hand in coding is asking for trouble.

No matter where on the internet we fish for info, it is up to each of us to decide whether the info found is reasonable and correct. I am quite sure that I am not the only one to find errors in MSKB and yet we rely on it heavily. Will you still once it takes on (soon) the AI hat?

As the foot soldier to some ancient Greek warlord said, “Don’t kill the messenger”, ......just before they quartered the poor bastard for bringing bad news.

In the end, the appearance of the XLSX File in the Type column was due to some action by Windows not related to the file’s non-existent file extension. Gemini gave REN56 some avenues to explore.

22

For further troubleshooting, I agree that points 2 (ShellIConCache) and 4 (double-clicking on the extension-less XLSX file to see if it opens).... even after it became a lowly ""File" after the copy action, are the steps I would take if in REN56's shoes. (Where is REN56? Shame he's not here to enjoy all this free kibbutzing).

23

That's also at the start of every zip file, and has no relevance on the problem we're discussing, as file content doesn't affect what appears in the Type column, nor what the file's name or extension is.

The issue also isn't related to the shell icon cache. The AI suggesting that is wasting your time, and you are wasting our time by repeating its outputs in this thread. AI slop is banned on this forum for a reason, and that won't be changing. Your attempt to convince us it is useful has only reinforced that it isn't.

I don't see how any of this discussion is helping solve the actual problem. Let's stay on topic please.

24

I thought I was. If REN56 double-clicks on the workbook that now displays as a simple FILE and it opens into Excel, then the problem that remains is to find all the files on that drive that have no extension and that have "PK" in the first two bytes of the header. Once found, then replace the extension with 'XLSX' by script or, more laboriously, open each file and then save it.

How would you proceed in solving the problem if it encompasses more than a handful of extension-less workbooks? Do you have an idea how to winnow out any ZIP files that have lost their extension?

25

Hi everyone,

Thank you for digging into my issue and taking it so seriously. The discussion has gone a bit over my head, but I did see a request in one of the post to share the problem files if I can. As far as I know I will be able to do so. Please let me know where to share them to.

In answer to some of the questions I saw. All of these files are on my local drive. To my knowledge, I'm doing nothing exotic. No hidden characters or anything like that. I wouldn't even know how to do that.

Some of the files are created by me. Others were sent to me on email. Doesn't seem to matter. And as I mentioned before, the issue does not occur consistently. I just created a new Excel file and it was created showing the proper ext., exhibiting none of the issues discussed.

One behavior I want to point out. As you'll see on the attached screenshot, the files in the Sandkings folder do not show a file extension on the filename itself. When I copied them to the Sandkings Temp folder, they all exhibited the issue of dropping their extensions. I then added the proper extensions onto each of the filenames in the Sandkings Temp folder. If these same files (in Sandkings Temp) are now moved or copied, they do not exhibit the issue.

Anyway, happy to share these files is you like. Just let me know where.

Thx,
Bob

Opus Share

26

What does the Properties dialog show for one of those files without an extension?

27

You can either (or both):

  • Zip the two folders (Sandkings*) and post the zip file here (drag'n'drop in the post). Ziping may change the filename/extension if there is something weird, so another possible option is:
  • Use something like https://wetransfer.com/ and share the link here.

One quick additionnal question: how did these files get there? Were they edited and saved in this Sandkings folder directly by their editing app? Or were they somewhere else and got copied/moved here?
In case it's the second option, interested in knowing how this was achieved (drag'n'drop from email? windows explorer? where to? Opus directly? explorer?....).

28

Most of the files were sent to me on email. If I drag them or copy and paste them to windows explorer the extension corruption occurs. If I drag or copy/past them to Opus, there's no corruption.

Anyway, I believe I may have discovered a bug in windows explorer causing all this. There's a setting in WE Options/View called "Hide extension for known file types". If that option is selected then the problem behavior occurs. If the option is not selected, copying files from email to WE does not result in corrupted extensions.

Surprisingly, turning this setting off also seems to correct files that were previously copied from email to WE.

Let me know if you have any thoughts. But it appears the issue has absolutely nothing to do with Opus.

I simply need to turn off the Hide Extensions setting in Explorer.

..Bob

29

This is definitely weird!!
That WE options is not supposed to affect the way files are actually copied (during drag&drop), only the way they are displayed.
But according to what you describe, this is actually the case, but in a strange way (like if the extension was left out but you somehow get some "shadow" of the extension since the file type displays XLSX File, DOCX File, PDF File).
I'd say drag them to opus (or leave the option to display extensions on) if you're to drag them to WE...
First time I see this.

As a side note:
Since we relied on some AI to try and understand the mechanisms behind all this, I tried this. According to Gemini, this can occur due to bad OLE integration of mail client combined with that option interfering with the extension definition upon drag&drop so that it ends up malformed, like adding some non printable character in it! This is not backed up by any source and could also be pure hallucination. Gemini suggests to try dir /x on the folder via console/terminal to see if the short name really ends up with .XLSX which would be a proof of a long name malformation.

It would still be interesting to get the properties as requested by Jon or the files themselves (zip or something else).

30

So this doesn't involve Opus?

But you also said this, so I am not sure I understand:

31

My understanding is that the first sentence is related to how the files are first getting on the file system: drag and drop from email client.
The second sentence applies to operations done after that, once the files with what seems to be corrupted extensions are on the file system.

32

Hi,

Yes, PassThePeas interpretation of my statements is correct. Sorry for confusion.

Here's a link to a folder containing files dragged from Outlook to 1) Opus 2) Explorer with Hide Extensions turned on. Hopefully you'll see the same behavior - when moved using Opus the files in the "... to Explorer" folder will lose their extensions. the files in "...to Opus" won't.