Joerg Schilling wrote: > "Garrett D'Amore" <gdamore at sun.com> wrote: > > >>> Archivers that slurp and spit the symlink contents will work >>> without mods as long as they get all of the bytes, but would >>> need more extensive modifications if our storage was in a >>> system attribute. Also, we can get the single bit we need >>> in ZFS now, and a 16K sysattr will not be supportable for a >>> few more months. >>> >> I'm confused. Brian says that archivers Just Work with the current >> form, because the attributes are retained. Yet, you're saying that the >> attributes are not necessarily retained. Which is it? Right now, >> either way, you have an attribute... which I *think* means that the you >> need support (which may or may not be present) in the archivers. >> > > If these objects will be seen as symlink file type and in case they cannot > be copied using symlink(), I expect problems. >
You're trying to draw a distinction between this proposal and current symlink behavior but there is no distinction. To existing applications, these will appear like symlinks that don't resolve to an existing target. Alan > I beleve we need to get more information in order to be able to check whether > the case makes a POSIX compliant proposal. > > And BTW, I like to remind people to the "well planned" Linux implementation > for > "file flags" that forces archivesrs like star to open() _all_ files in search > for file flags. If I am going to backup /dev/, I am forced to open e.g. the > "rewind" type of a tape drive entry and thus forcing the tape to rewind just > for > checking for fflags. > > So please give more information on how to distinguish these objects from > vanilla symlinks. > > J?rg > >
