Ignore .DS_Store files

[Rip and Tear]

.DS_Store files are hidden files used by macOS to store folder display information (Wikipedia). These files are created automatically by the Finder. These files can cause startup warnings in ZDoom.

Code: Select all

Invalid data encountered for texture :sprites/.ds_store

I am suggesting that these files be quietly ignored, rather than throwing a warning when the engine attempts to parse them.

[_mental_]

While I'm still thinking that it's responsibility of modders to remove all junk files from their creation, cleaning up those autogenerated files can be somewhat tricky.

This PR adds the requested feature. Windows thumbs.db files are ignored as well. I'm not 100% sure that we should handle those files though.

[Rachael]

In my opinion, adding special handling for these files just gives OS developers carte blanche to make a mess of user's folders the way they do, but we're not in a strong enough position to strong-arm any of them out of it.

Luckily, Microsoft somewhat abandoned that practice with Windows Vista, although Vista and later will still create a Thumbs.db on removable devices.

[Graf Zahl]

For Mac users this can be really painful, though because that system is rather merciless when it comes to creating these things. But I'm still not convinced that ignoring these is a good idea to mess around with resource archived, but when reading in a directory it may make sense to do so, because it is very hard not to get these things in.

[Rachael]

How about this, instead:

If GZDoom detects these blacklisted folders in a folder, it simply ignores them.

If it detects it in a .zip or .7z that it is loading, it will halt the load for 4 seconds with a big obvious orange message that says "Remove your .DS_Store/.git/Thumbs.db using your archive manager for this_archive.pk3!" and then proceed to ignore said file.

[Enjay]

While this is under discussion, does Windows still create desktop.ini files too, or have they gone?

[Rachael]

Yes, it does, but only if you customise the folder.

[fakemai]

How about this, instead:

If GZDoom detects these blacklisted folders in a folder, it simply ignores them.

If it detects it in a .zip or .7z that it is loading, it will halt the load for 4 seconds with a big obvious orange message that says "Remove your .DS_Store/.git/Thumbs.db using your archive manager for this_archive.pk3!" and then proceed to ignore said file.

Was about to go into angry mode since I actually do run some mods cloned from Git (if anything more mods need to use this sort of version control) but thankfully noticed the second sentence in time. Anyway the easiest would probably just to be ignoring unknown extensions and .hidden files if anything.

[_mental_]

it will halt the load for 4 seconds with a big obvious orange message that says "Remove your .DS_Store/.git/Thumbs.db using your archive manager for this_archive.pk3!" and then proceed to ignore said file.

Do we already have similar workflow for other warnings or errors? I'm not aware of it. If we don't have it indeed, what's the point of inventing such thing for this particular case? Is it so common to be handled exclusively?

the easiest would probably just to be ignoring unknown extensions

Certainly it's not the easiest and in fact this is wrong. zscript.exe and decorate.dll must and will be parsed accordingly because their lump/short names are ZSCRIPT and DECORATE. Same logic applies for many other special lumps.

and .hidden files if anything.

This is also questionable. I see no reason why arbitrary dotfile should be ignored. Are you 100% sure that no one uses them already?

[Rachael]

Do we already have similar workflow for other warnings or errors? I'm not aware of it. If we don't have it indeed, what's the point of inventing such thing for this particular case? Is it so common to be handled exclusively?

The reason why I thought of that was I was trying to guess why Graf thought it was a bad idea to completely ignore it when not for folders. In terms of mod development - such a warning would be handy before you "go gold" with your mod to alert you there's some stuff you need to trim out to not only save download/upload space but also to protect your own confidentiality in terms of workflow, in case of things like accidentally putting a private photo in the folder that you don't want others to have thumbnail access to.

[fakemai]

Do we already have similar workflow for other warnings or errors? I'm not aware of it. If we don't have it indeed, what's the point of inventing such thing for this particular case? Is it so common to be handled exclusively?

I definitely remember being bothered that the Git repo for Aetherius was tracking Thumbs.db files. Can't find any other examples of those in my mod collection though, surprisingly. EDIT: Correction, Project Brutality has one too at least for its Git repository. Can't speak for its normal version.

Certainly it's not the easiest and in fact this is wrong. zscript.exe and decorate.dll must and will be parsed accordingly because their lump/short names are ZSCRIPT and DECORATE. Same logic applies for many other special lumps.

Didn't know that about those two, but no on reconsideration you'd probably end up needing to make a list of valid extensions, which would be longer than a list of common problem filenames.

This is also questionable. I see no reason why arbitrary dotfile should be ignored. Are you 100% sure that no one uses them already?

Of the mods I have there was only a single one in Lithium and said file seems to be dummied out from actual use. I'm mostly just throwing the idea out there though if you want to consider making it stricter and it's possible to do without breaking anything. If necessary though filtering out .git and the like would be sensible.

[Gez]

I definitely remember being bothered that the Git repo for Aetherius was tracking Thumbs.db files.

Git can exclude certain files from being tracked, that's the purpose of the .gitignore list.

[Graf Zahl]

And yet, you encounter countless of repos that indiscriminately track internal compiler files and other sorts of garbage, making it a pain in the ass to work with those repos because switching back and forth is next to impossible. One of the projects I use at work had committed that sin many years ago. I immediately removed the garbage after starting work, but if I have to check out older revisions nothing works anymore due to these extraneous files a previous developer once added.

[fakemai]

Just checked and both Brutal Doom and Project Brutality have a Thumbs.db (MODELS/Decoration/Splash/Thumbs.db) though GZDoom doesn't seem to print any warning about it either like for .ds_store. In any case making such warnings annoying or fatal is a non-starter.

I definitely remember being bothered that the Git repo for Aetherius was tracking Thumbs.db files.

Git can exclude certain files from being tracked, that's the purpose of the .gitignore list.

Yeah, and there's a pretty helpful template for some of the common Windows ones here.

And yet, you encounter countless of repos that indiscriminately track internal compiler files and other sorts of garbage

Different VCS? Because you can outright purge files from the history with Git, and amusingly, there's an unofficial tool "BFG" to simplify the process.

[Graf Zahl]

Not if the remote is protected against retroactive tinkering. The main problem is that this will alter all commit hashes and render any local copy invalid. You cannot do that if several people have to work on it or if company policy is to disallow rewriting history.