Closed Bug 663732 Opened 13 years ago Closed 13 years ago

Validator: Flag more types of common hidden files (thumbnail caches, directory settings, and auto-backups)

Categories

(addons.mozilla.org Graveyard :: Admin/Editor Tools, enhancement, P3)

enhancement

Tracking

(Not tracked)

RESOLVED FIXED
Q3 2011

People

(Reporter: kmag, Assigned: basta)

References

Details

(Whiteboard: [ReviewTeam])

User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:6.0a1) Gecko/20110513 Firefox/6.0a1
Build Identifier: 

Hidden files have to be one of the most common issues we see in add-on submissions, made more difficult by the fact that authors often think they've removed them when it turns out that they haven't. I'd like to see the following flagged by default:

• __MACOSX folders. These are a fairly major issue, since they're often comparable in size to the rest of the contents of the XPI.

• .DS_Store and Thumbs.db files

• Any dot-files, which would pick up the all too common Vim swap files.

• Files ending in ~, for backup files generated by many editors.

• *Possibly* *.bak, *.orig, *.rej for changes by patch(1) and the like.

It would also be nice if duplicate files were flagged, given the fairly common case of including both a JAR of chrome and the entire unJARed chrome tree.

Reproducible: Always
Dot-files and __MACOSX folders should already be flagged per bug 648416. Flagging more seems like a valid enhancement request, so confirming for that.

I once almost got burned by *.orig because my diff program created them as backups from a large merge and by default ignored them in its diffs. Caught them manually, though, a warning for this would be nice just in case. I'd also add *.old to the list as I use those all the time.

Thumbs.db are in every idiot's archive on the Internet, so yes please on that one.

The Windows counterpart to .DS_Store is desktop.ini, so I'd suggest adding that one to the list too. On Linux .directory files are already being caught by the dot-prefix file filter.

As to duplicates, that should probably be filed as a separate bug.
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Validator: Flag common hidden files → Validator: Flag more types of common hidden files (thumbnail caches, directory settings, and auto-backups)
Priority: -- → P3
Whiteboard: [required amo-editors]
Target Milestone: --- → Q3 2011
Ah, I didn't think to search closed bugs. It looks like my first test didn't zip the __MACOSX folder because it was empty. Dot-files are still ignored, though.
Depends on: 648416
Assignee: nobody → mbasta
Do we have a script/tool to remove these files during packaging/deployment? It can be imaginably frustrating for developers to keep removing OS-generated files (__MACOSX/thumbs.db) time and time again.

It might also be worth it to implement support in the repackager for removing those files automatically.
I'd be happy with that, but most developers expect the XPI they download to be the same one they uploaded, so I think it should be strictly opt-in.

As for a utility, I've heard mention of one, but I can't name it. It's generally better for developers to just use packaging scripts.
(In reply to comment #4)
> I'd be happy with that, but most developers expect the XPI they download to
> be the same one they uploaded, so I think it should be strictly opt-in.

The idea of auto-editing an uploaded addon has come up before and yes, I don't think anything should be touching uploads. There's always the risk of breaking something accidentally, I think it may break signed addons, and you might even get into complaints with regard to the addon's license. If there's a large amount of junk just have it be policy for the editor to reject and ask that it be fixed.

Now, putting some sort of detector/cleaner in some Addon SDK tool might be a good idea.
I think with regard to signing we should be fine, since individual files are signed rather than the whole XPI. Sub-JARs would present issues. On the other issues, I agree, but since we are going to have repackaging in the future in any case, I think it would be fine to have this as an opt-in feature.
Merged:

https://github.com/mozilla/amo-validator/commit/859e2837920fd4818ab83a8990c4847c337b9a9a
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Reclassifying editor bugs and changing to a new whiteboard flag. Spam, spam, spam, spam...
Whiteboard: [required amo-editors] → [ReviewTeam]
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.