fix temp filename
Was not putting it inside the temp dir, but next to it! This was just wrong, and it led to a longer filename that desired being used, leading to some bug reports.
This commit is contained in:
parent
6e71094e7d
commit
2936153fc4
6 changed files with 43 additions and 1 deletions
|
@ -36,3 +36,5 @@ FAIL (0.29s)
|
|||
(This could be due to a bug in git-annex, or an incompatability
|
||||
with utilities, such as git, installed on this system.)
|
||||
```
|
||||
|
||||
> [[fixed|done]] --[[Joey]]
|
||||
|
|
|
@ -0,0 +1,12 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 2"""
|
||||
date="2015-12-06T20:02:49Z"
|
||||
content="""
|
||||
Ok, this involves where the test suite is run.
|
||||
The addurl test adds `file://`pwd`/somefile`, and that will create a file
|
||||
with a name like `_home_you_sub_dir_path_here_somefile`. Which can easily
|
||||
exceed filename length limits of 255 bytes.
|
||||
|
||||
There was indeed a reversion in addurl's handling of that.
|
||||
"""]]
|
|
@ -46,3 +46,5 @@ Debian amd64 unstable package 5.20151116-1.
|
|||
### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
|
||||
|
||||
That’s just a little hiccup in, up to now, various months of merry use! ;-)
|
||||
|
||||
> [[fixed|done]] --[[Joey]]
|
||||
|
|
|
@ -0,0 +1,24 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 1"""
|
||||
date="2015-12-06T19:50:59Z"
|
||||
content="""
|
||||
I can reproduce this.
|
||||
|
||||
symlink("../.git/annex/objects/fK/9M/URL--http&c%%mvod.lvlt.rtve.es%resour-39e58395b01e2385d46bade56127cfc4/URL--http&c%%mvod.lvlt.rtve.es%resour-39e58395b01e2385d46bade56127cfc4", ".git/annex/misctmp/Documentos_RNE___Coss\303\255o_y_la_Casona_de_Tudanca__refugio_de_la_cultura_espa\303\261ola_entre_las_monta\303\261as_de_Cantabria___28_08_15.mp3.0Documentos_RNE___Coss\303\255o_y_la_Casona_de_Tudanca__refugio_de_la_cultura_espa\303\261ola_entre_las_monta\303\261as_de_Cantabria___28_08_15.mp3") = -1 ENAMETOOLONG (File name too long)
|
||||
|
||||
The problem is not the length of the link target, which is only 170
|
||||
characters and will work on any OS. The basename of the symlink
|
||||
being created is pretty long, 294 characters, and that's the
|
||||
cause of the failure.
|
||||
|
||||
joey@darkstar:~>ln -s /dev/null $(perl -e 'print ("a" x 294)')
|
||||
ln: failed to create symbolic link ‘aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa’ -> ‘/dev/null’: File name too long
|
||||
|
||||
The limit is 255 characters in a single path component (`pathconf _PC_NAME_MAX`).
|
||||
|
||||
So, the issue is caused by the rss feed having a long title for this
|
||||
item.
|
||||
|
||||
And this used to work; it's a recent reversion. Fixing.
|
||||
"""]]
|
Loading…
Add table
Add a link
Reference in a new issue