Re: [Bug-gnupod] Add --copy option to gnupod_search?

[Richard van den Berg]

On 16 mrt. 2011, at 16:44, Stuart McLaren <address@hidden> wrote:

> Ok. What I plan to do is have it work as follows:
>> 
> 
> 1) update gnupod_search --help --> Would include info on the --copy option
> 2) gnupod_search --copy --> Would backup whole ipod to current directory
> 3) gnupod_search --copy --directory=/tmp --> Would backup whole ipod to /tmp
> 4) gnupod_search --copy --directory=/tmp -a John_Doe -l Rock_On 
> --> Would backup artist John_Doe's Rock_On album to /tmp
> (ie the behaviour with matching would be exactly the same as delete)
> 
> Note that output would be in the form:
> 
> "John_Doe - Rock_On"/01_Song_One.m4a
> "John_Doe - Rock_On"/02_Song_Two.m4a
> 
> Does that work for you?

Sounds good to me, but let's hear Henrik's opinion as well (he is the main 
gnupod coder). 

> 
>> Interesting. Is this an iPod or OS limitation? What OS are
>> you using?
> 
> Debian 6.0, 2.6.32-5-amd64
> 
> Without this option there's a mismatch between the
> read ipod path for the file and the real mount point, ie
> gnupod looks for
> 
> /mnt/ipod/f19/file.mp3
> 
> but that doesn't exist, without the mount option its actually
> 
> /mnt/ipod/F1/file.mp3. With the mount option they
> match up.

According to Google shortname=lower is the default for linux vfat mounts. Will 
accessing a directory u6sing F19 not work when f19 exists on vfat? Silly case 
insensitive file systems..

Please remember to copy the mailing list on replies. 

Richard

>