Using File Bit Flags for Other Purposes

Tag: windows Author: swleon Date: 2009-08-08

I'm conflicted on this one. Here's the situation -

I have a bunch of PDF files arriving in a folder from an external application (beyond my control) on a Windows 2003 server. These PDF files eventually get printed by my application by looking at the dates on the file (i.e. "print today's PDFs"), and then are generally held for a month or so before being deleted. They can be automatically printed, or manually printed by a user.

As a convenience to the user (data we don't act upon) I'd like to show which files have already been printed. This application has been fairly standalone and very simple, the way I like it.

Should I consider using file bits (i.e. Archive bit or something) to differentiate between files that have been printed and take the chance that a backup program could run, -or- increase the testing/maintenance overhead of the application by creating a data source for it (cross-reference table in XML) and introduce another "moving piece"?

Best Answer

You could consider keeping the information self-contained, without misusing flags, by using NTFS alternate data streams.


+1 for teaching me something new!
I had no idea this even existed. This is most definitely the most attractive option. What are the gotcha's with this?
@routeNpingme - There are two disadvantages I see. First, it ties you to NTFS. For some this is problematic, but if you are targeting windows it shouldn't be a problem. Second, some file copy utilities or backups do not support alternate streams, so you might lose the data if you depend on any such programs.
@Michael - good points. For me the NTFS dependency is OK, though from what I gather this is not widely used at all. In addition to your points, anybody know if this technique causes antivirus to look upon you suspiciously or cause undesired effects with existing PDF readers, etc?
Windows itself uses ADS extensively, see and scroll down to Microsoft.

Other Answer1

Using file bits for this is probably not the right approach - things like Archive are intended for use by system utilities that may change the bits beyond your control.

You should either keep a separate record of what's been printed (in a file or the registry), or perhaps move them into separate physical folders to differentiate them (while your application can just present a unified view of the two folders to the user.)

I wouldn't be worried about the perf overhead of keeping a separate record of this - it only has to be updated when users are printing, and printing will definitely be more expensive than updating a file.


+1, but the asker did say s/he's worried about complexity overhead, not performance.
Good point about overhead, I misread that. Still, the overhead of doing this upfront will be less than the overhead of figuring out why some documents are randomly switching between printed and not printed state.

Other Answer2

If it were me, I would not use file flags for something which they're not intended. Some other process could set the flags outside of your control and you wouldn't know what to do. Create a new moving piece that is explicit and easy for another developer to know what is going on.