Set Description modifying my files

I'm using the "Set Description" function with descript.ion files but Directory Opus is adding EXIF tags to the file and I can't have that. Is there any way to prevent DOpus from modifying the file content?

I was expecting that the comment would be lodged only in the descript.ion file (or in an NTFS extension if chosen) as it was in older versions but I noticed that the size of the file was changing.

Descriptions will be written into files for formats (e.g. JPEG) that support it, and which Opus knows how to change. That's true whether you're using NTFS comments of descript.ion files.

It's only actively avoided for things like raw digital camera formats, since they're all undocumented and we don't feel it's safe to edit them.

So the answer to my question is no -- the mangling of the files cannot be prevented?

Modification and mangling are two different things. My understanding is that the files are not being corrupted, but correct me if I'm wrong as we'd want to fix that if they are.

There is no way to prevent setting a description on a JPG file from modifying the JPG file to write the description into it, other than possibly renaming the file to a different extension before setting the description. (I'm not sure how well renaming would work after the file was renamed back, especially if the EXIF data in it contained a different description, which would most likely be given priority and hide the one in the descript.ion file.)

Obviously the file isn't rendered useless, but it isn't the same and that doesn't work in a system that depends on file checksums (a common way of identifying duplicates in picture collections).

These irreversible changes to the behavior of Directory Opus are why I haven't upgraded in a long time. I can understand why editing extended properties is something that many wanted but I hope you can understand that it is something that negatively impacts the utility of DOpus as it can, to some extent, no longer be used as it once was (just to change the ADS or descript.ion contents).

I'd suggest more emphasis in the documentation on the fact that the file content will be changed. It may also help others to know exactly what file formats are subject to this modification.

As my post history shows I have struggled with this feature for years myself and stopped using any of the comments, ratings & description fields in DOpus altogether for the exact same reasons you mentioned. Changing files is the absolute no-go for me, too.

I started developing custom scripts to store data in ADS the way I want but that wouldn't be necessary if DOpus were always using exclusively ADS. On the other hand, I fully understand the reasons and the benefits of current behavior for non-power users. DOpus devs serve a broader user base than you or me but it breaks my workflow and quasi-OCD nonetheless. When I put a comment in multiple formats at once, DOpus saves some values in the files (and those in completely different standards like ID3, EXIF, and whatnot) and some in ADS. And depending on the format one of 2 fields, comments and description, conceals the other despite each having a different value and both columns show the same value. What DOpus does works mostly for most, but not for me.

I was thinking about requesting one or two features for quite some time so that we can exclusively use ADS, like enumerating existing streams and user-definable fields in a user-definable ADS name in metapane (inspired by MP3Tag's custom sidepanel-fields feature).

As an example of a less invasive approach, XNView allows you to choose, via checkbox, which of the "descriptions" it can handle are updated. It also allows you to, at the dialog level, have a different EXIF XPComment from that lodged in the descript.ion (more useful than echoing the same description in multiple mechanisms) or not change the existing EXIF data at all.

I see updating the file contents as an entirely separate act as compared to modifying the completely external APS or descript.ion file. All are eminently useful and making them independent would be even more useful but DOpus doesn't give me that option. Adding another checkbox or two to the dialog is the approach that XNView takes and it makes it much more clear what's at stake. I submit that operations that modify the file contents should be separate and apart from those that don't.

I hold up JD Design's Touchpro as an example of true flexibility when setting attributes. It allows you to pick (and remembers) which of the file timestamps you want to change (both internal and external) and it also allows you to pick one of several dates (including those from picture or document metadata) that you want to copy from. I use this utility extensively to cover a change made somewhere along the line where DOpus remembers the last set date rather than looking at the date on the first selected file as the Amiga version did. Touchpro also allows dates to be manipulated by an interval rather than a hard date which has been particularly useful for me when dealing with filesystems and archiving programs that don't handle Daylight Saving gracefully.

What DOpus is doing is akin to adding permanent ink and a needle to your temporary tattoo.