Quoting Bruce Ferrell ([email protected]): > Sorry Rick... I missed that.
No worries (as our Australian friends say). > I am absolutely astounded by the number of time I've seen *IX > "admins" at fortune X companies copy a tree to a windows share and > wonder why it's broken when they try to restore from it. NFS, if not > done correctly, can do that same thing too. So... Reminds me of something I forgot to mention earlier. Most Linux folks have heard of the stat(2) system call, but did you know there's also an informative stat(1) system _utility_? Play with it on diverse sorts of file/directory targets, and see how informative it is. It shows in human-readable form _all_ metadata available about any filesystem object. Around 2001 when I was writing an article for _Linux Journal_ about then-new USB flash drives called 'Floppies for the New Millennium', it belatedly occurred to me to wonder how the vfat filesystem (typically used on flash drives) dealt with storage of native *ix's three time stamps (ctime, mtime, atime) on a filesystem (vfat) incapable of storing more than a single time stamp. The answer is logical: All three get instantiated by overloading the single DOS time stamp, which thus gets rewritten every time any of them must be updated. And, point is, one can observe this kludge at work using /usr/bin/stat. Anyway, to second what you said: Any storage target that's not Linux-native, and NTFS is case in point, is going to unavoidably introduce some degree of silent metadata loss (absent encapsulation, such as in a tarball), so beware. _______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
