tags:

views:

39

answers:

3

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"?

+2  A: 

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.

Michael
+1, but the asker did say s/he's worried about complexity overhead, not performance.
Rex M
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.
Michael
+5  A: 

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

Eric J.
+1 for teaching me something new!
John Rudy
I had no idea this even existed. This is most definitely the most attractive option. What are the gotcha's with this?
routeNpingme
@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
@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?
routeNpingme
Windows itself uses ADS extensively, see http://en.wikipedia.org/wiki/Fork_(filesystem) and scroll down to Microsoft.
Eric J.
@routeNpingme - I doubt it would cause issues with any PDF readers (as Eric stated, it's used by Explorer for caching all sorts of information). Some malware do try to disguise themselves in ADS, but I don't know of any AV that will flag this, and if so, it should be easy to configure them not to.
Michael
+1  A: 

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.

awhite