-
-
Notifications
You must be signed in to change notification settings - Fork 153
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
option to choose tomb filesystem #45
Comments
if we make it configurable, what's the best way to check which filesystem the tomb is formatted? |
On 17/01/2012 18:09, Jaromil wrote:
This will go togheter to #45 that I If we choose one of these approaches, I can code this into #45 and then Anathema +--------------------------------------------------------------------+ |
Bumping this issue since I want to use ZFS now on some tombs. It features history and compression. So I'll take it from here and hack something together soon. I think of a -t option (like with mount) on lock() Tomb also needs to save information on how it was formatted, or even better detect (with sfdisk?) Will try ASAP. So far I can see useful options for EXT2/3/4 and ZFS, not sure what else. |
I find I think FAT is great for most tombs, but that's another story :) |
ZFS works in a very different way than other Linux filesystems, it needs to have ad-hoc code for its usage. Why do you think FAT is great? can you sketch a situation where it would be useful? |
On a computer, my UID is 1001. On another one, my UID is 1002. |
Don't use FAT to solve such a problem. FAT will never make it in Tomb for such a reason, it is a complex way to solve a simple problem and implies huge drawbacks. Besides, look at line 1511: chown ${_uid}:${_gid} ${tombmount}
chmod 0750 ${tombmount} why that is not working for you? any other reason you like to put forward to advocate use of FAT? |
|
Probably because it does not change the ownership of the files inside the Tomb. Indeed, that's an interesting issue. I have it also. We could take advantage of the hooks to If the user gets to the point she needs to own the files, we can safely assume she is the right owner of the Tomb, so we could simply add |
ACK, true there is no -R in that chown I've pointed. Hellekin analysis here is fairly complete. so the suggested solution of a chown -R of the ${_uid} alone is fine for me, but it should be specified in the documentation and bypassed by the -n option, together with the hooks. |
I agree that the cases for multiple owner are not much; I can not say the same thing for the mode; therefore, I propose chown -R ${_uid}:${_gid} ${tombmount}
chmod 0750 ${tombmount} So that the chmod is not recursive |
Hmmm no. The GID is often more significant than the uid, especially for giving read-only access to some applications, or other users. Please do not touch the GID :) |
I just want to toss one more fs onto the list. XFS if possible. Thanks for taking it into consideration. |
Sometimes fat32 can be better than ext3 (especially for moving the tomb on another computer). Sometimes it's the opposite (fat32 has a lot of limitations).
We should add an option
--filesystem=FSNAME
to the create subcommand, to let the user choose it.EDIT: still requested XFS and FAT32
The text was updated successfully, but these errors were encountered: