#87 Allow Negatives to Ignore Timestamp, File Size, etc.

open
nobody
UNIX (32)
5
2008-12-18
2008-12-18
Jeff Kelley
No

It would be useful to allow negatives to handle cases where only some of the file's data is useful. For instance, if the timestamp on /foo is unimportant, but the checksum and permissions are important, replacing the timestamp with a dash like this:

f ./foo 0644 0 80 - 143 Bdp3AU5vhGF5kiNgj/s691L4ES4=

would result in the timestamp not being checked.

Discussion

  • Andrew Mortensen

    This is a duplicate of 1819368, but the requester never responded to our questions.

     
  • Jeff Kelley

    Jeff Kelley - 2009-01-21

    I'll respond to the question here since that one appears to be closed. I think a command-line flag to ignore timestamps if the file's size and checksum match the known value would be acceptable. At the same time, I think allowing it to be specified on a per-file basis would be a better solution. For instance, if you have a program that needs to have the setguid flag set, you could do this:

    f ./foo 0644 0 - ...

    and have fsdiff not check the GID.

     
  • Steve Simmons

    Steve Simmons - 2010-04-05

    This idea recently resurfaced here as well. We've bumped into some issues where sloppy software allows a group to change in irrelevant manners, requiring radmind runs that do nothing but change the gid on a file permitted 700.

    There's definitely a small but real need to ignore some but not all metadata about a given file. We've bumped into cases where badly implemented utilities change the gid of a file to the last writer, as an example. So long as the file is permitted 700, then we don't care what the group is. 1819368 gives an example of this with dates.

    Consider also the case of the locate command. To use it, regular runs of 'updatedb' are required. This updates an index file 'locatedb' in a directory, usually '/var/locate'. The directory should not contain anything except that one file, but the file changes in size, date and checksum every night. A negative transcript on the directory causes it to ignore any extra files in that dir, which is not what you want. A negative transcript on the file causes it to be created if it doesn't exist - and that either breaks the locate command (empty file == bad) or makes you create and load a fake db, which then gives misleading results for locate. And while updatedb is running, there will be a 'locate.n' file in the directory. You want to allow such files if they exist, but not create them if they don't. The right way to do this is with a positive transcript that makes existence optional, but if it exists sets proper ownership and permissions while ignoring date and sum.

    As a matter of personal importance, ignoring non-existent files is lowest on my priority list. I can always make sure that updatedb is scheduled such that it's done by the time 'ra.sh trip' is started. Date and sum are very high on my list, group in the middle.

    In 1819368, wes suggested a command-line option to do this. It's not clear to me how one could do that with, say, 'ra.sh update' and not wind up getting *all* the dates ignored. Nor does it handle gids, etc.

     
  • Michael Graziano

    I have mixed feelings about "ignore group" (mostly I'm curious how we would specify it in the transcript - an X or * for gid?). I'm not opposed to it, but in my environment I consider UID/GID/Perms to be security-critical (even if their change is effectively a no-op). I want to know if they changed & forcibly reset them when I do a push.

    ---

    Specifically Re: locatedb and problems along that line, my solution here is a "defaults" transcript (a negative transcript where the files aren't zero-size) -- This lets me push out a mostly-correct locatedb, but doesn't stomp on the ones that get created by the updatedb job in cron.

    That solution isn't ideal (IIRC it resets the date), but I think the more generic "don't care about timestamps" patch to fsdiff solves that (though I'm biased in that I don't care about dates so much if my checksums match -- If you care about dates that's not a good solution).

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks