I'm a bit puzzled about something - I thought that all folder labels you had set were stored in foldercolors.oxc. I think that was true for v10, but with v11, I have far more folder labels displaying in Opus than what there is listed in foldercolors.oxc - so it is obviously untrue for v11.
I've deliberately set all those labels (including the ones not in foldercolors.oxc) - that isn't the problem. The problem is that previously I would be able to backup foldercolors.oxc and then if I reinstall Opus, my folder labels would return when I copied the backup foldercolors.oxc into the new installation. Now, with v11, I don't know what files to backup to keep my folder labels. If someone could enlighten me, that would be great.
See the two new options below the list of labelled folders in Preferences.
They are described in the release notes under File and Folder Labels Improvements
Thanks Leo, that answers the backup question (i.e. there is nothing to backup now). That does lead to two follow-up questions though:
- In the Labelled Files and Folders field in Opus preferences, why are only the foldercolors.ocx folders listed? Shouldn't the field list all the labelled folders?
- Why are some folders stored in foldercolors.ocx, and others in the file system itself? For example, I removed one of the folders from the Labelled Files and Folders field in preferences, and then went back to Opus and added a label to it again. Result was that it was listed again in Labelled Files and Folders (and foldercolors.ocx) - but there are quite a few other folders on that same drive that aren't listed in Labelled Files and Folders as they are now stored in the file system. This is using Beta 3 with those two options ticked (i.e. the defaults).
If a label is stored in the file system, it is only stored in the file system, as part of the actual thing (file or folder) it is placed on. If you move or rename that thing, the label will move with it (assuming the NTFS metadata is copied, anyway). The label is not applied to a path in that case, it is applied to the actual file or folder, so the path is not saved into the config file.
You can have some labels stored in the file system and other labels stored in your Opus config pointing to particular paths, mixed together.
If you don't like the new default of storing new labels in the filesystem, simply turn it off (and fix up any labels that you have applied in the new way) and everything will be like it was before.
Ok, wo with #1, Opus only shows labels in the preferences that are not stored in the file system, correct?
With #2, it's not that I don't like it - storing it in the file system is better, as I usually forget to backup foldercolors.oxc when I uninstall and reinstall Opus. I just can't work out why - with both the new options ticked - Opus stores the label in foldercolors.oxc and not in the file system as it should. Seems like a bug to me.
Labels can be stored in either place. The option just changes the default place that new labels are stored.
You can override the place where the label is stored by going extra arguments to the command that sets labels.
Existing labels are not affected when you change the default storage location.
But these aren't exiting labels, they are new labels. So, I highlight a folder, click the Properties button on the default Opus toolbar, select a label from there - and it's added to foldercolors.oxc, despite the two options being enabled (for one folder on the drive anyway, for another on the same drive it will be added to the file system). So, where is the Properties button on the toolbar meant to be storing the labels? At the moment, it seems to pick a storage system (file system vs foldercolors.oxc) at random.
There's a bug in the current beta where that may happen if you add the label using the Properties button while the Preferences dialog is also open. Maybe that's what you're seeing. We'll be fixing that. For now, don't set labels using the button while the Prefs dialog is open.
If you're setting labels on drives that aren't NTFS, or where the default to store labels using NTFS has been turned off, or where the command to store them overrides the default, then they'll also end up in foldercolors.oxc.
Nope, no preferences dialog open - something else must be going wrong. All my drives are NTFS - I have no other format. This is what I did.
- Found a folder that was highlighted green. Clicked it, went Properties-->Set Label-->Reset. Folder was reset to the normal colour.
- Totally exited from Opus (ie right click, Exit from the system tray icon), then re-opened it. Went into Preferences, and verified the folder had been removed from there (Labelled Files and Folders).
- Closed Preferences dialog, and totally exited from Opus (ie right click, Exit from the system tray icon), then re-opened it. Selected the folder, went Properties-->Set Label-->Green. Folder turned green.
- Totally exited from Opus (ie right click, Exit from the system tray icon), then re-opened it. Went into Preferences, and folder is once again listed in Labelled Files and Folders (and in foldercolors.oxc).
Again, this is on an NTFS drive. Very frustrating that it isn't working correctly.
However, if I then repeat that test with the folder immediately above that test folder in the folder tree (on the same drive, it is just the next folder above the test folder in the Opus folder tree), it adds it to the file system. There must be some folder names or folder paths that the label command gets tripped up on and bugs out.
Ok, finally worked the problem out. The problem is that Opus v10 set the folders to read-only when you added a label - and does not remove that read-only when you remove the label. Now with v11, when you go to set a label, it notices the read-only, and simply adds the label to foldercolors.oxc. If you go and reset the read-only label on all the folders that were marked with v10, then repeat the steps with v11, it will finally add them to the file system.
Well spotted, I hadn't thought of that. I'm not familiar with the labelling code but I've made a note to check if it's intentionally doing that for read-only folders, or if we could make it work with them by changing the attribute temporarily.
I don't think Opus 10 would have set the read-only flag on the folders when they had labels applied. Opus 10 did not touch files/folders at all to label them as it was just a configuration change. But using things like the Properties > Customize dialog to set custom icons for folders would have caused (and still will cause) them to be set read-only (because Explorer/Windows abuse the read-only attribute on folders to mean "see if anything has been customized", to avoid the expensive checks on folders which haven't been customized).
Hm, I don't recall having customised the icons for those folders - but I guess it's possible and that I've forgotten. Anyway, however read-only was applied to those folders, I have now reset all read-only attributes on those folders, and I then reset and re-applied the green folder label to them via the Properties button. Opus has now written the labels to the file system (so foldercolors.oxc is now empty), so it's all fine now.
Hello, I'm having this exact same problem! I have five stubborn folders that will just not stop appearing in Labelled Files and Folders - and also in the foldercolors.oxc file!
I thought it was just me seeing this and I thought I was going mad! I want the list and the foldercolors.oxc file to be completely empty.
I too have only the NTFS file system, and I would like all my labels to be stored in the object itself - unless I specifically set it in Preferences to be otherwise.
I have done exactly what Blueloo has done to the smallest detail - reset the Read-only attributes on the folders (even if you said that wasn't the cause), I've also restored all folder icons to defaults (even though I never actually customised any folders via Windows Properties) but I wanted to make sure that was ruled out before reporting here.
In the whole drive, with NTFS file system, where I can set a label to any other file or folders and they get added to the file system, 5 specific folders won't. Although they have the colored label I want, they also keep appearing in the list in Preferences and the .ocx file - without fail! No matter how many times I delete the labels, restart Dopu, set the labels again etc.
What else could be causing these folders to persist like this besides the 'read-only' and 'customize icon' problems you suggest? I really want to get to the bottom of this, as I really want to fully utilise the new label improvements you have added in Dopus 11.
What happens if you fully exit Opus (using File > Exit Directory Opus), then delete foldercolors.oxc, then re-start Opus?
I fully exited Dopus. I deleted the foldercolors.ocx, then restarted Dopus.
With the file gone and no files or folders listed in Preferences>Files and Folder Labels, I attach a label to one of the five troubled folders. I look in the Dopus ConfigFiles folder and the foldercolors.ocx file comes back, I open it in Notepad, the folder path appears!. When I delete it, the ocx is empty but when I label one of the folders again, the filesize changes so I don't even need to open the file to check its there.
All other folders in the drive that I labelled previously are okay (labelled pink) and they don't appear in the ocx file or in Preferences - just the 5 problem folders.
Its very odd, because even if I changed the folder's names (which I really didn't want to do as I have constructed a very strict naming system) it still happens. So it seems the labels are attaching themselves to the 'space' that the folder occupies, and not the folder itself. But if thats the case, then why couldn't I change that with these new improvements and override that?
The only way around this was to backup the said folders, shred the originals (not just mere delete), label the backed-up folders in their new location - and then restore them to the original drive! As it was only 5 folders bugging out, I resorted to this - I wouldn't have done that if there were more. So far, the labels stick and no folders list themselves in Preferences or the foldercolors.ocx file, which is good. I will keep an eye on these in case something changes. But I think this way has worked.
I'm guessing there was a file permissions difference on those folders.
This is an old problem that has since been solved (ages ago!) I'm so sorry I didn't reply earlier, I completely missed it shame on me