loc-xferutils-mail Mailing List for Library of Congress - Transfer Tools
Status: Beta
Brought to you by:
l0c
You can subscribe to this list here.
2011 |
Jan
|
Feb
|
Mar
(1) |
Apr
(1) |
May
(2) |
Jun
|
Jul
|
Aug
(5) |
Sep
(1) |
Oct
|
Nov
(1) |
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2012 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2013 |
Jan
|
Feb
|
Mar
(1) |
Apr
(4) |
May
|
Jun
(2) |
Jul
(1) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2014 |
Jan
(7) |
Feb
(3) |
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Littman, J. <jl...@lo...> - 2014-05-27 16:59:24
|
There is an option (keepemptydirs) for baginplace, but not create. Best. --Justin ________________________________________ From: Layale Bassil [lb...@au...] Sent: Tuesday, May 27, 2014 3:41 AM To: loc...@li... Subject: [Loc-xferutils-mail] bagit-4.9.0 Hello, I am using the latest version of the bagit tool to create bags for transfer and preservation. I would like to know if there is any parameter that can be sent to the “create” command in order to include empty folders inside the bag. I have folders that are sometimes empty but I need to preserve to conserve the full structure of the bag but they are not being included I the bag when they are empty. Please advise, Help is very much appreciate. Regards. Layale Bassil Software Engineer – Business Analyst IT Solutions Delivery Department [cid:image001.gif@01CF7998.35051870] American University of Beirut Office of Information Technology P.O.Box 11-0236 Riad El-Solh, Beirut 1107 2020, Lebanon T: +961 (1) 350000 x 3649 | M: +961 (03) 929876 E: lb...@au...<mailto:lb...@au...> W<http://www.aub.edu.lb/> . Fb<http://www.facebook.com/aub.edu.lb> . Fl<http://www.flickr.com/groups/aub> . T<http://twitter.com/AUB_Lebanon> . Y<http://www.youtube.com/AUBatLebanon> . L<http://www.linkedin.com/company/american-university-of-beirut> . IT<http://www.aub.edu.lb/it/> Think Green... Keep it on the Screen… Save a Tree... |
From: Mark A. M. <ma...@ma...> - 2014-05-27 14:41:46
|
Hi Layale, On May 27, 2014, at 3:41 AM, Layale Bassil <lb...@au...> wrote: > I have folders that are sometimes empty but I need to preserve to conserve the full structure of the bag but they are not being included I the bag when they are empty. Per the most recent BagIt specification [0]: > Payload manifests only include the pathnames of files. Because of > this, a payload manifest cannot reference empty directories. To > account for an empty directory, a bag creator may wish to include at > least one file in that directory; it suffices, for example, to > include a zero-length file named ".keep”. [0] http://tools.ietf.org/html/draft-kunze-bagit-10 Best, Mark A. Matienzo, Director of Technology Digital Public Library of America | http://dp.la ma...@dp... |
From: Calvin W. <cal...@ha...> - 2014-02-20 21:48:39
|
Hi, Is there Java documentation hosted anywhere or will I have to generate it from the source? Calvin |
From: Littman, J. <jl...@lo...> - 2014-02-18 11:53:43
|
Christie- The code is available from Github, but all of the releases are still at SourceForge. We're not activitely developing Bagger -- basically, we've come to the conclusion that it needs a rewrite, but don't currently have the resources. The version of BIL has not been updated, but if someone has a reason to need the more recent version we could do an update. Best. --Justin ________________________________________ From: Christie Peterson [cpe...@jh...] Sent: Monday, February 17, 2014 4:30 PM To: loc...@li... Subject: [Loc-xferutils-mail] Current version of Bagger? Hello, I have a need to use Bagger for a quick field acquisition, and I’m wondering if Bagger 2.1.3 found on SourceForge at http://sourceforge.net/projects/loc-xferutils/files/loc-bagger/2.1.3/ is the latest release. Is anyone planning an update to a more recent BagIt library (Bagger 2.1.3 supports BagIt 4.4) or is it no longer being developed? I know LOC moved its tools to GitHub last year, but I don't see an actual release of Bagger there. Thanks, Christie ------------------------------------------- Christie S. Peterson Records Management Archivist Johns Hopkins University The Sheridan Libraries 3400 N. Charles Street Baltimore, MD 21218 410.516.5898 Fax 410.516.7202 cpe...@jh...<mailto:cpe...@jh...> |
From: Christie P. <cpe...@jh...> - 2014-02-17 22:30:25
|
Hello, I have a need to use Bagger for a quick field acquisition, and I'm wondering if Bagger 2.1.3 found on SourceForge at http://sourceforge.net/projects/loc-xferutils/files/loc-bagger/2.1.3/ is the latest release. Is anyone planning an update to a more recent BagIt library (Bagger 2.1.3 supports BagIt 4.4) or is it no longer being developed? I know LOC moved its tools to GitHub last year, but I don't see an actual release of Bagger there. Thanks, Christie ------------------------------------------- Christie S. Peterson Records Management Archivist Johns Hopkins University The Sheridan Libraries 3400 N. Charles Street Baltimore, MD 21218 410.516.5898 Fax 410.516.7202 cpe...@jh...<mailto:cpe...@jh...> |
From: Nicolas F. <Nicolas.Franck@UGent.be> - 2014-01-15 07:52:34
|
you're right. Had forgotten about that;-) But bagging is al about "transfer" of data from one computer to the other, not about restoring of data to the same locations they were before (for that is the reason their paths preserved in a zip). Bagit is basically just a directory structure. ZIP is only used as a way of transferring this bag. See "serialization" of bags: http://www.digitalpreservation.gov/documents/bagitspec.pdf ________________________________________ From: Eisenhauer, Stephen [Ste...@un...] Sent: Wednesday, January 15, 2014 12:24 AM To: Nicolas Franck; Calvin Wong; loc...@li... Subject: RE: [Loc-xferutils-mail] Preserving directory structure > Even a zip does not preserve the full path of the source files, > because unzipping a file like "C\users\calvin\documents\stuff" > would write the file to "C:\users\calvin\documents\stuff" instead > of to the same directory of the zip file. Actually, preserving the paths that way is generally an option in many compression tools. Some people intend for an archive to be expanded at the root of a filesystem, or otherwise just want the archive to reflect the entire hierarchy for whatever reason. I wouldn't say it's "not possible", but I don't think it's provided by default in any official BagIt utilities or libraries. You'll just need to implement that logic yourself somehow. Stephen Eisenhauer Programmer for Strategic Projects Libraries, University of North Texas ________________________________________ From: Nicolas Franck [Nicolas.Franck@UGent.be] Sent: Tuesday, January 14, 2014 3:49 PM To: Calvin Wong; loc...@li... Subject: Re: [Loc-xferutils-mail] Preserving directory structure Hi, 1. regarding your first question: I suppose you want something like this...: bag/ manifest-md5.txt data/ C\users\calvin\documents\stuff ...in order to preserve some sort of "history" (where was it originally stored?) of the filename/directory. No, this is not possible: a bag is simply a directory, to be dragged from source to destination, like any other directory. That destination can be another computer, but also another directory on the same filesystem. Even a zip does not preserve the full path of the source files, because unzipping a file like "C\users\calvin\documents\stuff" would write the file to "C:\users\calvin\documents\stuff" instead of to the same directory of the zip file. I would recommend describing this kind of information in a mets.xml: http://www.loc.gov/standards/mets/ It's an international metadata standard for describing files and their corresponding metadata (and so also their history). I'm not sure if I understood your first question correctly ;-) 2. and your second question: "Is there also a way to keep duplicate folders with the same name that are in different paths separate?" Mm, I suspect you tried to add source directories with the same name (but in different parent directories) to the bag? That will not work. For they are added to the "root" of the bag. It's like copying those directories to the same destination directory (they would overwrite each other). Simply prepare the directory structure the way you want it to look in the bag, and then add this new directory to the bag. ________________________________________ From: Calvin Wong [cal...@ha...] Sent: Tuesday, January 14, 2014 7:49 PM To: loc...@li... Subject: [Loc-xferutils-mail] Preserving directory structure Hello, Is there a way to preserve the path structure up to the folder to be bagged? Such as if I had an input path like "C:\users\calvin\documents\stuff," I want the folders inside the bag to also be something like "C\users\calvin\documents\stuff." Is there also a way to keep duplicate folders with the same name that are in different paths separate? Thanks ------------------------------------------------------------------------------ CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk _______________________________________________ Loc-xferutils-mail mailing list Loc...@li... https://lists.sourceforge.net/lists/listinfo/loc-xferutils-mail |
From: Eisenhauer, S. <Ste...@un...> - 2014-01-14 23:25:05
|
> Even a zip does not preserve the full path of the source files, > because unzipping a file like "C\users\calvin\documents\stuff" > would write the file to "C:\users\calvin\documents\stuff" instead > of to the same directory of the zip file. Actually, preserving the paths that way is generally an option in many compression tools. Some people intend for an archive to be expanded at the root of a filesystem, or otherwise just want the archive to reflect the entire hierarchy for whatever reason. I wouldn't say it's "not possible", but I don't think it's provided by default in any official BagIt utilities or libraries. You'll just need to implement that logic yourself somehow. Stephen Eisenhauer Programmer for Strategic Projects Libraries, University of North Texas ________________________________________ From: Nicolas Franck [Nicolas.Franck@UGent.be] Sent: Tuesday, January 14, 2014 3:49 PM To: Calvin Wong; loc...@li... Subject: Re: [Loc-xferutils-mail] Preserving directory structure Hi, 1. regarding your first question: I suppose you want something like this...: bag/ manifest-md5.txt data/ C\users\calvin\documents\stuff ...in order to preserve some sort of "history" (where was it originally stored?) of the filename/directory. No, this is not possible: a bag is simply a directory, to be dragged from source to destination, like any other directory. That destination can be another computer, but also another directory on the same filesystem. Even a zip does not preserve the full path of the source files, because unzipping a file like "C\users\calvin\documents\stuff" would write the file to "C:\users\calvin\documents\stuff" instead of to the same directory of the zip file. I would recommend describing this kind of information in a mets.xml: http://www.loc.gov/standards/mets/ It's an international metadata standard for describing files and their corresponding metadata (and so also their history). I'm not sure if I understood your first question correctly ;-) 2. and your second question: "Is there also a way to keep duplicate folders with the same name that are in different paths separate?" Mm, I suspect you tried to add source directories with the same name (but in different parent directories) to the bag? That will not work. For they are added to the "root" of the bag. It's like copying those directories to the same destination directory (they would overwrite each other). Simply prepare the directory structure the way you want it to look in the bag, and then add this new directory to the bag. ________________________________________ From: Calvin Wong [cal...@ha...] Sent: Tuesday, January 14, 2014 7:49 PM To: loc...@li... Subject: [Loc-xferutils-mail] Preserving directory structure Hello, Is there a way to preserve the path structure up to the folder to be bagged? Such as if I had an input path like "C:\users\calvin\documents\stuff," I want the folders inside the bag to also be something like "C\users\calvin\documents\stuff." Is there also a way to keep duplicate folders with the same name that are in different paths separate? Thanks ------------------------------------------------------------------------------ CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk _______________________________________________ Loc-xferutils-mail mailing list Loc...@li... https://lists.sourceforge.net/lists/listinfo/loc-xferutils-mail |
From: Nicolas F. <Nicolas.Franck@UGent.be> - 2014-01-14 21:49:42
|
Hi, 1. regarding your first question: I suppose you want something like this...: bag/ manifest-md5.txt data/ C\users\calvin\documents\stuff ...in order to preserve some sort of "history" (where was it originally stored?) of the filename/directory. No, this is not possible: a bag is simply a directory, to be dragged from source to destination, like any other directory. That destination can be another computer, but also another directory on the same filesystem. Even a zip does not preserve the full path of the source files, because unzipping a file like "C\users\calvin\documents\stuff" would write the file to "C:\users\calvin\documents\stuff" instead of to the same directory of the zip file. I would recommend describing this kind of information in a mets.xml: http://www.loc.gov/standards/mets/ It's an international metadata standard for describing files and their corresponding metadata (and so also their history). I'm not sure if I understood your first question correctly ;-) 2. and your second question: "Is there also a way to keep duplicate folders with the same name that are in different paths separate?" Mm, I suspect you tried to add source directories with the same name (but in different parent directories) to the bag? That will not work. For they are added to the "root" of the bag. It's like copying those directories to the same destination directory (they would overwrite each other). Simply prepare the directory structure the way you want it to look in the bag, and then add this new directory to the bag. ________________________________________ From: Calvin Wong [cal...@ha...] Sent: Tuesday, January 14, 2014 7:49 PM To: loc...@li... Subject: [Loc-xferutils-mail] Preserving directory structure Hello, Is there a way to preserve the path structure up to the folder to be bagged? Such as if I had an input path like "C:\users\calvin\documents\stuff," I want the folders inside the bag to also be something like "C\users\calvin\documents\stuff." Is there also a way to keep duplicate folders with the same name that are in different paths separate? Thanks |
From: Calvin W. <cal...@ha...> - 2014-01-14 18:56:46
|
Hello, Is there a way to preserve the path structure up to the folder to be bagged? Such as if I had an input path like "C:\users\calvin\documents\stuff," I want the folders inside the bag to also be something like "C\users\calvin\documents\stuff." Is there also a way to keep duplicate folders with the same name that are in different paths separate? Thanks |
From: Littman, J. <jl...@lo...> - 2014-01-08 12:41:25
|
Hello Kari- I'm afraid we don't have anyone at LC familiar enough with the existing Bagger code to answer your question. Sorry about that. --Justin From: Kari R Smith [mailto:smithkr@MIT.EDU] Sent: Tuesday, January 07, 2014 11:28 AM To: loc...@li... Subject: [Loc-xferutils-mail] Bagger profile display - question Hello, I have created two custom profiles for Bagger. The metadata fields are not displaying in the Bagger BagInfo window in the same order as I have in the json profile file. Any thoughts on how to force the ordering of the metadata fields in the BagInfo window? Thank you, Kari R. Smith, Digital Archivist MIT Libraries, Institute Archives and Special Collections 617-258-5568 | smithkr (at) mit.edu http://libraries.mit.edu/archives/ |
From: Kari R S. <smithkr@MIT.EDU> - 2014-01-07 16:28:03
|
Hello, I have created two custom profiles for Bagger. The metadata fields are not displaying in the Bagger BagInfo window in the same order as I have in the json profile file. Any thoughts on how to force the ordering of the metadata fields in the BagInfo window? Thank you, Kari R. Smith, Digital Archivist MIT Libraries, Institute Archives and Special Collections 617-258-5568 | smithkr (at) mit.edu http://libraries.mit.edu/archives/ |
From: Littman, J. <jl...@lo...> - 2013-10-17 15:27:22
|
Hey Mark- It's going to be a while before someone at LC can take a look at this. We're a bit backed up, but will add to the list. Best. --Justin From: dig...@go... [mailto:dig...@go...] On Behalf Of Mark A. Matienzo Sent: Thursday, October 17, 2013 10:54 AM To: dig...@go...; loc...@li... Subject: [digital-curation] Bagger 2.1.3 fails to start on Windows 7 Hi all, I'm trying to get Bagger 2.1.3 running on a new Windows 7 system, and when it starts up for the first time, it seems to fail at the step where it's trying to copy the default profiles to my user directory. Here's a portion of the start up logs that demonstrate the problem: https://gist.github.com/anarchivist/7026354 - note that I don't have a user named "asdf" on this machine. Thanks, Mark -- Mark A. Matienzo <ma...@ma...<mailto:ma...@ma...>> Digital Archivist, Manuscripts and Archives, Yale University Library Technical Architect, ArchivesSpace -- You received this message because you are subscribed to the Google Groups "Digital Curation" group. To unsubscribe from this group and stop receiving emails from it, send an email to dig...@go...<mailto:dig...@go...>. To post to this group, send email to dig...@go...<mailto:dig...@go...>. Visit this group at http://groups.google.com/group/digital-curation. For more options, visit https://groups.google.com/groups/opt_out. |
From: Littman, J. <jl...@lo...> - 2013-07-12 11:25:39
|
All- The java BagIt Library (BIL) has been moved to Github (https://github.com/LibraryOfCongress/bagit-java) from SourceForge. Contributions are welcome. Best. --Justin Littman P.S. Also checkout the other OSS available from the Library of Congress: https://github.com/LibraryOfCongress |
From: Malik, S. <sm...@lo...> - 2013-06-24 23:37:43
|
Hi, I would try to make sure that the JSON in profile is valid JSON. You can verify the JSON at http://jsonlint.com/. If the JSON is valid then please send me your profile file and I can try to reproduce the issue. Thanks. Salim Salim Malik Information Technology Specialist Office of Strategic Initiatives Library of Congress (202)707-6863 (Office LA-314) (703)282-1254 (Mobile) ________________________________________ From: gretta treuscorff [dee...@gm...] Sent: Monday, June 24, 2013 6:38 PM To: loc...@li... Subject: [Loc-xferutils-mail] no success with project profiles I am attempting to use project profile, using bagger 2.1.3 on my mac osx 10.8.4 any time i modify existing profiles in the ~/bagger directory, they are (a) not recognized; and (b) cause bagger to not start correctly when i restart. i am only modifying existing files to the exact specification in the user manual (Bagger User Guide version 2.1.3) If i remove ~/bagger I can start bagger up again, but I can't find out how to get a custom profile to work. Even if it would register my changes, how am I to get a new name. If i rename the file, it definitely does not register, even when following the specified <project name>-profile.json format. any help is much appreciated. Thanks! |
From: gretta t. <dee...@gm...> - 2013-06-24 22:38:56
|
I am attempting to use project profile, using bagger 2.1.3 on my mac osx 10.8.4 any time i modify existing profiles in the ~/bagger directory, they are (a) not recognized; and (b) cause bagger to not start correctly when i restart. i am only modifying existing files to the exact specification in the user manual (Bagger User Guide version 2.1.3) If i remove ~/bagger I can start bagger up again, but I can't find out how to get a custom profile to work. Even if it would register my changes, how am I to get a new name. If i rename the file, it definitely does not register, even when following the specified <project name>-profile.json format. any help is much appreciated. Thanks! |
From: Eisenhauer, S. <Ste...@un...> - 2013-04-01 18:49:20
|
Mark, That's generally what I was hinting at as a possibility, though I didn't want to jump straight to Bagit Profiles as a solution candidate because I think warning output for these files could be potentially useful to more than just the subset of users utilizing a Profile (specifically, the subset of THOSE users whose profile specifies all of these common hazards). My reasoning for proposing it as a possible feature of the standard tools is the broader reach and reduction of duplication. I do think the functionality described so far in this thread could be good to have in the Profile Spec, though. With regard to the pattern/regex format, perhaps regexes would be overkill? I'm personally happy with how .gitignore files work, but then again that might not be the easiest or most practical format to emulate. Stephen Eisenhauer Programmer for Strategic Projects Libraries, University of North Texas ________________________________________ From: Littman, Justin [jl...@lo...] Sent: Monday, April 01, 2013 11:29 AM To: 'Mark Jordan'; loc...@li... Subject: Re: [Loc-xferutils-mail] Bagit Tools and Undesirable Files I'd suggest that a complementary use case is for "Ignore-Patterns", viz., files or directories that should be ignored in BagIt operations. In our environment, we often find it necessary to ignore .nfs files and lost+found directories. --Justin -----Original Message----- From: Mark Jordan [mailto:mj...@sf...] Sent: Monday, April 01, 2013 12:03 PM To: loc...@li... Subject: [Loc-xferutils-mail] Bagit Tools and Undesirable Files Hi Stephen, I'm just joining this list now, and this message is in response to your "Bagit Tools and Undesirable Files" thread but not 'of' the thread, if you get my drift. A small group of us have been working on a BagIt Profile Specification ( https://github.com/ruebot/bagit-profiles ) for a few months, and at this point, we think it can express in a machine-actionable form (JSON) most of the optional aspects of the BagIt spec itself. We also have a Python validator library ( https://github.com/ruebot/bagit-profiles-validator ), based on the Profile spec. Until now, we've chosen to restrict the Profile Spec to BagIt options only, but we're certainly interested in hearing use cases that identify machine-actionable constraints on the /data payload so we can build a generalized, extensible mechanism into the Profile spec. Your "Unacceptable-Patterns" use case is a great example. One mechanism we could build into BagIt Profiles would be to include a 'Payload' section in the top-level of the JSON file (i.e., a sibling of 'BagIt-Profile-Info') that would contain tags like "Unacceptable-Patterns", which in this case would be a list of regular expressions that a validating script could check (for example). Do you think that sort of approach would be useful? One issue would be that it would be important to use cross-language compatible regexes (like PCREs), or to bind one or more a 'Language' tags with the "Unacceptable-Patterns" tag. If anyone has other use cases for being able to constrain a Bag's /data payload like Stephen is suggesting, we'd be interested in hearing them. We're trying to move discussion of the Profile spec to its Github issues queue ( https://github.com/ruebot/bagit-profiles/issues ); let me know if that's OK and I'll start an issue that we can use, but if you'd all rather discuss this particular question here, no problem. Mark Mark Jordan Head of Library Systems W.A.C. Bennett Library, Simon Fraser University Burnaby, British Columbia, V5A 1S6, Canada Voice: 778.782.5753 / Fax: 778.782.3023 / Skype: mark.jordan50 mj...@sf... |
From: Littman, J. <jl...@lo...> - 2013-04-01 16:29:53
|
I'd suggest that a complementary use case is for "Ignore-Patterns", viz., files or directories that should be ignored in BagIt operations. In our environment, we often find it necessary to ignore .nfs files and lost+found directories. --Justin -----Original Message----- From: Mark Jordan [mailto:mj...@sf...] Sent: Monday, April 01, 2013 12:03 PM To: loc...@li... Subject: [Loc-xferutils-mail] Bagit Tools and Undesirable Files Hi Stephen, I'm just joining this list now, and this message is in response to your "Bagit Tools and Undesirable Files" thread but not 'of' the thread, if you get my drift. A small group of us have been working on a BagIt Profile Specification ( https://github.com/ruebot/bagit-profiles ) for a few months, and at this point, we think it can express in a machine-actionable form (JSON) most of the optional aspects of the BagIt spec itself. We also have a Python validator library ( https://github.com/ruebot/bagit-profiles-validator ), based on the Profile spec. Until now, we've chosen to restrict the Profile Spec to BagIt options only, but we're certainly interested in hearing use cases that identify machine-actionable constraints on the /data payload so we can build a generalized, extensible mechanism into the Profile spec. Your "Unacceptable-Patterns" use case is a great example. One mechanism we could build into BagIt Profiles would be to include a 'Payload' section in the top-level of the JSON file (i.e., a sibling of 'BagIt-Profile-Info') that would contain tags like "Unacceptable-Patterns", which in this case would be a list of regular expressions that a validating script could check (for example). Do you think that sort of approach would be useful? One issue would be that it would be important to use cross-language compatible regexes (like PCREs), or to bind one or more a 'Language' tags with the "Unacceptable-Patterns" tag. If anyone has other use cases for being able to constrain a Bag's /data payload like Stephen is suggesting, we'd be interested in hearing them. We're trying to move discussion of the Profile spec to its Github issues queue ( https://github.com/ruebot/bagit-profiles/issues ); let me know if that's OK and I'll start an issue that we can use, but if you'd all rather discuss this particular question here, no problem. Mark Mark Jordan Head of Library Systems W.A.C. Bennett Library, Simon Fraser University Burnaby, British Columbia, V5A 1S6, Canada Voice: 778.782.5753 / Fax: 778.782.3023 / Skype: mark.jordan50 mj...@sf... ------------------------------------------------------------------------------ Own the Future-Intel® Level Up Game Demo Contest 2013 Rise to greatness in Intel's independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d _______________________________________________ Loc-xferutils-mail mailing list Loc...@li... https://lists.sourceforge.net/lists/listinfo/loc-xferutils-mail |
From: Mark J. <mj...@sf...> - 2013-04-01 16:03:25
|
Hi Stephen, I'm just joining this list now, and this message is in response to your "Bagit Tools and Undesirable Files" thread but not 'of' the thread, if you get my drift. A small group of us have been working on a BagIt Profile Specification ( https://github.com/ruebot/bagit-profiles ) for a few months, and at this point, we think it can express in a machine-actionable form (JSON) most of the optional aspects of the BagIt spec itself. We also have a Python validator library ( https://github.com/ruebot/bagit-profiles-validator ), based on the Profile spec. Until now, we've chosen to restrict the Profile Spec to BagIt options only, but we're certainly interested in hearing use cases that identify machine-actionable constraints on the /data payload so we can build a generalized, extensible mechanism into the Profile spec. Your "Unacceptable-Patterns" use case is a great example. One mechanism we could build into BagIt Profiles would be to include a 'Payload' section in the top-level of the JSON file (i.e., a sibling of 'BagIt-Profile-Info') that would contain tags like "Unacceptable-Patterns", which in this case would be a list of regular expressions that a validating script could check (for example). Do you think that sort of approach would be useful? One issue would be that it would be important to use cross-language compatible regexes (like PCREs), or to bind one or more a 'Language' tags with the "Unacceptable-Patterns" tag. If anyone has other use cases for being able to constrain a Bag's /data payload like Stephen is suggesting, we'd be interested in hearing them. We're trying to move discussion of the Profile spec to its Github issues queue ( https://github.com/ruebot/bagit-profiles/issues ); let me know if that's OK and I'll start an issue that we can use, but if you'd all rather discuss this particular question here, no problem. Mark Mark Jordan Head of Library Systems W.A.C. Bennett Library, Simon Fraser University Burnaby, British Columbia, V5A 1S6, Canada Voice: 778.782.5753 / Fax: 778.782.3023 / Skype: mark.jordan50 mj...@sf... |
From: Littman, J. <jl...@lo...> - 2013-04-01 11:58:00
|
Would the idea be to warn when bagging or to warn when verifying (or both or something else)? --Justin From: Eisenhauer, Stephen [mailto:Ste...@un...] Sent: Thursday, March 28, 2013 1:09 PM To: loc...@li... Subject: [Loc-xferutils-mail] Bagit Tools and Undesirable Files Hi all, In our usage of BagIt, we've run into the situation of receiving bags containing certain "undesirable" files that creators unintentionally include (Thumbs.db, DS_Store, .listing, foobar~, et al.). Needless to say these files can be a nuisance farther down the conveyor belt and nobody is able to remove them without violating the relationship between the copy and the original. Naturally the BagIt format itself should remain completely content agnostic, but in some discussions here we've posed the idea that it may be helpful if bagging tools generated some kind of warning output when encountering these files. It may also be possible that this is a task more suited for BagIt Profiles to handle (an "Unacceptable-Patterns" section?), though a tool feature would have broader reach and require less duplication. What is the prevailing attitude toward all of this? Have I missed something that already addresses these questions? Stephen Eisenhauer Programmer for Strategic Projects Libraries, University of North Texas |
From: Eisenhauer, S. <Ste...@un...> - 2013-03-28 17:09:08
|
Hi all, In our usage of BagIt, we've run into the situation of receiving bags containing certain "undesirable" files that creators unintentionally include (Thumbs.db, DS_Store, .listing, foobar~, et al.). Needless to say these files can be a nuisance farther down the conveyor belt and nobody is able to remove them without violating the relationship between the copy and the original. Naturally the BagIt format itself should remain completely content agnostic, but in some discussions here we've posed the idea that it may be helpful if bagging tools generated some kind of warning output when encountering these files. It may also be possible that this is a task more suited for BagIt Profiles to handle (an "Unacceptable-Patterns" section?), though a tool feature would have broader reach and require less duplication. What is the prevailing attitude toward all of this? Have I missed something that already addresses these questions? Stephen Eisenhauer Programmer for Strategic Projects Libraries, University of North Texas |
From: Malik, S. <sm...@lo...> - 2012-02-13 21:37:49
|
All, Bagger 2.1.2 has been released to SourceForge at (i.e. including README.txt): http://sourceforge.net/projects/loc-xferutils/files/loc-bagger/2.1.2/ Please let me know if you have any questions. Thanks. Salim Salim Malik Software Engineer CTR/CACI 4114 Legato Road Fairfax, VA 22033 (202) 707-6863 (Desk - LAG07) (703)282-154 (Mobile) (703) 460-1061 (Remote Office) |
From: Littman, J. <jl...@lo...> - 2012-01-17 12:33:33
|
All- BagIt Library 4.0 has been released to SourceForge (https://sourceforge.net/projects/loc-xferutils/) and Maven Central Repo (http://repo1.maven.org/maven2/gov/loc/bagit/ -- might take some time for syncing). Changes in 4.0: 1. Added support for BagIt 0.97. The significant change is allowing tag directories. (Note that operations are version aware, meaning pre-0.97 bags do not allow tag directories.) 2. Removes Commons VFS. 3. Deprecates support for reading/writing tar, tar bz2, and tar gz. 4. Deprecates support for transferring SWORD and BOB. 5. Added close() method to Bag for closing IO resources. 6. Clarified logging messages for CompleteVerifier and ValidVerifier. 7. Changed so that bagging-in-place throws an exception if a prebag contains a data directory and tag directories for pre-0.97 bags. 8. Added support for fail modes when performing verification: * FAIL_FAST: Fail on first error. * FAIL_SLOW: Fail at end of verification. * FAIL_STEP: Fail after each step of verification. A step is a set of like verification operations. * FAIL_STAGE: Fail after each stage of verification. A stage is a set of logically grouped verification operations. For example, when validating a bag, all of the operations to verify that a bag is complete is a stage. 9. Added support for compressing zip files. 10. Replaced Commons Httpclient with Apache HttpComponents. Let me know if you have any questions or problems. --Justin |
From: COTHEY, V. <Viv...@gl...> - 2011-11-01 13:10:04
|
The schema mapping for http\://www.springframework.org/schema/beans/spring-beans-2.0.xsd=org/springframework/beans/factory/xml/spring-beans-2.0.xsd appears to be missing. This is preventing us from using "bagger" in a standalone or behind a firewall environment. I would be grateful if you could make the necessary correction. Many thanks (Dr) Viv Cothey Gloucestershire Archives _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Think before you print - only print this email if absolutely necessary. This email and any attachments are strictly confidential and intended for the addressee only. If you are not the named addressee you must not disclose, copy or take any action in reliance of this transmission and you should notify us as soon as possible. This email and any attachments are believed to be free from viruses but it is your responsibility to carry out all necessary virus checks and Gloucestershire County Council accepts no liability in connection therewith. |
From: Littman, J. <jl...@lo...> - 2011-09-06 15:51:16
|
All- BagIt Library 3.13 has been released to SourceForge (https://sourceforge.net/projects/loc-xferutils/) and Maven Central Repo (http://repo1.maven.org/maven2/gov/loc/bagit/ -- might take some time for syncing). Several releases were not made publicly available because they addressed LOC-specific needs, hence the jump from 3.9 to 3.13. Changes in 3.13: 1. Added support for keeping empty directories when bagging in place. 2. Increased default MAXMEM to 1024m. 3. Added verbose console and log progress reporting to CommandLineBagDriver. 4. Added support for ignoring symbolic links when verifying a bag on a file system. 5. Upgraded to Commons IO 2.0.1. Changes in 3.12: 1. Added support to CompleteVerifier, PreBag, and BagFactory to ignore specified directories (e.g., lost+found). Changes in 3.11: 1. Added support to FileSystemWriter to only write files that had mismatch between manifest and files on disk. Changes in 3.10: 1. Added additional list methods to BagInfoTxt. 2. Added chaining completer. 3. Changed completers to not create empty payload manifests. 4. Added support to FileSystemWriter to only write tag files. --Justin |
From: Illtud D. <ill...@ll...> - 2011-08-30 10:32:32
|
On 30/08/11 11:06, Littman, Justin wrote: > Timestamp would definitely be more efficient in some circumstances. > If you (or anyone else) wanted to write a Completer implementation > that relied on a timestamp, I'd be happy to merge into the code > base. Thanks. I'll see if I can get one of our java developers to look at this. -- Illtud Daniel ill...@ll... Prif Swyddog Technegol Chief Technical Officer Llyfrgell Genedlaethol Cymru National Library of Wales |