Version: 0.6.2 (using KDE KDE 3.2.3) Installed from: Gentoo Packages OS: Linux It's a little thing, but when I try entering an album filename with a forward slash (/) Digikam chokes on the slash, "Could not make folder /home/user/photos/Mt Hood 22/08/04". I can't seem to escape the forward slash with either a backslash or quotes. But it doesn't seem that I should have to escape it anyway, since that's a common delimiter for dates. Thanks.
/ can't be used in a unix file/directory name as it conflicts with / as the directory separator
Then shouldn't the error message be more explicit? Is everyone new to Unix going to know that? Ideally there would be a way to map the / to some other char. Thanks.
the cvs version will give you an error message if you try to create an album with a / in the name. some kde apps map / to %2F, but its a kde specific solution and doesn't work for other apps.
Thanks. I'm not sure I understand though, isn't digikam a KDE app?
Albums in digikam are implemented as folders. The name of the Album is used as the folder name. Folder names can not contain '/' because it's used as (sub)folder seperator. Digikam could encode the '/' as '%2F' but then the plugins and all other filesystem brower would show you a '%2f' in folder listings. Quite confusing. Achim
I hope somebody is reading this even though the bug report is marked as invalid. I consider the current behaviour to be a (minor!) bug, too. So here's my proposal: store the album name in the digikam.xml file and always use a sanitized version of this name as directory name. By sanitized I mean: remove or replace slashes and anything non-ASCII. Or, at least replace spaces by underscores and somehow escape slashes. The current behaviour leads either to encoding hell (I really don't like UTF-8 and spaces in filenames) or to "ugly" names when one restricts oneself to plain ASCII without slashes and spaces. Apart from this issue the current digikam really rocks! Thanks a lot.
answering comment #6: as Achim said, the albums are just folders on disk. whatever is allowed by the filesystem is allowed to be in the albumname: in short max 256 chars long and can contain any character which is not "/". there are no other restrictions, you can use utf-8 and spaces without any problems
On Monday 31 January 2005 23:57, Renchi Raju wrote: > as Achim said, the albums are just folders on disk. whatever is allowed by > the filesystem is allowed to be in the albumname: in short max 256 chars > long and can contain any character which is not "/". there are no other > restrictions, you can use utf-8 and spaces without any problems Thanks for your reply. I'm just worried about two things: * Spaces in filenames can lead to ugly problems with scripts. I know that not everyone is writing shell scripts and when done properly everything works, but still, it would be more elegant to have no spaces in filenames. * I wouldn't be surprised if some users will have encoding problems when they use their data on other operating systems (or even a non-utf-8 linux distribution). IMO the filename should be independent of the contents of a file. For example, why include an ID tag for the title in Ogg Vorbis files? After all, the filename can contain everything (except the "unimportant" slash) So, why not use the filename as title? The same holds for KWord Documents: even though I can set a title, the actual filename is independent. In these and many other cases this information (even the title or track name) is considered to be metadata and is stored in the file, not the filesystem. Actually, digikam is doing this (storing the metadata in digikam.xml) for everything -- except the album name! Again IMHO, it would be nice to move the album name to digikam.xml. That being said, I can live with the current situation because I am knowledgable enough to work around these problems. Kind regards, and congratulations for a fine program, Gilles
I would not agree with you. I often other programs like mc or konqueror to navigate over my photos and I like when album name equals to folder name. For now digikam have the another name for album - album description. You can use it for any purposes. I think it can contains any characters. At least it is possibble to do.
By the way on by SuSE 9.1 machine: lan@lan:~/tmp> uname -a Linux lan 2.6.5-7.111.30-default #1 Fri Jan 14 12:58:46 UTC 2005 i686 athlon i386 GNU/Linux lan@lan:~/tmp> touch file\\with\\slash lan@lan:~/tmp> mkdir dir\\with\\slash lan@lan:~/tmp> ls -lad file* dir* drwxr-xr-x 2 lan users 48 2005-02-02 09:04 dir\with\slash -rw-r--r-- 1 lan users 0 2005-02-02 09:04 file\with\slash lan@lan:~/tmp>
Opps, sorry, this is not that slash :-)
comment #6: Gilles you mixed something up ;) utf-8 _is_ the solution for the encoding hell. I have user from around the globe and all those different 8bit encodings are #$^@@^^$@ (especially on servers) Now no new installatation without UTF-8 as default here! Peace;) Achim
On Thursday 03 February 2005 01:09, Achim Bohnet wrote: > comment #6: Gilles you mixed something up ;) utf-8 _is_ the solution for > the encoding hell. I have user from around the globe and all those > different 8bit encodings are #$^ ^^$@ (especially on servers) Yes, I know that in the long run it's the only viable solution, and I'm no longer using anything non-utf-8. Yet, in the past, I had some problems when writing CDs or using a USB pen drive and so on. AFAIK Windows doesn't use utf-8 as default and this can lead to problems. Ok, that's only insofar digikam's fault that I cannot choose the directory name. After all, the album name is prominently used in digikam as a title. Therefore I'm forced to name the album something useful (with spaces and everything). But from a Unix perspective these filenames (with spaces or shell metacharacters) can be problematic. Additionally, this leads to a superfluous restriction (no slashes). Do other photo management apps have the same limitation? I doubt it. > Now no new installatation without UTF-8 as default here! Here too :-) I guess it's up to the developers to decide. ;-) Kind regards, Gilles