On 04/18/2013 12:28 AM, Daniel Kahn Gillmor wrote: > On 04/17/2013 06:25 PM, Daniel Kahn Gillmor wrote: >> On 04/17/2013 05:05 PM, Beith, Linda wrote: >>> Gpg: can't open 'rwu.dbdump_Nov2012.sql.gz.gpg' Gpg: >>> decrypt_message filed: file open error >> >> >> This message suggests that there is a problem in the filesystem, >> > > on further reflection, this might also indicate that the file does > not exist in the location (or with the name) that the operator is > indicating. > > For example: > > 0 dkg@alice:~$ gpg --decrypt does.not.exist.gpg gpg: can't open > `does.not.exist.gpg' gpg: decrypt_message failed: file open error 2 > dkg@alice:~$
I think this is no longer a decryption issue. If all you want is something about encryption, TAP DELETE NOW! Encryption is not even discussed here! In that case, either sha1sum or file (why not do two things at once?) gives a more meaningful message: $ sha1sum nonexistentfile sha1sum: nonexistentfile: No such file or directory $ sha1sum foo sha1sum: foo: Permission denied $ ls -l foo -rw-r----- 1 root root 32 2013-04-18 00:08 foo I just wrote Linda privately since it was no longer an encryption issue IMO. I hope the leading "rwu." does not mean they are storing everything in one folder. No IBM main-frame person would do that and IBM main-frames have ISAM (Indexed Sequential Access Method). Almost a million files in one folder (yes I have saw it stupidly done not once but twice) is not a pretty sight, and if you have ext4, something like Reiser isn't going to save you. You still have O(N/2) on average to do anything with files in that folder (the dir file, not the inodes the various dir entries point to). I would give each client their own folder at minimum and maybe sub-folders. Things run much quicker that way all the way around. What was the clue that they are using a one folder method? They are removing the older files. it could be they are running out of storage space but we have terrabyte disks now so it is more likely they are having a one folder for all slow down. Disks are cheap. Make /client an NFS mount and squirrel away the old drives into storage to be replaced by new disks on the NFS mount. You could recycle the old disks after a while. Make the backups resilient to wait for 30 minutes on fail before trying again while the old disk is umounted and replaced with the new disk. And I would much rather have the mount device be a hard /dev/sd# rather than all the other id stuff too. Have client folder pre-made and ready to go before the new disk is mounted. I have done some of this stuff in my sleep - literally! A kot of DB people do it too. As I read it, they are somehow able to cd into the folder - perm 711 / 751, (please not 755!), but once they get there the file has the proper permissions (640) and is hopefully owned by owner rwu and is in group rwu. I would set each user like rwu with a umask 027 in their shell start up and then assuming files were stored in something like (it works for me but maybe not for SQL DBs): /client/RogerWilliamsUniversity/ - alternatively /client/rwu/ me$ su -l rwu rwu$ cd /client/RogerWilliamsUniversity/${RESTOFPATH} rwu$ sha1sum -b rwu.dbdump_Nov2012.sql.gz.gpg rwu$ ls -l rwu.dbdump_Nov2012.sql.gz.gpg # if succes with sha1sum and ls: rwu$ gpg -d < rwu.dbdump_Nov2012.sql.gz.gpg | tar -xvf - rwu$ file rwu.dbdump_Nov2012.sql rwu$ ls -l rwu.dbdump_Nov2012.sql Use of the "v" in tar optional. File not there? rwu$ find /client/RogerWilliamsUniversity -type f -name \ rwu.dbdump_Nov2012.sql.gz.gpg -print There again by having their own folder I reduce the work find has to do by several orders of magnitude. I also reduce the work load in normal operations. I would prefer 2012_11 which means you could have YYYY folders and if necessary inside the year folder a MM folder (month in numerics). That is just one method to reduce the directory overloaded with too many files. But all of the methods have the trait of using subfolders (as many directories as necessary) according to something that is naturally there in the data / file names. Like I said, use /client/rwu/ if that makes more sense and make the real world name (GECOS field) for user rwu to be Roger Williams University. I did ask her to respond on the solution. It may still be an encryption issue but I doubt it Oops, I said something about encryption. Excusez mow. HHH
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users