<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Filenames by Design, Part One</title>
	<atom:link href="http://www.linux-mag.com/id/7158/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.linux-mag.com/id/7158/</link>
	<description>Open Source, Open Standards</description>
	<lastBuildDate>Sat, 05 Oct 2013 13:48:18 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.1</generator>
	<item>
		<title>By: eemaestro</title>
		<link>http://www.linux-mag.com/id/7158/#comment-5794</link>
		<dc:creator>eemaestro</dc:creator>
		<pubDate>Wed, 30 Nov -0001 00:00:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.linux-mag.com/id/7158/#comment-5794</guid>
		<description>This sounds like a great application for GNU/linux builtin utilities.     I can&#039;t wait to read how you do it.    The idea of saving annotations in a spreadsheet sounds like a great idea, in order to quickly find photos.  Much simpler than using some database program.  Thanks for writing this.</description>
		<content:encoded><![CDATA[<p>This sounds like a great application for GNU/linux builtin utilities.     I can&#8217;t wait to read how you do it.    The idea of saving annotations in a spreadsheet sounds like a great idea, in order to quickly find photos.  Much simpler than using some database program.  Thanks for writing this.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: eemaestro</title>
		<link>http://www.linux-mag.com/id/7158/#comment-5795</link>
		<dc:creator>eemaestro</dc:creator>
		<pubDate>Wed, 30 Nov -0001 00:00:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.linux-mag.com/id/7158/#comment-5795</guid>
		<description>Jerry,&lt;br /&gt;
I suggest you include in a future article a description of how to use GNU/linux tools (sed, tr, dd, etc) how to discard from text files characters that are not letters, numerals, punctuation marks, or whitespace -- in other words, nonprintable ASCII characters.&lt;br /&gt;
&lt;br /&gt;
I did write a C program that strips HTML tags from a text file.</description>
		<content:encoded><![CDATA[<p>Jerry,<br />
I suggest you include in a future article a description of how to use GNU/linux tools (sed, tr, dd, etc) how to discard from text files characters that are not letters, numerals, punctuation marks, or whitespace &#8212; in other words, nonprintable ASCII characters.</p>
<p>I did write a C program that strips HTML tags from a text file.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: mabradford</title>
		<link>http://www.linux-mag.com/id/7158/#comment-5796</link>
		<dc:creator>mabradford</dc:creator>
		<pubDate>Wed, 30 Nov -0001 00:00:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.linux-mag.com/id/7158/#comment-5796</guid>
		<description>I have found that instead of using Windows to &quot;span&quot; a file system across with whatever techniques - I use Linux and LVM. I install say 3 hard disks of maybe 160gigs, 250gigs, 300 gigs. Using LVM to create but not format yet - I start with say a 100 gig non-formatted LVM partition on the 160g hard disk and then I go to the other 2 hard disks and use up their entire disks space with creating non-formatted LVM partitions on them as well. After all the hard disks have non-formatted LVM partitions on them - I go into the LVM utility that comes up during the initial Install and create a Group I call the VolGroup00 and I add all the listed drives to that Volume Group and call it logvol00 and format it ext3 and call it /srv.  After the install is done - you can completely fill the /srv folder up with whatever - I usually leave 20% free - and voila - you have a &quot;raid typical&quot; LVM setup that spans one directory across many drives and is completely usable as such. I first lucked across this technique by chance with SuSE 10 while not knowing what I was doing - but, it works very good. I&#039;ve been using the same file storage machine for years and it hasn&#039;t failed yet...about 3 years and is typically fast.</description>
		<content:encoded><![CDATA[<p>I have found that instead of using Windows to &#8220;span&#8221; a file system across with whatever techniques &#8211; I use Linux and LVM. I install say 3 hard disks of maybe 160gigs, 250gigs, 300 gigs. Using LVM to create but not format yet &#8211; I start with say a 100 gig non-formatted LVM partition on the 160g hard disk and then I go to the other 2 hard disks and use up their entire disks space with creating non-formatted LVM partitions on them as well. After all the hard disks have non-formatted LVM partitions on them &#8211; I go into the LVM utility that comes up during the initial Install and create a Group I call the VolGroup00 and I add all the listed drives to that Volume Group and call it logvol00 and format it ext3 and call it /srv.  After the install is done &#8211; you can completely fill the /srv folder up with whatever &#8211; I usually leave 20% free &#8211; and voila &#8211; you have a &#8220;raid typical&#8221; LVM setup that spans one directory across many drives and is completely usable as such. I first lucked across this technique by chance with SuSE 10 while not knowing what I was doing &#8211; but, it works very good. I&#8217;ve been using the same file storage machine for years and it hasn&#8217;t failed yet&#8230;about 3 years and is typically fast.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: mabradford</title>
		<link>http://www.linux-mag.com/id/7158/#comment-5797</link>
		<dc:creator>mabradford</dc:creator>
		<pubDate>Wed, 30 Nov -0001 00:00:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.linux-mag.com/id/7158/#comment-5797</guid>
		<description>I forgot to mention that my main data machine has 3 x 500gig hard disks and I run them with the same LVM setup and using ReiserFS.  I know people are frowning away from ReiserFS but - it is near SCSI lightening in speed when it comes to small files and pictures. So putting MySQL on one machine and that data on another machine designed just for servicing data calls - works terrific.</description>
		<content:encoded><![CDATA[<p>I forgot to mention that my main data machine has 3 x 500gig hard disks and I run them with the same LVM setup and using ReiserFS.  I know people are frowning away from ReiserFS but &#8211; it is near SCSI lightening in speed when it comes to small files and pictures. So putting MySQL on one machine and that data on another machine designed just for servicing data calls &#8211; works terrific.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: graemeharrison</title>
		<link>http://www.linux-mag.com/id/7158/#comment-5798</link>
		<dc:creator>graemeharrison</dc:creator>
		<pubDate>Wed, 30 Nov -0001 00:00:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.linux-mag.com/id/7158/#comment-5798</guid>
		<description>I also have 50,000+ photos, mainly taken at full-res (JPEG compression of 100%) on a 10MP Nikon DSLR (ie 50k x 4MB = 200GB).&lt;br /&gt;
I&#039;m now mainly Ubuntu, but retain dual-boot to WinXP.&lt;br /&gt;
To avoid corruption of photos, I strongly recommend storing photos on an external drive (one that is not used for system writes etc, so can&#039;t be trashed by normal system failures).&lt;br /&gt;
For compatibility I use NTFS formatting of USB drives (2TB in total), so I can attach to anyone&#039;s PC and copy off some photos (WinXP lack of support for EXT3 dictates NTFS).&lt;br /&gt;
I use Irfanview (www.irfanview.com) as BEST image quick-editor for 7+ years.  I&#039;ve pleaded with Irfan to do a Linux version, but he insists many just use WINE... which is a bit slower to start-up.&lt;br /&gt;
Irfanview allows quick batch processing, without Linux command-line issues of having spaces within filenames.&lt;br /&gt;
I use a simpler directory structure on drive &quot;/media/Photos&quot; (seen in windows as &quot;P:&quot; or &quot;Photos&quot;) of:&lt;br /&gt;
&quot;2008 10 Yr8 Hockey v Rose Bay&quot;&lt;br /&gt;
&quot;2008 10 Farm riding w jumps&quot;&lt;br /&gt;
&lt;br /&gt;
In other words, each photo session is given a meaningful name, and I put the year and month in front of that for directory sorting purposes.  Sometimes, I go one level deeper where the &#039;event&#039; is &quot;2007 01 India Trip&quot; and then under that are separate collections based on each of the major cities/sites visited... as if I am to look for an Indian photo I will know where to go, and it saves having too many higher level directories.  By the time I get to 75,000 photos I will have to put some of the 1990s to 2004 photos in a year-based higher level directory.&lt;br /&gt;
&lt;br /&gt;
This approach means that there is no need to access any external database or spreadsheet to work out where a photo is.  For most sessions, photos are left as just the auto-numbered filename, but if it is a great shot, I put an explicit filename on the photo, such as &quot;Great shot of Claudia jumping Princess 12oct08.jpg&quot; and when I access that directory, I can easily see the few great ones, without looking at thumbnails.  Also, for truly great shots I COPY the image to a separate higher-level directory &quot;Claudia&#039;s favourites&quot;, as it is never worth re-diving into 50,000 anything to re-find something that is within your top-200!!!&lt;br /&gt;
&lt;br /&gt;
Using a well-organised directory level organisation beats the hell out of any photo-organising software, as that software may well go out-of-support, yet your JPEGs will always be readable.  However, best to put explicit description in the filename, not elsewhere, so that when people have a copy of that file, you get the description &#039;locked&#039; with the file.&lt;br /&gt;
&lt;br /&gt;
When I do cut-down sizes for emailing say, I create a &quot;/sqzd&quot; directory under that event, use Irfanview to create 1024x768 (say) images at 40% compression, then work through them, deleting the squeezed versions of any not worth emailing, till that directory contains the top-5 or whatever of the session... then I email just those, and leave that squeezed directory in place, as the total space is just 5x60kb in total, and who knows someone may ask for it to be emailed again...</description>
		<content:encoded><![CDATA[<p>I also have 50,000+ photos, mainly taken at full-res (JPEG compression of 100%) on a 10MP Nikon DSLR (ie 50k x 4MB = 200GB).<br />
I&#8217;m now mainly Ubuntu, but retain dual-boot to WinXP.<br />
To avoid corruption of photos, I strongly recommend storing photos on an external drive (one that is not used for system writes etc, so can&#8217;t be trashed by normal system failures).<br />
For compatibility I use NTFS formatting of USB drives (2TB in total), so I can attach to anyone&#8217;s PC and copy off some photos (WinXP lack of support for EXT3 dictates NTFS).<br />
I use Irfanview (www.irfanview.com) as BEST image quick-editor for 7+ years.  I&#8217;ve pleaded with Irfan to do a Linux version, but he insists many just use WINE&#8230; which is a bit slower to start-up.<br />
Irfanview allows quick batch processing, without Linux command-line issues of having spaces within filenames.<br />
I use a simpler directory structure on drive &#8220;/media/Photos&#8221; (seen in windows as &#8220;P:&#8221; or &#8220;Photos&#8221;) of:<br />
&#8220;2008 10 Yr8 Hockey v Rose Bay&#8221;<br />
&#8220;2008 10 Farm riding w jumps&#8221;</p>
<p>In other words, each photo session is given a meaningful name, and I put the year and month in front of that for directory sorting purposes.  Sometimes, I go one level deeper where the &#8216;event&#8217; is &#8220;2007 01 India Trip&#8221; and then under that are separate collections based on each of the major cities/sites visited&#8230; as if I am to look for an Indian photo I will know where to go, and it saves having too many higher level directories.  By the time I get to 75,000 photos I will have to put some of the 1990s to 2004 photos in a year-based higher level directory.</p>
<p>This approach means that there is no need to access any external database or spreadsheet to work out where a photo is.  For most sessions, photos are left as just the auto-numbered filename, but if it is a great shot, I put an explicit filename on the photo, such as &#8220;Great shot of Claudia jumping Princess 12oct08.jpg&#8221; and when I access that directory, I can easily see the few great ones, without looking at thumbnails.  Also, for truly great shots I COPY the image to a separate higher-level directory &#8220;Claudia&#8217;s favourites&#8221;, as it is never worth re-diving into 50,000 anything to re-find something that is within your top-200!!!</p>
<p>Using a well-organised directory level organisation beats the hell out of any photo-organising software, as that software may well go out-of-support, yet your JPEGs will always be readable.  However, best to put explicit description in the filename, not elsewhere, so that when people have a copy of that file, you get the description &#8216;locked&#8217; with the file.</p>
<p>When I do cut-down sizes for emailing say, I create a &#8220;/sqzd&#8221; directory under that event, use Irfanview to create 1024&#215;768 (say) images at 40% compression, then work through them, deleting the squeezed versions of any not worth emailing, till that directory contains the top-5 or whatever of the session&#8230; then I email just those, and leave that squeezed directory in place, as the total space is just 5x60kb in total, and who knows someone may ask for it to be emailed again&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: graemeharrison</title>
		<link>http://www.linux-mag.com/id/7158/#comment-5799</link>
		<dc:creator>graemeharrison</dc:creator>
		<pubDate>Wed, 30 Nov -0001 00:00:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.linux-mag.com/id/7158/#comment-5799</guid>
		<description>Now I know that the trade-off for using long filenames to describe a photo session, or an individual photo will have negative consequences on file retrieval time (compared to simply a photo number).  However, I find that the issue with photos and similar archival material is that it is very seldom accessed (unlike a commercial database say) but the issue is re-finding stuff (ie human search time).  So being able to go directly to year/month and find the session is about as fast as you can get (ie avoids opening external databases etc).&lt;br /&gt;
&lt;br /&gt;
In fact I&#039;ve set up an imaging bureau and believe that with things like medical images (or scans of medical paperwork), nothing beats having the &#039;medical record number&#039; followed by &#039;surname&#039; followed by &#039;first names&#039; and optionally followed by &#039;date of birth&#039; on ALL images.  As that way, if one is searching in a hundred years time, one will still easily find all material for that particular patient, and none other... whereas all databases and other required search intermediaries may have been long lost.  I&#039;ve been guest-lecturer to national archivists associations etc - the real risk is not losing the information, but knowing how to access it... like all the tapes kept which no longer have readers to retrieve the information.&lt;br /&gt;
&lt;br /&gt;
Having said the above, I also use Diskeeper (home edition US$29) in WinXP, so when dual boot is brought up in WinXP every now and then, Diskeeper does a full-automatic background task defragmentation of the 2TB of external NTFS drives, putting all directory information together etc, to optimise directory opens and file searches.  Diskeeper is the best commercial disk optimizer... and the effect is to fully-offset any delays caused by using long filenames.&lt;br /&gt;
&lt;br /&gt;
However, while I differ with the author on the best way to organize photos, let me suggest that the article is great for its description of how to use script to do detailed automated directory operations...&lt;br /&gt;
Graeme Harrison (prof at-symbol post.harvard.edu)</description>
		<content:encoded><![CDATA[<p>Now I know that the trade-off for using long filenames to describe a photo session, or an individual photo will have negative consequences on file retrieval time (compared to simply a photo number).  However, I find that the issue with photos and similar archival material is that it is very seldom accessed (unlike a commercial database say) but the issue is re-finding stuff (ie human search time).  So being able to go directly to year/month and find the session is about as fast as you can get (ie avoids opening external databases etc).</p>
<p>In fact I&#8217;ve set up an imaging bureau and believe that with things like medical images (or scans of medical paperwork), nothing beats having the &#8216;medical record number&#8217; followed by &#8216;surname&#8217; followed by &#8216;first names&#8217; and optionally followed by &#8216;date of birth&#8217; on ALL images.  As that way, if one is searching in a hundred years time, one will still easily find all material for that particular patient, and none other&#8230; whereas all databases and other required search intermediaries may have been long lost.  I&#8217;ve been guest-lecturer to national archivists associations etc &#8211; the real risk is not losing the information, but knowing how to access it&#8230; like all the tapes kept which no longer have readers to retrieve the information.</p>
<p>Having said the above, I also use Diskeeper (home edition US$29) in WinXP, so when dual boot is brought up in WinXP every now and then, Diskeeper does a full-automatic background task defragmentation of the 2TB of external NTFS drives, putting all directory information together etc, to optimise directory opens and file searches.  Diskeeper is the best commercial disk optimizer&#8230; and the effect is to fully-offset any delays caused by using long filenames.</p>
<p>However, while I differ with the author on the best way to organize photos, let me suggest that the article is great for its description of how to use script to do detailed automated directory operations&#8230;<br />
Graeme Harrison (prof at-symbol post.harvard.edu)</p>
]]></content:encoded>
	</item>
</channel>
</rss>