Top is windows file explorer, right is the file properties, and bottom is Directory Opus where the data isn't showing.
I've tried refreshing, waiting, navigating to different folders and back, fully closing Directory Opus, rebooting, opening in windows file explorer and showing the same columns, adding and removing columns, and changing the view to other views and back. Probably a few other things as well. 2 day old install, no plugins.
Which Opus version are you using?
Under Preferences / Viewer / Plugins, is the Video & Audio plugin enabled? What does its configuration window look like?
Current settings. I also just tried checking 'Windows Shell' under 'Metadata Methods' and fully restarting DO. No change. Reverting that option now.
Hmmm, I can't seem to find an "About" anywhere.
The installer is DOpusInstall-13.21.exe. Downloaded from https://www.gpsoft.com.au/download/release. Unsure if that is the current version (not sure if automatic updates are a thing with DO).
Further testing:
Regardless of folder name, copying a file from that folder into another seems to work fine.
Duplicating a file also causes the info to appear for just that file.
I'm wondering if DO just failed to fetch the metadata for some reason and won't retry even on a refresh.
This is unfortunately not a fix, as many folders and files have this issue for me. Is there a way to force DO to fetch the metadata?
Is that a cloud storage folder? If the files are in offline storage Opus won't be able to retrieve metadata from them.
Is that a cloud storage folder?
No. I included the drive/folder/file path at the top. All screenshots are on the same drive. So it is working in some folders, but not others. The screens of copying a file and it working in the same folder also should rule that out.
If you turn on the General > Attributes (or "Attr" for short) column, which letters does it show for the files? (Something may have flagged them as offline even though they aren't really. Easily fixed if so.)
When you copied the files to another folder, was that copy done using Opus or another tool? (If Opus is able to copy the files, that rules out a bunch of possible causes.)
Seems like you're on to something...
I deleted the other copy and made a new one in DO (which it did fine, same result though).
However the -----o- for attributes on the files not showing details makes me think you're right.
I got it reproducible.
I added one of the files to a 7zip archive with 7zip. Moved it to a different folder, and used the 7zip right-click context menu to "Extract to "archivefilename""
Resulted in the -----o- attributes.
Edit: Further testing
Folder names link to the testing I did:
7zWinFileExp: I extracted using 7zip in Windows File Explorer.
WinFileExp: I extracted using windows native archive handling.
DO Extract: I extracted using DO native archive handling.
No additional label: I extracted using 7zip in DO.
So it does seem to be linked to at least 7zip, curious if it's other archive handling programs as well. It is interesting that Windows File Explorer doesn't have an issue with the details when extracted using 7zip.
It is also curious that the file extracted with Windows File Explorer's native handling retains the 'archive' attribute bit.
Edit2:
Even further testing.
Windows does not see the file as offline.
The files all have the offline attribute set on them. Opus avoids reading from files that are marked as offline to avoid triggering a download of the data from cloud storage.
The files all have the offline attribute set on them. Opus avoids reading from files that are marked as offline to avoid triggering a download of the data from cloud storage.
Then why is there no offline attribute when listing the file in the terminal?
The terminal listing may not include that attribute. There are lots of attributes which are usually not included (even in Opus).
The 7z format will preserve the attribute if told to. Tools creating or extracting files should really filter it out to avoid marking files as offline when they aren't, but it's easy to overlook. (We overlooked it ourselves at first as well.)
To fix the files, you can create a button in Opus to run the DOS attrib command on them:
Clear Offline attribute.dcf (266 Bytes)
That runs this command, in MS-DOS Batch Mode:
attrib -O {filepath$}
Select the files and run that on them and it should fix them.
Added the button. Selected the file, clicked the button. Terminal window was created and exited in an instant. Hit refresh. No change.
Checked in cmd, file didn't have Offline attribute. I can add it, and remove it. No change even after a refresh in DO.
This did get me thinking. I'm not familiar with X P U attributes. I looked into them:
X is
FILE_ATTRIBUTE_NO_SCRUB_DATA
131072 (0x00020000)
The user data stream not to be read by the background data integrity scanner (AKA scrubber). When set on a directory it only provides inheritance. This flag is only supported on Storage Spaces and ReFS volumes. It is not included in an ordinary directory listing.
P is
FILE_ATTRIBUTE_PINNED
524288 (0x00080000)
This attribute indicates user intent that the file or directory should be kept fully present locally even when not being actively accessed. This attribute is for use with hierarchical storage management software.
U is
FILE_ATTRIBUTE_UNPINNED
1048576 (0x00100000)
This attribute indicates that the file or directory should not be kept fully present locally except when being actively accessed. This attribute is for use with hierarchical storage management software.
I removed each, one by one, refreshing the folder each time. X and P were removed with no change. The instant I removed U, Opus populated all fields and stopped showing the Offline attribute.
It seems like Opus is reading U as Offline.
Unpinned also means Offline, and shouldn’t be set on files that aren’t in cloud storage. Something set that attribute by mistake.
XPU seems to be set in some archived files from archive.org.
Anyway, thank you greatly for the assistance. Only possible change I can think from this is allowing P to take precedence over U.
Even if they're (incorrectly) set in some archives, the tools that extract those archives to a Windows filesystem should be filtering out those attributes. I would report this to the authors of whichever tool you extracted the archives with, as it will definitely cause other problems for people.
(We fixed the same thing in Opus some years ago.)
Of course, if it was Opus itself that extracted them, then please give us details of an example archive as we'd want to fix that. AFAIK it shouldn't happen with our code, but we may have missed a situation where it still can.
