Why jump from 1.0.9 to 1.1 for just a bug fix release? I originally planned to release this version as 1.0.10, but unfortunately some older code in my version-checking routines didn't consider two-digit revision numbers, so 1.1 it is. Also, it's likely that this will be the last 1.x version, as I'm now doing a complete rewrite which will be called "XRay II". Check here, or use the "Check for Updates..." feature for progress reports. Should you have suggestion for 2.0, don't hesitate to send them in!

Although I've made an intense effort to make XRay do exactly what it is supposed to do, and have killed all reported bugs, a few unimplemented features remain; some remaining problems, unfortunately, are the responsibility of other software, and I can't do anything about them. Make frequent backups, wear your spinach and eat your galoshes, yadda yadda yadda. See the "Known Problems and Limitations" section below for details, and please reread it before sending in a bug report. There is ABSOLUTELY NO WARRANTY for this software; RUN AT YOUR OWN RISK. Also see my complete disclaimer at the end of the general help document.

• When batch removing resource forks from the "Change Type and Creator for Enclosed..." dialog, XRay would, under certain circumstances, stop prematurely when one of the items already had an empty resource fork. This has been fixed.
  
• Cocoa applications with no NIB files were being incorrectly reported as Carbon applications.
  
• Dual-fork Mach-O files (yes, they exist!) were being incorrectly reported as Classic 68K applications.
  
• Xcode, Interface Builder and other Cocoa applications that depended upon a certain minimum JVM version were being incorrectly reported as Java applications.
  
• When running XRay as administrator, sometimes preference changes were being incorrectly saved to the "root" user's folder. This has been fixed.
  
• The eSellerate library has been updated to its latest version (3.5.6), making registration faster - at least until a new version comes out.
  
• Generic documents could be incorrectly reported as "Unix Executable File" if their executable permission was set. Actually, this seems to be a Panther bug; XRay now checks the file contents to see if the file is really executable object code, and reports it as such. (Some ".DS_Store" files seem especially susceptible to this.)
  
• Separate counts are now done for invisible files and folders, instead of conflating them into one count as previously.
  
• XRay now sends the user's Mac OS X version number back to my server when the online version checking facility is used, and the "Check for Updates..." window is opened automatically when you upgrade XRay. Please click on it whenever you upgrade XRay or your system, to give me statistics about which versions of Mac OS X are still being used; from what I see so far, 10.1.x is completely dead and 10.2.x (Jaguar) very nearly so.
  
• A crash when starting up XRay with some system configurations has been fixed.
  
• Some internal fixes and adjustments have been made.
  
• This documentation has been revised and updated. (Yes, this line will always appear here...)

• XRay may not work anymore with Mac OS X 10.1.5 and earlier releases; I no longer have a Macintosh with such a system installed; sorry about that.
  
• Programs using any contextual menu plugin may crash if there are two copies installed in different domains. This is a system limitation.
  
• XRay can't handle files whose full path exceeds the BSD limit of 1024 characters. The upcoming version 2.0 will hopefully be able to work around this restriction.
  
• XRay doesn't do complex processing for files on remote servers. In particular, only the local users and groups are available in the ownership popups for Jaguar, and all network users and groups are available for Panther. I'm still figuring out a better way to control this. Some attributes, such as the lock bit, may not be recognized on remote files, or remote clients may not handle them correctly if they're set on local files.
  
• Dragging an alias or symbolic link to the XRay icon, or XRaying it through the contextual menu, causes the alias or symbolic link to be resolved by the Finder before handing the item to XRay. There seems to be no way around this "feature". For the same reason, if you open a symbolic link, and later try to open it again from the "Open Recent" menu, the original is opened instead. Command-Shift-X doesn't resolve links, however.
  
• Opening a large number of items may be very slow. This is being investigated; in the meantime, try to avoid opening many items. XRay doesn't do batch operations.
  
• XRay depends on certain system tools to change permissions in some cases. XRay checks for the presence of these tools and won't run if they're missing. You should reinstall the BSD subsystem from your Mac OS X install CD if that happens.
  
• If you XRay a file which is in use by another application, you may get errors or strange side effects when saving changes. Don't do it.
  
• Changing attributes on non-HFS file systems may not always work as expected, depending on the way they emulate the specific attribute. Please e-mail me with details if you run into a specific case.
  
• Even with Administrator authorization, item names and some other attributes may not be editable if you don't have write permission to the item's enclosing folder. This may be fixed in a future version. Relaunching as Administrator will always allow editing.
  
• XRay uses the system file "/etc/magic" (on Jaguar) or "/usr/share/file/magic" (on Panther) to analyze file contents if other methods don't furnish a file type. If this file is is corrupted, XRay may hang or may give less detailed results. Notice that the magic results can't be used for application binding; although the Finder does a similar analysis, details are not available.
  
• Stacking windows uses the default (and not too-nice) Cocoa algorithm. This will be fixed in a future release.
  
• Certain files may contain invalid data, have invalid metadata or may cause exceptions to be raised in the Cocoa Framework, causing XRay to crash. Later versions will have better exception catching.
  
• Localization strings have not been properly implemented yet. They never may be...
  
• The subitems of the path "/dev" are not visible in the standard open panel. This seems to be a system limitation. Use the browser to view those subitems.
  
• Under certain rare circumstances, a field may be editable but saving the changes will not work. Check if you have write permission for the folder containing the item, or if that folder's "locked" flag or one of the "immutable" flags is set. In some cases, XRay may ask for a password only while saving. Relaunching as Administrator will usually allow any changes - root flags excepted!
  
• The Plugin API is not finished. It will be published with version 2.0, I swear. E-mail me if you want details.
  
• Selecting the "Open volumes as if they were folders" preference may cause a very long delay when opening a large drive. Notice that if you open your boot drive ("/") the calculated sizes will include all mounted drives, partitions and drive images!
  
• When opening a large batch of folders or other containers, content sizes and counts for some items may not be calculated. This is being investigated.
  
• The Finder does not notice certain changes to an item immediately, especially permission changes. This is being investigated.
  
• XRay may not unmount network volumes correctly; the "eject" button may be disabled or simply doesn't work. This is being investigated.