On Wed, 20 Jun 2018 14:08:09 -0000, "Grunenberg, Renar" said: > There are after each test (change of the content) the file became every time > a new inode number. This behavior is the reason why the shadowfile think(or > the > policyengine) the old file is never existent
That's because as far as the system is concerned, this is a new file that happens to have the same name. > At SAS the data file will updated with a xx.data.new file and after the close > the xx.data.new will be renamed to the original name xx.data again. And the > miss interpretation of different inodes happen again. Note that all the interesting information about a file is contained in the inode (the size, the owner/group, the permissions, creation time, disk blocks allocated, and so on). The *name* of the file is pretty much the only thing about a file that isn't in the inode - and that's because it's not a unique value for the file (there can be more than one link to a file). The name(s) of the file are stored in the parent directory as inode/name pairs. So here's what happens. You have the original file xx.data. It has an inode number 9934 or whatever. In the parent directory, there's an entry "name xx.data -> inode 9934". SAS creates a new file xx.data.new with inode number 83425 or whatever. Different file - the creation time, blocks allocated on disk, etc are all different than the file described by inode 9934. The directory now has "name xx.data -> 9934" "name xx.data.new -> inode 83425". SAS then renames xx.data.new - and rename is defined as "change the name entry for this inode, removing any old mappings for the same name" . So... 0) 'rename xx.data.new xx.data'. 1) Find 'xx.data.new' in this directory. "xx.data.new -> 83425" . So we're working with that inode. 2) Check for occurrences of the new name. Aha. There's 'xxx.data -> 9934'. Remove it. (2a) This may or may not actually make the file go away, as there may be other links and/or open file references to it.) 3) The directory now only has '83425 xx.data.new -> 83425'. 4) We now change the name. The directory now has 'xx.data -> 83425'. And your backup program quite rightly concludes that this is a new file by a name that was previously used - because it *is* a new file. Created at a different time, different blocks on disk, and so on. The only time that writing a "new" file keeps the same inode number is if the program actually opens the old file for writing and overwrites the old contents. However, this isn't actually done by many programs (including vi and SAS, as you've noticed) because if writing out the file encounters an error, you now have lost the contents - the old version has been overwritten, and the new version isn't complete and correct. So many programs write to a truly new file and then rename, because if writing the new file fails, the old version is still available on disk....
pgpnFxJaMCJdh.pgp
Description: PGP signature
_______________________________________________ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
