On Tue, Dec 04, 2012 at 12:10:32PM -0800, Darren Hart wrote: > > > >> [ ] Add meta-data mirroring > > > > Not sure what what you mean by meta-data mirroring? > > Sorry, just uid, gid, permissions... basically the inode. This could be > done by updating the script to use the sif command, but having a -i or > similar option to "write" (or maybe a new "copy" which did effectively > the same thing) by reading stat and copying the data across would be a > nice abstraction. Oh, I see, grabbing the permissions from what's actually in the source tree. You may want to talk to some of the people who will actually be using your script to see what they want. I could easily imagine some folks arguing that they don't want to use the mtimes from the source code tree, but instead they want to set them all to some standard set timestamp specified in some config file (in order to make the file system image be stable across checkouts). In addition, for setuid root programs, you won't be able to take the uid/gid and permissions from the inode anyway --- so I had been assuming that you would have some kind of control file, that would perhaps be in the top-level of your initial_ directory, that would list the default uid/gid/mod times to be used, and then exceptions on a per-file basis. (This was the control file where I was suggesting that you _not_ use XML for your encoding; if you want a flexible, but easy-to-use config file parser, I'll suggest you take a look at e2fsck/profile.c, which is used for parsing /etc/e2fsck.conf and /etc/mke2fs.conf.) > Agreed on the hard link. However, things like mknod and write from > debugfs seem like good candidates to be moved into libext2fs, then > other tools can make use of the code. For write from debugfs, you do realize we have lib/ext2fs/fileio.c, right? That's what debugfs uses already. Maybe it would make sense to add a ext2fs_create_file() function which takes a pathname, and it takes care of calling namei to get the target directory, and then allocating the file, etc., and then leave it to the calling application to fill in the inode structure with whatever is neecessary to create a new regular file, or a new block/character device, etc. So that one new function would would kill multiple stones at once; it would give you mknod, as well as refactoring most of what's in debugfs today for writing a file to a filesystem that isn't in lib/ext2fs/fileio.c. The one gotcha with creating these convenience functions is that it make may it much harder to properly report errors back to the user, since a fundamental rule for functions in libext2fs is that they should not use fprintf(stderr, ...) to report errors back to the user. That's the other reason why I tended not push too much complexity into libext2fs. (In general use of stdio in libext2fs is strongly discouraged, since that wouldn't be useful for an application written to uses gtk or even ncurses, such as that old EVMS front end program that some former colleagues of ours at IBM's LTC had written. :-) It's also problematic for the ppcboot folks, since they are trying to write a bootloader which would use libext2fs in a restricted environment that doesn't even have stdio available to programs; that was actually a problem for them caused by the recently merged mmp code, and I had to help them with that.) - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
