Thanks to everyone for their quick responses.
The original question:
>On a SPARCstation 5 running SunOS 4.1.4, the 'file' command, when reading a
>file, changes the 'atime' of the file. For some reason, when 'file'
>finishes reading the file, it reverts the 'atime' to what it was before the
>'file' command made the check. The undesirable side-effect of this is that
>the ctime (inode change time) is modified. This is a more serious change than
>the actual atime of the file.
>This has been changed in Solaris 2.3, where the 'file' command modifies the
>atime, and the ctime remains the same.
>Is there a patch/workaround to make the 'file' command under 4.1.4 work
>in the same way as the one under Solaris 2.3? Can the 'file' command from
>Solaris 2.3 be used under SunOS 4.1.4?
Response from Tom Orban (email@example.com):
> Yep, I reported that bug to sun, and they aren't going to fix it. (unless
> enough people complain possibly) No, you can't use a Solaris 2 binary on
> a Solaris 1 machine. My workaround is this:
> alias file 'su nobody -c "/bin/file \!*"'
> That way you don't have the perms to modify the file. Obviously, this only
> works for root.
Response from Nate Itkin (Nate-Itkin@ptdcs2.intel.com):
> I don't have a simple solution for you, but I can tell you that "file"
> under SunOS 4.1.3 works the same way and I don't really like it either.
> Well, if you're desperate enough I suppose you could do the following.
> I would set aside about 8 hours for this task if I were you.
> 1) Dissassemble "file" with adb
> 2) Find the trap instruction calling utimes(). This can be
> tricky with dynamically linked executables. Once you find
> it however, it's the only way to modify the atime/mtime of
> an inode so you're home free.
> 3) Replace the trap with a nop (0x01000000 in SPARC assembly)
Response from Steve Harris (firstname.lastname@example.org):
> Wow. Somebody should win the bonehead award.
> Same behavior under 4.1.3, and 4.1.1.
> Hope you find a solution. I would expect one could:
> get the bsd 4.4 source, fix the bug (if present), and rebuild it.
> maybe gnu has a version.
> adb the binary -- should be only a couple hours work for a good adb
> (or gdb, etc) jockey.
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:10:16 CDT