"copyattr -d -r" results in attempts to write to read-only source partition.

[bga]

I did a clean Haiku install in one partition and started moving the data from the old partition to the new one. For this, I mounted the old partition read-only and used copyattr -d -r to copy specific directories. From time to time, I would get messaged like the following in my syslog:

2009-05-05 19:38:59 KERN: bfs: bfs_open:1183: Read-only file system
2009-05-05 19:39:01 KERN: Last message repeated 729 times.

Looking at BFS's kernel_interface.cpp file, I see this:

	// opening a directory read-only is allowed, although you can't read
	// any data from it.
	if (inode->IsDirectory() && (openMode & O_RWMASK) != 0) {
		openMode = openMode & ~O_RWMASK;
		// TODO: for compatibility reasons, we don't return an error here...
		// e.g. "copyattr" tries to do that
		//return B_IS_A_DIRECTORY;
	}

	status_t status = inode->CheckPermissions(open_mode_to_access(openMode)
		| (openMode & O_TRUNC ? W_OK : 0));
	if (status < B_OK)
		RETURN_ERROR(status);

Some questions about this:

1 - Why does copyattr need that? Can't we simply fix it? 2 - Although if the volume is read/write this will allow copyattr to do whatever it does, when it is read-only it will bail out on the following error (which results in the messages I mentioned in the syslog). Does this mean that the copy operation does not really work when the source is a read-only volume? 4 - If it does work even with the error being returned, why is it a problem to return the error in the pointed commented out above?

[axeld]

I would think these are two separate issues. The BeOS copyattr needed this, so we might want to revert that change - however, I am not sure if we currently require a writable file handle in case one wants to change the attributes of a file; that might also be the source of that problem, btw.

If you find the time, you could do an "strace copyattr ..." to see where the failure actually happens.

[axeld]

Whatever the problem was, it doesn't seem to happen anymore.