Re: [Bug-tar] Bug? Where? Why? Why so many files changing as we read them?
Paul Eggert wrote: One possibility is that the file system is buggy, and that reading a file (and therefore modifying st_atime) also modifies st_ctime as a side effect. Often this sort of thing is delayed, that is, you read a file and its st_atime is updated immediately, but its st_ctime is updated after a delay of a few seconds. This would explain the observed behavior. AFAIK (but with MS, who really knows anything?), MS adopted a similar system to the linux kernel in regards to updating last-access times when atime updating is turned off. I.e. I thought that the kernel opportunistically updates last-access if something else changes in the inode to be no earlier than the ctime or modtime fields. I just read last week in looking at MS notes on NTFS implementation, that it does something similar when don't have last-access turned off -- but it may hold off on the writing out of the last access time for up to an hour -- trying to wait for a time when one of the other times is updated. But that said -- I don't get the same messages when I run tar on the client-MS machine. Instead I get failures to read ACL's and ext-attrs... which is maybe worse. But it's only when I use the linux CIFS to access the remote NTFS that tar gets upset. So I don't think it is the source FS. See, for example: https://bugzilla.redhat.com/show_bug.cgi?id=1058526 which does indeed illustrate remote file-system bugs that can cause the behavior in question. (Mark O'Keefe's proposed change to tar isn't right; there are security reasons to worry about ctime as opposed to mtime). Well -- I have yet to try to use stat on all the files b4 and aftr ... keep getting sidetracked.
Re: [Bug-tar] adding ACLs when there are none
Pavel Raiskup wrote: These are IMO candidates for omitting --acls option, no? Or could you give an example? What *exactly* do you expect the --acls should behave by default? Combine existing acls in parent directory (default acls) with the stored in archive? Leaving default acls in the dir -- case in in point... If the SetGid bit is set on a directory on linux, it is usually propagated to lower lower level dirs to permit a particular type of access to be propagated to lower level files and dirs. If a default acl is set on a dir I see it used in the same way.
Re: [Bug-tar] GNU tar generates malformed Pax attributes
Joerg Schilling wrote: This is a star version that is 6 years old, so nobody currently cares about it anymore and the fact that you did never send any information that would allow to debug a potential reason makes it obvious that you do not have a problem, but rather like to grump without reason. The author of star was told about this over 6 months ago. No newer version of star was submitted to the SuSE repo -- they released the latest version that the author had released. If you had a newer version of it, you could have submitted it. I certainly never saw anything submitted from you despite you being on their factory mailing list and being aware of the problem. If you don't care to submit an update, SUSE will continue to distribute the version I used as the latest version. Note -- I'm just a user -- but if I had a version that worked, I certainly would have submitted it. I gave you a bug report and you asked me for a trace from your own tools -- that are not included on suse. You ignored the bug report, just like you ignore this one. It has a stack trace and the versions of the libraries used. You are the program author. If you are not capable of debugging it, don't claim it has no bugs just because you neither release new source. You said to search on the net -- I couldn't find anything newer. Even if I did, I'm not SuSE and wouldn't be able to submit it for you.. If you however are able to repeat a problem using a recent star version (1.5.3a01 or later) _and_ you send a stacktrace that includes the fault address and opcode, so debugging could be done, you are of course welcome. Like I said -- this is the latest version you've provided to suse despite having previous knowledge of this bug and knowledge that they had no newer version. If the problem you are talking about did ever exist it has been fixed long ago. - This shows how screwed up you are. if the problem ever did exist?? What, you think people just type up stack back traces to harass you? Um... get a clue.
